I was at a talk by Guy Steele where he mentioned in passing that Clojure was a Lisp which had done everything right. This was all the more impressive to him because Rich Hickey had until then been a relative outsider to the Lisp/Scheme community.
This also means that sometimes things do not seem as "beautiful" as one might like. Well, that's because they aren't. There is no way to sugarcoat certain things without making the language less practical, and Clojure seems to have been designed with no sugarcoating in mind.
Incidentally, I love this quote from Rich, an answer to people complaining that Clojure isn't easy to learn: "Instruments are made for people who can play them". I've grown to appreciate that over the years. You don't expect to be able to sit at a piano of a particular brand and just start playing it.
babashka is a little interpreter that implements large portions of "scripting Clojure" so you can write tiny Clojure scripts the way you'd write bash or Python.
GraalVM's native image is a Serious Compiler (unfortunately also with Serious RAM appetite and compile times, though this has gotten much better over the last few months) that will produce native binaries on Windows, macOS and Linux.
I recently was looking for something like this and I also found Planck, Lumo, and Eden.
Do you (or anyone) know of a comparison between them?
By all accounts, though, Clojure became as popular as it is because of the JVM, not despite it.
1) The original one, developed by Rich Hickey in 2005-2007, which he deleted before releasing Clojure
2) The second one, known as ClojureCLR, which David Miller developed in 2008 from the ClojureJVM.
https://soundcloud.com/defn-771544745/48-david-miller-and-cl...
How he describes information systems, in that world, JVM is an amazing piece of technology that can hardly be surpassed.
But today, the programming landscape goes far beyond that. ML and Data Science, infrastructure automation, serverless, etc.
I also work in the world of enterprise information systems, so I'm always surprised about people saying the JVM doesn't work well for them. For me the JVM is the best piece of tech out there, only matched by the CLR. Even Go isn't up to par yet.
But I reckon, other use cases value different execution characteristics. Low memory footprint is more important than raw performance. Throughput is more important than latency. Binary size is more important than portability. Startup times is more important than runtimes. Etc.
Well the good news is that Clojure is meant to be hosted. And the JVM is only one of its many hosts. ClojureScript can run on NodeJS, eventually Deno, it can run on JavaScriptCore and in the browser. All these offer alternative execution models which can meet a new set of requirements.
Clojure CLR is still real and robust, while it hasn't seen much use, it is ready at any time to take over. If the CLR provides to fulfill alternative execution characteristics it would be an option. Right now, the CLR has pretty much the same characteristics as the JVM though, which is why its use in Clojure hasn't seen a lot of popularity.
Babashka and Joker are Clojure based runtimes, interpreters really, so exactly the same as what Python and Ruby offer. Babashka especially is picking up pace, and already starting to offer a really compelling set of alternate execution characteristics, specifically one where startup time trumps all.
I'm also quite fascinated by Clojerl, a Erlang hosted Clojure. While less official, the maintainer is very active, and I feel it's actually now ready to be used in production.
And there are more, smaller ones, but I'll skip those.
What this shows is the landscape of possible runtimes is vast and will just keep expanding. Right now lots of experiment in having a Clojure hosted on Go, on Common Lisp, on Rust, etc.
This a testament to Rich's hosted design. Clojure is easy to build on top of other runtimes. This ease really helps it grow and reach more use case.
And there's the fact that the JVM is only getting better. GraalVM already offers native binaries with a small memory footprint, small binary, fast startup and still pretty fast performance. There are so many new garbage collectors coming along. Some for large heaps, small heaps, no heaps, tuned to throughout, latency, low memory, large memory, etc.
P.S.: Also, I really urge you to reconsider a JVM. The truth is, it's such a powerful piece of technology that it can be hard to navigate and understand even what all it can do. I believe a lot of people are turned off by that and choose to use Go or Python because they have only one easy mode of operation. But the JVM can do so much, it's a worthy investment, it's very possible it has what you actually need.
For example, you no longer need to install a JVM. Apps are self-contained. The user doesn't have to install a JVM, and the bundle contains only what the app uses, not the whole JVM. And as mentioned, compiled native binaries are also a possibility now.
i stand corrected :)
As another, less flippant, example, Julia will typically beat Java in most long-running algorithms (but probably not time-to-first-x), because it doesn't have a well-optimized-for-compilation-speed compiler, but it does have a better-optimized-for-running-speed compiler for many scientific tasks. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Don't think that's really accurate.
You don't have to use C with Python, and there's no VM to worry about. CPython* just happens to be the most popular implementation.
Clojure (by and large)* requires the whole Java infrastructure, and that is a nonstarter for many.
There are Clojure implementations that run on JS runtimes, the .Net CLR, the Erlang BEAM runtime, etc.
CPython comes with its own VM: are you saying the issue is "you need to install 2 things instead of 1"?
I think, though, that the things that Clojure gets right go way beyond just the JVM, though. Clojure's approach to nil punning, for example, is really well thought out.
I don't have anything against Clojure (well, I'm a little negative on the JVM), but I personally don't see any reason to move to it from Common Lisp.
On the other hand, I'd miss CLOS, and I feel like CL has a better/more consistent design. Something about Clojure always feels like they're "winging it".
In a nutshell, nil punning is a thing in lisps (and some other languages) where the null value can have different meanings in different contexts. It's comparable to Python's concept of "truthiness" and "falsiness", but more so.