This is really a massive release with many cool new features
My personal favorite is add-libs
You can now write single file demos or minimal examples for issues. Really lowers the friction to share small runnable snippets with people
You can also actually use it to demo Java libraries as well without all the Java boilerplate. Just poke around in the REPL and paste code into a comment on HN or wherever and anyone can replicate your "setup" and get it running exactly the same. No need to clone a repo or anything
I thought they were going to hold this until Clojure/conj 2024. No particular reason to believe so (besides Clojure 1.10 being released around the same time as Clojure/conj 2021 and the Datomic-becoming-free announcement being done at the very start of Clojure/conj 2023).
Still waiting on spec2, though... for now I am working around rigidity of specs by using Malli but it really isn't a first-class citizen in Clojure (mostly due to inability to check macros, and this is by design of the Clojure compiler). But you can emulate the ideas of schema/select by manipulating malli schemas as data.
The changes for functional interfaces also means we no longer have to maintain utility macros like
What do you mean by “inability to check macros”? You can s/fdef macros with spec and it checks the calls at compile time. In fact Clojure core uses spec to check macro calls as you can see in the stack trace sometimes when you call one wrong. Do you mean something else?
If you're interested in learning more about Clojure, check out the Clojure/conj conference Oct 23-25 in Alexandria, VA. https://2024.clojure-conj.org :)
Lovely to see add-libs and sync-deps, aren't many (any?) reasons to close down a session at all now.
This release feels like it had a very different scope from previous releases, contains a lot of stuff, which is exciting to see! But I hope it doesn't end up like a hairball a few releases down from increase of pace or something.
The functional interface changes are huge. Clojure is always at its best when staying close to Java via judicious use of interop and this solves one of the major missing links.
It continues to exist and is in use. Lots of work has been done on a successor, but that is stalled while we consider what we want to do on various things.
Is it going strong? I'm evaluating it for a new project. I'm considering it together with Clara[0]. However, it does give a vibe that it's not as mainstream as it was before and that the ecosystem is more sparse than what is once was.
I'm not trying to troll. I want to choose it. It seems like a good engineering decision to me, but if it's nosediving in popularity and contributors, this might bite me back in the near future.
Clojure is great. Brining together Lisp with the Java ecosystem makeand its concurrency model makes it great for building backend system, while still enabling quick changes.
One thing that I found noteworthy is that Clujure did not pickup some innovations happening at Java since like version 8, such as Invoke Dynamic in the JVM or streams.
Generally for streams, the equivalent in Clojure with sequences or transducers is much cleaner and simpler so there was not a lot of reason to want them from Clojure. However, it is important to provide interop paths to work with Java libs that make use of them.
The functional interface coercion is implemented with invokedynamic.
"Enterprise" stuff in a much less "enterprise" way is one usage, hence being based off the JVM. Rich Hickey has also mentioned the concept of "situational programs"[1] which Clojure is used in a lot. Clojure is also used in a wide variety of other areas like data science[2] or desktop applications[3] much like other general purpose programming languages.
It is a general programming language (with great interop with Java). You can pretty much build anything with it - web apps (backend + frontend), APIs, Scripts, etc. Anything you can do in Python / Java you can do it in Cloujure. It even has libraries for data crunching (or can use Java libs).
It's a general purpose programming language that runs on the JVM.
It can easily interop with Java and do the same stuff that Java does ('enterprise stuff' and more).
It excels at handling data transformations, so it's popular for tasks involving complex data pipelines, analysis, or real-time processing.
Clojure’s immutable data structures and concurrency story make it great for building highly concurrent systems, so things like financial services, real-time monitoring, event processing.
Clojurescript compiles to Javascript and interops with it well, so web based front end applications. It's used for mobile app development too.
There are libraries for AI/data sciences and there's python interop via library too, so you can build Clojure apps on top of Python libs.
Native-fast shell scripts using Babashka.
I would not use it for low level system programming (eg. where C is used), but for everything else - it would be one of my first choices.
It's a very pragmatic and practical programming language, with a strong philosophy behind every design decision and the fact that it can interop with pretty much everything makes it a powerful tool in skilled hands. Learning curve is quite steep though, but well worth climbing it.
NuBank, OneStudyTeam, CircleCI, and Guaranteed Rate are some of the larger companies I know about personally that have significant investments in Clojure.
Exoscale, a cloud provider is also using clojure heavily.
Pretty much anywhere where the jvm is a good fit, but given it’s a hosted language you can also use it to emit dart code or js and find it running on shoulders of others (like jank, llvm based dialect, or babashka)
This is a wonderful language I've only just started paying attention to, watching the talks from Rich on YouTube have ruined things I loved (like Either types.) I'm struggling with how to introduce it into my company without recommending my colleagues follow my path of working through 3 books and then watching most of the conj talks from the last 12 years on 1.75x speed, while building a personal project and re-implementing a couple of services I work with every day in it... but the lessons around simplicity I think are so critical, I'm going to find a way.
I've been at an organization that went from Java to Clojure about 12 years ago. I think there were two main things that allowed us to make the move:
* No one was in love with Java. It was fine but we were doing the whole spring style super verbose Java and it felt like a lot of ceremony to get anything done. There had been an experiment with Scala previously but that hadn't taken off.
* We had a service-oriented architecture which meant we could try Clojure out on a few new services and see how it felt.
We ended up going from 2 services to moving the whole org over really quickly. A lot of excitement built up and people didn't want to be left out. At the end of things only 2 people decided they didn't want to learn Clojure.
A few other things we did:
* Bought loads of books and left them lying around
* Started a Clojure club where we booked an hour a week and did some exercises in Clojure
* Had a big meeting where we convinced everyone that Clojure was worth an experiment
* Brought in 3 consultants to do some Clojure training for everyone
* Probably strong armed everyone into watching simple made easy - it helped that lots of people had already seen it live that year
There are a few talks about it floating around although they are very very old now and I'm not sure they're worth the time!
Find the least important project that one person can take on, and have that be the prototype for the clojure stack.
Ideally, use someone well versed in the tech stack - otherwise, you're taking on double risk of a new tech stack plus unfamiliarity. This prototype needs to demonstrate the value of the clojure stack - which has to have a business value (aka, speed/ease of maintenance etc).
Convince the decision makers to use clojure after the above prototype showed value, and use it to extrapolate value for other projects. This will then require a transition from doing the project, to teaching others (who might not know clojure at all). You cannot rely on just telling people to watch videos or read books - they won't do it, and it will cause failure in subsequent projects.
You will have to hand hold, until the newbie "clicks". Unfortuantely, this is an uphill battle, because management will always want to hire for the "regular/normal" tech stack, and will have trouble finding clojure-ready people. So the company will continue to have to invest in teaching it to new hires, which is a drain that could tank the clojure move.
It's funny because I went the opposite direction - from clojure to Rust, and I feel my programs are more maintainable, easier to re-read code written by myself and others, and runs without needing to bring along a virtual machine.
I do like Rich's talks and agree that static typing can be taken a bit too far though.
ClojureScript in particular is much nicer to work with compared to JavaScript
Honestly, maybe don’t. You love Clojure, that’s awesome. But introducing it at your company if it does not have a lisp culture already might not go so well. You say so yourself: lisp dialects like Clojure come with a steep learning curve, and not everyone will appreciate the shift, especially if they're comfortable with the current stack.
Forcing it on your team could create frustration, confusion, and a lot of resentment, not just toward the language, but possibly toward you. Sure, you might convert a person or two, but most will likely see it as unnecessary complexity.
If you really want to write Clojure every day, you might be better off finding a company that already embraces it instead of trying to turn your current team into Clojurists. Sometimes it’s better to enjoy something for yourself than to make it everyone else’s problem.
Every company likes to hear about increased productivity and less bugs, and that's what Clojure/Script gives you. The trade-off is you get less resumes when hiring. The plot twist is the resumes are much higher quality.
The way is to drop Clojure and adopt it's principles. Teach your colleagues the functional engineering principles.
You can write code that looks a lot like Clojure in any modern language now, a lot of the functional primitives have been adopted in mainstream. e.g. Async/await => channels.
I started my career as a Clojure/Clojurescript developer 12 years ago. And now I do python for ML research and Typescript for prototyping all day.
Clojure honestly help me back a lot of the time because the tooling is so far behind the large programming communities. Functional programming has a lot of good ideas, but none good enough to leave behind all the packages on pip/npm.
I would only ever advise niche programming languages for small sub-teams that are highly technical were it makes a lot of sense. Something like compiler teams, webgl/triton for GPU programming, etc...
Dont. It wont be appreciated because nobody but you can work on it, and one day you wont work there anymore and the company is stuck with a few projects in Clojure while the rest is on their regular tech stack. You are creating a major company risk just for your own personal benefit.
> Does any of this release help with startup time?
Clojure (and indirectly Java) was never created with "fast startup speed" in mind. This is why things like `add-lib` (that was added in this release) is so useful, because you start your developing session once, and it stays open until you either have to restart your computer or done developing the project.
Then the typical deployment target is either "Push this .jar to a server somehow, start the process and let it run" or "User double-clicks executable, waits for application to be ready".
Finally, if you're OK with JavaScript you could give ClojureScript a try, has fast startup (as fast as NodeJS I suppose) but yeah, it's JavaScript.
But overall, Clojure/Java isn't optimized for the use-case of "Start process for each request, stop process once processed" so I'm guessing you'll face an uphill battle there.
But from java world: With GraalVM/NativeImage, it is possible to compile (clojure or java) .jar files into native binaries.
Those binaries have a way faster to startup (less than 10ms for non-trivial apps)
Also, lambda engines (like AWS lambda) continuously improve their "java" target, with preloading and other things,which also benefits clojure.
TLDR; clojure startup isn't a thing that needs to be fixed. JVM startup used to be slow. And this is being resolved in the JVM itself.
Note: clojure DEV startup time is still slow-ish. Clojure DEV is usually not AOT compiled and etc. the new "sync deps" feature helps to solve this DEV problem
[+] [-] contrarian1234|1 year ago|reply
My personal favorite is add-libs
You can now write single file demos or minimal examples for issues. Really lowers the friction to share small runnable snippets with people
You can also actually use it to demo Java libraries as well without all the Java boilerplate. Just poke around in the REPL and paste code into a comment on HN or wherever and anyone can replicate your "setup" and get it running exactly the same. No need to clone a repo or anything
[+] [-] fire_lake|1 year ago|reply
[+] [-] didymospl|1 year ago|reply
[+] [-] pjmlp|1 year ago|reply
[+] [-] koito17|1 year ago|reply
Still waiting on spec2, though... for now I am working around rigidity of specs by using Malli but it really isn't a first-class citizen in Clojure (mostly due to inability to check macros, and this is by design of the Clojure compiler). But you can emulate the ideas of schema/select by manipulating malli schemas as data.
The changes for functional interfaces also means we no longer have to maintain utility macros like
and instead just pass functions directly.[+] [-] doubleg|1 year ago|reply
[+] [-] eduction|1 year ago|reply
[+] [-] jdminhbg|1 year ago|reply
[+] [-] puredanger|1 year ago|reply
[+] [-] diggan|1 year ago|reply
This release feels like it had a very different scope from previous releases, contains a lot of stuff, which is exciting to see! But I hope it doesn't end up like a hairball a few releases down from increase of pace or something.
[+] [-] _xiaz|1 year ago|reply
Rich Hickey and the rest of the Clojure Team are very careful designers. I wouldn't worry too much
[+] [-] eduction|1 year ago|reply
[+] [-] charlotte-fyi|1 year ago|reply
[+] [-] ledgerdev|1 year ago|reply
[+] [-] puredanger|1 year ago|reply
[+] [-] tgerdin|1 year ago|reply
[+] [-] haolez|1 year ago|reply
I'm not trying to troll. I want to choose it. It seems like a good engineering decision to me, but if it's nosediving in popularity and contributors, this might bite me back in the near future.
[0] https://www.clara-rules.org/
[+] [-] erichocean|1 year ago|reply
A major problem people have at first[0] is just reading the code. AIs like ChatGPT and Claude are incredibly good at explaining existing Clojure code.
As a result, developers can onboard much, much faster.
[0] After a few weeks, reading Clojure becomes second nature and you'll forget you ever COULDN'T read it.
[+] [-] pjmlp|1 year ago|reply
[+] [-] xxmarkuski|1 year ago|reply
[+] [-] puredanger|1 year ago|reply
The functional interface coercion is implemented with invokedynamic.
[+] [-] wiz21c|1 year ago|reply
[+] [-] uludag|1 year ago|reply
[1] https://youtu.be/2V1FtfBDsLU?feature=shared&t=639 [2] https://scicloj.github.io/ [3] https://github.com/HumbleUI/HumbleUI
[+] [-] rockyj|1 year ago|reply
[+] [-] delegate|1 year ago|reply
It can easily interop with Java and do the same stuff that Java does ('enterprise stuff' and more).
It excels at handling data transformations, so it's popular for tasks involving complex data pipelines, analysis, or real-time processing.
Clojure’s immutable data structures and concurrency story make it great for building highly concurrent systems, so things like financial services, real-time monitoring, event processing.
Clojurescript compiles to Javascript and interops with it well, so web based front end applications. It's used for mobile app development too.
There are libraries for AI/data sciences and there's python interop via library too, so you can build Clojure apps on top of Python libs.
Native-fast shell scripts using Babashka.
I would not use it for low level system programming (eg. where C is used), but for everything else - it would be one of my first choices.
It's a very pragmatic and practical programming language, with a strong philosophy behind every design decision and the fact that it can interop with pretty much everything makes it a powerful tool in skilled hands. Learning curve is quite steep though, but well worth climbing it.
[+] [-] ebiester|1 year ago|reply
NuBank, OneStudyTeam, CircleCI, and Guaranteed Rate are some of the larger companies I know about personally that have significant investments in Clojure.
[+] [-] zcam|1 year ago|reply
Pretty much anywhere where the jvm is a good fit, but given it’s a hosted language you can also use it to emit dart code or js and find it running on shoulders of others (like jank, llvm based dialect, or babashka)
[+] [-] sir_eliah|1 year ago|reply
[+] [-] erichocean|1 year ago|reply
$5M ARR. Two full-time developers.
[+] [-] kunley|1 year ago|reply
[+] [-] MarkMarine|1 year ago|reply
[+] [-] lebski88|1 year ago|reply
* No one was in love with Java. It was fine but we were doing the whole spring style super verbose Java and it felt like a lot of ceremony to get anything done. There had been an experiment with Scala previously but that hadn't taken off.
* We had a service-oriented architecture which meant we could try Clojure out on a few new services and see how it felt.
We ended up going from 2 services to moving the whole org over really quickly. A lot of excitement built up and people didn't want to be left out. At the end of things only 2 people decided they didn't want to learn Clojure.
A few other things we did:
* Bought loads of books and left them lying around
* Started a Clojure club where we booked an hour a week and did some exercises in Clojure
* Had a big meeting where we convinced everyone that Clojure was worth an experiment
* Brought in 3 consultants to do some Clojure training for everyone
* Probably strong armed everyone into watching simple made easy - it helped that lots of people had already seen it live that year
There are a few talks about it floating around although they are very very old now and I'm not sure they're worth the time!
https://whostolebenfrog.github.io/clojure,/deployments,/clou...
[+] [-] chii|1 year ago|reply
Ideally, use someone well versed in the tech stack - otherwise, you're taking on double risk of a new tech stack plus unfamiliarity. This prototype needs to demonstrate the value of the clojure stack - which has to have a business value (aka, speed/ease of maintenance etc).
Convince the decision makers to use clojure after the above prototype showed value, and use it to extrapolate value for other projects. This will then require a transition from doing the project, to teaching others (who might not know clojure at all). You cannot rely on just telling people to watch videos or read books - they won't do it, and it will cause failure in subsequent projects.
You will have to hand hold, until the newbie "clicks". Unfortuantely, this is an uphill battle, because management will always want to hire for the "regular/normal" tech stack, and will have trouble finding clojure-ready people. So the company will continue to have to invest in teaching it to new hires, which is a drain that could tank the clojure move.
[+] [-] bschwindHN|1 year ago|reply
I do like Rich's talks and agree that static typing can be taken a bit too far though.
ClojureScript in particular is much nicer to work with compared to JavaScript
[+] [-] lelag|1 year ago|reply
Forcing it on your team could create frustration, confusion, and a lot of resentment, not just toward the language, but possibly toward you. Sure, you might convert a person or two, but most will likely see it as unnecessary complexity.
If you really want to write Clojure every day, you might be better off finding a company that already embraces it instead of trying to turn your current team into Clojurists. Sometimes it’s better to enjoy something for yourself than to make it everyone else’s problem.
[+] [-] chr15m|1 year ago|reply
[+] [-] nbardy|1 year ago|reply
You can write code that looks a lot like Clojure in any modern language now, a lot of the functional primitives have been adopted in mainstream. e.g. Async/await => channels.
I started my career as a Clojure/Clojurescript developer 12 years ago. And now I do python for ML research and Typescript for prototyping all day.
Clojure honestly help me back a lot of the time because the tooling is so far behind the large programming communities. Functional programming has a lot of good ideas, but none good enough to leave behind all the packages on pip/npm.
I would only ever advise niche programming languages for small sub-teams that are highly technical were it makes a lot of sense. Something like compiler teams, webgl/triton for GPU programming, etc...
[+] [-] _xiaz|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] FranzFerdiNaN|1 year ago|reply
[+] [-] minikomi|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] lincpa|1 year ago|reply
[deleted]
[+] [-] anothername12|1 year ago|reply
[+] [-] diggan|1 year ago|reply
Clojure (and indirectly Java) was never created with "fast startup speed" in mind. This is why things like `add-lib` (that was added in this release) is so useful, because you start your developing session once, and it stays open until you either have to restart your computer or done developing the project.
Then the typical deployment target is either "Push this .jar to a server somehow, start the process and let it run" or "User double-clicks executable, waits for application to be ready".
If you really need fast startup, you can go through something like https://github.com/ionutbalosin/faster-jvm-start-up-techniqu...
Or if you're fine with slightly worse runtime performance, give https://github.com/babashka/babashka a try
Finally, if you're OK with JavaScript you could give ClojureScript a try, has fast startup (as fast as NodeJS I suppose) but yeah, it's JavaScript.
But overall, Clojure/Java isn't optimized for the use-case of "Start process for each request, stop process once processed" so I'm guessing you'll face an uphill battle there.
[+] [-] souenzzo|1 year ago|reply
But from java world: With GraalVM/NativeImage, it is possible to compile (clojure or java) .jar files into native binaries.
Those binaries have a way faster to startup (less than 10ms for non-trivial apps)
Also, lambda engines (like AWS lambda) continuously improve their "java" target, with preloading and other things,which also benefits clojure.
TLDR; clojure startup isn't a thing that needs to be fixed. JVM startup used to be slow. And this is being resolved in the JVM itself.
Note: clojure DEV startup time is still slow-ish. Clojure DEV is usually not AOT compiled and etc. the new "sync deps" feature helps to solve this DEV problem