13 ms·

To be perfectly honest, Clojure's biggest mistake, from my point of view, was to be so heavily JVM-dependent. Yes, in certain environments Java is king and a t

To be perfectly honest, Clojure's biggest mistake, from my point of view, was to be so heavily JVM-dependent. Yes, in certain environments Java is king and a ton of people use it, it's battle-proven, etc. But so are other stacks. Clojure, as a programming language, sparks a lot of joy and is a lot of fun to use and reason about. Yet in reality, when working in a production environment, you're basically fighting the always-memory-hungry JVM. Just give me Clojure running on BEAM and I'll take it over anything in this world.

f3r3nc 7y ago
https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl
lincpa 7y ago
Clojure for the Erlang VM 1. clojerl language: https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl 2. kapok language: https://github.com/kapok-lang/kapok https://github.com/kapok-lang/kapok
- agumonkey 7y ago
  Thought the first was clojure on perl for a minute
  - vaylian 7y ago
    I also had to think for a moment until I realized what these links represent. More explanatory text would definitely have helped.
shivekkhurana 7y ago
ClojureScript can run on Node.js and the Browser.
- Touche 7y ago
  "can run" is much different from "the default environment". There's a big noticeable difference.
  - james-mcelwain 7y ago
    It's not "can run." ClojureScript is a fully supported and viable way to run Clojure in production.
pron 7y ago
> But so are other stacks. Not really. Few if any platforms compete with the JVM on performance and observability (monitoring/management) and ecosystem. It's technologically head and shoulders above pretty much all other runtimes (e.g. BEAM has excellent observability, but loses big time on performance and ecosystem). Also, if you're OK with the JVM running at BEAM speeds, you can give it far less memory.
- rhizome31 7y ago
  > Also, if you're OK with the JVM running at BEAM speeds, you can give it far less memory. I'm curious about this. How do you do it in practice? Doesn't it just crash with OutOfMemory errors when it runs out of memory?
  - bad_user 7y ago
    The JVM doesn't use more memory than other virtual machines, the problem is that it doesn't release memory back to the operating system, which is why it is being configured with a maximum heap size. Also compacting garbage collectors need more memory available for de-fragmenting the heap. I've been running a simple JVM web app on my own personal server with an allocated 128 MB of RAM and a lot of that is actually unused. You can do a lot with a heap of just 64 MB. People aren't aware, but when running your average PHP app you need more than that with just a couple of requests done at the same time, whereas my JVM server can easily handle 1000 requests per second. Similarly Ruby or Python apps can be big resource hogs, especially when you end up setting up multiple parallel processes. I was also surprised to find that compilation to "native" isn't necessarily efficient in terms of used memory. I've built a similar app in Haskell and the used memory ended up being higher and more unpredictable. If something like Go fares better, it's not because it is compiled to native. All in all the JVM is actually quite efficient in terms of used memory, for a garbage collected language ;-)
    - brazzy 7y ago
      > The JVM doesn't use more memory than other virtual machines, the problem is that it doesn't release memory back to the operating system This is untrue. The default configuration is just to do it very reluctantly, but this can be changed.
rhizome31 7y ago
> Just give me Clojure running on BEAM and I'll take it over anything in this world. Isn't it more or less what Elixir is?
- weavejester 7y ago
  Isn't Elixir more like Ruby on BEAM?
  - dragonwriter 7y ago
    Substantively, to me, it seems more similar to Clojure than Ruby, though it has a superficial syntactic resemblance to Ruby.
  - jb3689 7y ago
    It's more like Erlang with syntactic sugar and macros. Phoenix and Rails have more in common than Elixir and Ruby do
  - nathan_long 7y ago
    As a Ruby dev turned Elixir dev: no. I mean, they both have `do..end` blocks, which I don't love in either language. But the similarities pretty much end there. Here's the view of someone who went from Erlang to Elixir: https://www.theerlangelist.com/article/why_elixir https://www.theerlangelist.com/article/why_elixir
- iLemming 7y ago
  The biggest disadvantage of Elixir today - it doesn't have its own thing comparable with Clojurescript. Clojurescript is not just extremely nice compiler that gives you syntactic sugar, you can totally share code between JVM and JS and that's incredibly awesome.
hota_mazi 7y ago
I think it's the other way around: Clojure gained more exposure than past Lisps because it runs on the JVM. But it's still definitely niche and hardly used anywhere.
- ken 7y ago
  ABCL runs on the JVM and is about the same age as Clojure, and isn’t anywhere near as popular.
  - i_feel_great 7y ago
    Kawa (https://www.gnu.org/software/kawa/ https://www.gnu.org/software/kawa/) is even better, and I only ever came across one other person who has ever heard of it.
    - ken 7y ago
      Right, I'd forgotten about that! I used it as an extension language for a Java program once. I didn't think it even had a compiler, but that was 20 years ago, and it appears to have one now.
      - brlewis 7y ago
        It has always been a compiler. The REPL works by compiling expressions when you type them.
    - th0ma5 7y ago
      Kawa was my first Lisp / Scheme and I dug it quite a bit. I wrote some wrappers for Processing called ProKawa which probably doesn't work with the latest Processing releases, but it was all very fun. Quil on Clojure is pretty good, and in general I'd say I've gotten more milage out of Clojure for sure.
  - mschaef 7y ago
    A lot of credit for that goes to Rich Hickey - from what I can tell, he did a very successful job early on of 1) designing a Lisp with a unique combination of ideas and 2) publicizing it in a way that resonated with a people.
oddthink 7y ago
I don't know if JVM is a problem; the issue that caught me in my few-weeks of experimenting with the language was the lazy semantics of sequences. I know the problem, and I've danced around this same issue in things like Haskell with strictness annotations, and I've run into the same problem in R, but I'd like to just be able to read and parse a ~1GB CSV file without blowing out RAM with a giant list of thunks. This was many years ago now, so maybe they've fixed it, but I'm tired of fighting that particular battle.
- didibus 7y ago
  Ya, this has been completely fixed. There's now fully lazy as well as fully strict variants of all sequence functions. What you want to look into are transducers: https://clojure.org/reference/transducers https://clojure.org/reference/transducers Also, the lazy operations were made batching. So they are better optimized now in memory and performance.
mschaef 7y ago
> To be perfectly honest, Clojure's biggest mistake, from my point of view, was to be so heavily JVM-dependent. IMHO, Clojure's use of the JVM was something of a Faustian bargain. (But net worthwhile). Reasonable people might disagree, but there is a huge amount of value in having access to a good JIT, GC, and standard library - not to mention the ecosystem around the JVM. Keeping in mind that Clojure started out as a one-person, self-funded project, it was a very reasonable thing to borrow all of this from an existing well-established language. Maybe these things could've been reproduced, but not in the approx. two years that were initially available, and it's not at all clear that building a JIT, GC, etc. would have been the best road to making a useful impact.
bad_user 7y ago
What is BEAM?
- godfried 7y ago
  Erlang VM: https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine) https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine)
- ballpark 7y ago
  yeah BEAM didn't google well
hden 7y ago
The same can be said about WebAssembly. But we needs to first figure out how to implement GC.
i_feel_great 7y ago
Alas, it looks like it hasn't had much love since 2014: https://github.com/the-concurrent-schemer/scm https://github.com/the-concurrent-schemer/scm
Touche 7y ago
If we look at it from a historical perspective, Clojure came about at the end of the Java and Ruby eras where running big long-lasting programs was the norm. It was about 2 years later that Node.js, Go, and then Rust came about. These languages specialized in faster startup times, which made them more amenable to a variety of use-cases (where Java and Ruby were mostly used as web servers). If we just look at developments of the last 5 years, and in particular serverless, it's been about taking advantage of those short startup times to use in a server context. When you take that into account, these languages become even more in the lead. I think the next lisp that has a chance to really take of will be one built on wasm.
- zimablue 7y ago
  Couldn't you just compile cljs=>js=>wasm? cljs is mostly the same language right
  - yogthos 7y ago
    You absolutely can, and you can compile JVM Clojure to native binaries via GraalVM. For example, somebody wrapped up my Migratus library into a standalone migration tool recently https://github.com/leafclick/pgmig https://github.com/leafclick/pgmig
- tellak 7y ago
  Don’t really agree with the history. MRI ruby had always had a fast startup time and was not originally created for the web... it’s more like a “better” Perl cum toolkit for C/unixy stuff- ironically what python became more popular for despite python not originally being written for that purpose. Also in the old days of the web.. CGI was literally spawning a process per request. Regardless it’s bizarre to think nodejs pioneered startup time... Ruby, lua, python, and good lord Perl would really like to have a word with you for starters. Java was really more the exception. And I’m not sure it’s true that these serverless platforms are spawning a new process per request ... but wow what is old is new again. Sounds like you’re describing inetd (look it up). Nothing of what you’re talking about is 5 years. Try 30-40.
namelosw 7y ago
I always believe the exact same thing. Immutability and dynamic typing make it perfectly suited for BEAM. BEAM is also more suited for Clojure. Less powerful CSP and awkward component would be replaced by the actor and supervision tree.
pwinnski 7y ago
As someone who has done some Clojure, including some smaller projects in production at a big company, Clojure running on BEAM would have been a complete non-starter. It's really easy to introduce Clojure into a Java shop, because if things go south, you can throw away a bit of code and replace it with Java. Heck, people on other teams don't even have to know this started as Clojure code. Asking people to learn both a new way of developing and a new VM? Too much all at once, which is why Clojure spread as far as quickly as it did.
maxgiraldo 7y ago
> To be perfectly honest, Clojure's biggest mistake, from my point of view, was to be so heavily JVM-dependent. With Clojure being a hosted language, there's nothing stopping it from adopting a new platform or expanding to other platforms or languages. It has actually already done this with Clojurescript (run in the browser or Node.js)[1] and Clojure CLR (run on Microsoft's .NET)[2]. [1] https://clojurescript.org/ https://clojurescript.org/ [2] https://clojure.org/about/clojureclr https://clojure.org/about/clojureclr
didibus 7y ago
> Just give me Clojure running on BEAM and I'll take it over anything in this world. That already exists: http://try.clojerl.online http://try.clojerl.online It's a community maintained dialect. Its maintainer, Juan Facorro is very active. You can see him giving a talk about it here: https://youtu.be/Ow8o9Mm_N7M https://youtu.be/Ow8o9Mm_N7M I'm sure all the project is in need of are more adopters to really get it off the ground. Check it out!
DannyB2 7y ago
JVM has two new open source garbage collector implementations that are designed for TERABYTES of heap space with 10 ms GC pause times. (yes you read that correctly) ZGC from Oracle -- but open source Shenandoah from Red Hat -- also open source I know of no other managed runtime platform with the GC options and tunability as JVM. Also JVM has not one, but TWO JIT compilers, C1 and C2. Your JVM byte code starts out interpreted. It is constantly dynamically performance profiled. If it is getting above average CPU use then it is quickly compiled by C1 into native code, and scheduled to be recompiled soon later by C2. When C2 comes along, it takes its time recompiling your code into highly optimized native code. Suppose that YOUR function A calls MY function B. And C2 aggressively inlined my B function into your A function. Now suppose my code is dynamically reloaded within the running environment. Now your function has a stale version of my code inlined within. JVM will instantly de-optimize your code back to JVM byte code interpretation so that soon, if it is still a cpu hot spot, it will get recompiled again by C1 and C2. Let me know of any other runtime platform that even comes close to the things JVM does.
- User23 7y ago
  > Let me know of any other runtime platform that even comes > close to the things JVM does. Some of the more advanced Lisps would qualify.
  - pron 7y ago
    No Lisp runtime currently has this quality of JIT compilers, GCs, and observability.
    - madmax96 7y ago
      You should check out SBCL, it's competitive.
      - pron 7y ago
        It isn't. Perhaps you haven't seen what the JVM can do lately. It's got JIT compilers that do this[1], GCs that are getting close to 1ms max pause times on terabytes of heap [2], and low-overhead, in-production deep profiling [3]. Not to mention all of the classic capabilities of the JVM like hot code redefinition and exceptional monitoring. Lots of applications can certainly manage well without some or even all those things, and some want other tradeoffs (like no warmup or lower RAM footprint), but these days it's hard to compete with the JVM where it's strong. The technological gap between it and other runtimes is only growing. [1]: https://twitter.com/ChrisGSeaton/status/619885182104043520 https://twitter.com/ChrisGSeaton/status/619885182104043520 [2]: http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pdf http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pd... [3]: https://craftingjava.com/using-java-flight-recorder-with-openjdk-11/ https://craftingjava.com/using-java-flight-recorder-with-ope...
neilv 7y ago
From what I recall of Clojure's launch and the reactions I heard from people, the JVM aspect might've been 1/3 to 1/2 of the attraction to CL people: Java was more widely popular at the time, and Clojure said "here's our angle to get more people paid to Lisp". My self-interested perspective on Clojure today (as an expert in a couple other Lisp niches) is that I'd be happy to learn Clojure if someone would pay me to, but it's not relatively attractive to me now, in the ways that a Lisp is more attractive than a non-Lisp. (Nor in the way that Rust is in some ways more attractive than C and C++. I've been a senior developer in those, and Rust is sufficiently different, and might open some new doors.)
rcarmo 7y ago
I’ve played with LFE (http://lfe.io http://lfe.io) and found it quite enjoyable, but it isn’t Clojure and requires some understanding of Erlang-and some getting used to.

f3r3nc 7y ago

https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl

lincpa 7y ago

Clojure for the Erlang VM 1. clojerl language: https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl 2. kapok language: https://github.com/kapok-lang/kapok https://github.com/kapok-lang/kapok

agumonkey 7y ago
Thought the first was clojure on perl for a minute
- vaylian 7y ago
  I also had to think for a moment until I realized what these links represent. More explanatory text would definitely have helped.

shivekkhurana 7y ago

ClojureScript can run on Node.js and the Browser.

Touche 7y ago
"can run" is much different from "the default environment". There's a big noticeable difference.
- james-mcelwain 7y ago
  It's not "can run." ClojureScript is a fully supported and viable way to run Clojure in production.

pron 7y ago

> But so are other stacks. Not really. Few if any platforms compete with the JVM on performance and observability (monitoring/management) and ecosystem. It's technologically head and shoulders above pretty much all other runtimes (e.g. BEAM has excellent observability, but loses big time on performance and ecosystem). Also, if you're OK with the JVM running at BEAM speeds, you can give it far less memory.

rhizome31 7y ago
> Also, if you're OK with the JVM running at BEAM speeds, you can give it far less memory. I'm curious about this. How do you do it in practice? Doesn't it just crash with OutOfMemory errors when it runs out of memory?
- bad_user 7y ago
  The JVM doesn't use more memory than other virtual machines, the problem is that it doesn't release memory back to the operating system, which is why it is being configured with a maximum heap size. Also compacting garbage collectors need more memory available for de-fragmenting the heap. I've been running a simple JVM web app on my own personal server with an allocated 128 MB of RAM and a lot of that is actually unused. You can do a lot with a heap of just 64 MB. People aren't aware, but when running your average PHP app you need more than that with just a couple of requests done at the same time, whereas my JVM server can easily handle 1000 requests per second. Similarly Ruby or Python apps can be big resource hogs, especially when you end up setting up multiple parallel processes. I was also surprised to find that compilation to "native" isn't necessarily efficient in terms of used memory. I've built a similar app in Haskell and the used memory ended up being higher and more unpredictable. If something like Go fares better, it's not because it is compiled to native. All in all the JVM is actually quite efficient in terms of used memory, for a garbage collected language ;-)
  - brazzy 7y ago
    > The JVM doesn't use more memory than other virtual machines, the problem is that it doesn't release memory back to the operating system This is untrue. The default configuration is just to do it very reluctantly, but this can be changed.

rhizome31 7y ago

> Just give me Clojure running on BEAM and I'll take it over anything in this world. Isn't it more or less what Elixir is?

weavejester 7y ago
Isn't Elixir more like Ruby on BEAM?
- dragonwriter 7y ago
  Substantively, to me, it seems more similar to Clojure than Ruby, though it has a superficial syntactic resemblance to Ruby.
- jb3689 7y ago
  It's more like Erlang with syntactic sugar and macros. Phoenix and Rails have more in common than Elixir and Ruby do
- nathan_long 7y ago
  As a Ruby dev turned Elixir dev: no. I mean, they both have `do..end` blocks, which I don't love in either language. But the similarities pretty much end there. Here's the view of someone who went from Erlang to Elixir: https://www.theerlangelist.com/article/why_elixir https://www.theerlangelist.com/article/why_elixir
iLemming 7y ago
The biggest disadvantage of Elixir today - it doesn't have its own thing comparable with Clojurescript. Clojurescript is not just extremely nice compiler that gives you syntactic sugar, you can totally share code between JVM and JS and that's incredibly awesome.

hota_mazi 7y ago

I think it's the other way around: Clojure gained more exposure than past Lisps because it runs on the JVM. But it's still definitely niche and hardly used anywhere.

ken 7y ago
ABCL runs on the JVM and is about the same age as Clojure, and isn’t anywhere near as popular.
- i_feel_great 7y ago
  Kawa (https://www.gnu.org/software/kawa/ https://www.gnu.org/software/kawa/) is even better, and I only ever came across one other person who has ever heard of it.
  - ken 7y ago
    Right, I'd forgotten about that! I used it as an extension language for a Java program once. I didn't think it even had a compiler, but that was 20 years ago, and it appears to have one now.
    - brlewis 7y ago
      It has always been a compiler. The REPL works by compiling expressions when you type them.
  - th0ma5 7y ago
    Kawa was my first Lisp / Scheme and I dug it quite a bit. I wrote some wrappers for Processing called ProKawa which probably doesn't work with the latest Processing releases, but it was all very fun. Quil on Clojure is pretty good, and in general I'd say I've gotten more milage out of Clojure for sure.
- mschaef 7y ago
  A lot of credit for that goes to Rich Hickey - from what I can tell, he did a very successful job early on of 1) designing a Lisp with a unique combination of ideas and 2) publicizing it in a way that resonated with a people.

oddthink 7y ago

I don't know if JVM is a problem; the issue that caught me in my few-weeks of experimenting with the language was the lazy semantics of sequences. I know the problem, and I've danced around this same issue in things like Haskell with strictness annotations, and I've run into the same problem in R, but I'd like to just be able to read and parse a ~1GB CSV file without blowing out RAM with a giant list of thunks. This was many years ago now, so maybe they've fixed it, but I'm tired of fighting that particular battle.

didibus 7y ago
Ya, this has been completely fixed. There's now fully lazy as well as fully strict variants of all sequence functions. What you want to look into are transducers: https://clojure.org/reference/transducers https://clojure.org/reference/transducers Also, the lazy operations were made batching. So they are better optimized now in memory and performance.

mschaef 7y ago

> To be perfectly honest, Clojure's biggest mistake, from my point of view, was to be so heavily JVM-dependent. IMHO, Clojure's use of the JVM was something of a Faustian bargain. (But net worthwhile). Reasonable people might disagree, but there is a huge amount of value in having access to a good JIT, GC, and standard library - not to mention the ecosystem around the JVM. Keeping in mind that Clojure started out as a one-person, self-funded project, it was a very reasonable thing to borrow all of this from an existing well-established language. Maybe these things could've been reproduced, but not in the approx. two years that were initially available, and it's not at all clear that building a JIT, GC, etc. would have been the best road to making a useful impact.

bad_user 7y ago

What is BEAM?

godfried 7y ago
Erlang VM: https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine) https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine)
ballpark 7y ago
yeah BEAM didn't google well

hden 7y ago

The same can be said about WebAssembly. But we needs to first figure out how to implement GC.

i_feel_great 7y ago

Alas, it looks like it hasn't had much love since 2014: https://github.com/the-concurrent-schemer/scm https://github.com/the-concurrent-schemer/scm

Touche 7y ago

If we look at it from a historical perspective, Clojure came about at the end of the Java and Ruby eras where running big long-lasting programs was the norm. It was about 2 years later that Node.js, Go, and then Rust came about. These languages specialized in faster startup times, which made them more amenable to a variety of use-cases (where Java and Ruby were mostly used as web servers). If we just look at developments of the last 5 years, and in particular serverless, it's been about taking advantage of those short startup times to use in a server context. When you take that into account, these languages become even more in the lead. I think the next lisp that has a chance to really take of will be one built on wasm.

zimablue 7y ago
Couldn't you just compile cljs=>js=>wasm? cljs is mostly the same language right
- yogthos 7y ago
  You absolutely can, and you can compile JVM Clojure to native binaries via GraalVM. For example, somebody wrapped up my Migratus library into a standalone migration tool recently https://github.com/leafclick/pgmig https://github.com/leafclick/pgmig
tellak 7y ago
Don’t really agree with the history. MRI ruby had always had a fast startup time and was not originally created for the web... it’s more like a “better” Perl cum toolkit for C/unixy stuff- ironically what python became more popular for despite python not originally being written for that purpose. Also in the old days of the web.. CGI was literally spawning a process per request. Regardless it’s bizarre to think nodejs pioneered startup time... Ruby, lua, python, and good lord Perl would really like to have a word with you for starters. Java was really more the exception. And I’m not sure it’s true that these serverless platforms are spawning a new process per request ... but wow what is old is new again. Sounds like you’re describing inetd (look it up). Nothing of what you’re talking about is 5 years. Try 30-40.

namelosw 7y ago

I always believe the exact same thing. Immutability and dynamic typing make it perfectly suited for BEAM. BEAM is also more suited for Clojure. Less powerful CSP and awkward component would be replaced by the actor and supervision tree.

pwinnski 7y ago

As someone who has done some Clojure, including some smaller projects in production at a big company, Clojure running on BEAM would have been a complete non-starter. It's really easy to introduce Clojure into a Java shop, because if things go south, you can throw away a bit of code and replace it with Java. Heck, people on other teams don't even have to know this started as Clojure code. Asking people to learn both a new way of developing and a new VM? Too much all at once, which is why Clojure spread as far as quickly as it did.

maxgiraldo 7y ago

> To be perfectly honest, Clojure's biggest mistake, from my point of view, was to be so heavily JVM-dependent. With Clojure being a hosted language, there's nothing stopping it from adopting a new platform or expanding to other platforms or languages. It has actually already done this with Clojurescript (run in the browser or Node.js)[1] and Clojure CLR (run on Microsoft's .NET)[2]. [1] https://clojurescript.org/ https://clojurescript.org/ [2] https://clojure.org/about/clojureclr https://clojure.org/about/clojureclr

didibus 7y ago

> Just give me Clojure running on BEAM and I'll take it over anything in this world. That already exists: http://try.clojerl.online http://try.clojerl.online It's a community maintained dialect. Its maintainer, Juan Facorro is very active. You can see him giving a talk about it here: https://youtu.be/Ow8o9Mm_N7M https://youtu.be/Ow8o9Mm_N7M I'm sure all the project is in need of are more adopters to really get it off the ground. Check it out!

DannyB2 7y ago

JVM has two new open source garbage collector implementations that are designed for TERABYTES of heap space with 10 ms GC pause times. (yes you read that correctly) ZGC from Oracle -- but open source Shenandoah from Red Hat -- also open source I know of no other managed runtime platform with the GC options and tunability as JVM. Also JVM has not one, but TWO JIT compilers, C1 and C2. Your JVM byte code starts out interpreted. It is constantly dynamically performance profiled. If it is getting above average CPU use then it is quickly compiled by C1 into native code, and scheduled to be recompiled soon later by C2. When C2 comes along, it takes its time recompiling your code into highly optimized native code. Suppose that YOUR function A calls MY function B. And C2 aggressively inlined my B function into your A function. Now suppose my code is dynamically reloaded within the running environment. Now your function has a stale version of my code inlined within. JVM will instantly de-optimize your code back to JVM byte code interpretation so that soon, if it is still a cpu hot spot, it will get recompiled again by C1 and C2. Let me know of any other runtime platform that even comes close to the things JVM does.

User23 7y ago
> Let me know of any other runtime platform that even comes > close to the things JVM does. Some of the more advanced Lisps would qualify.
- pron 7y ago
  No Lisp runtime currently has this quality of JIT compilers, GCs, and observability.
  - madmax96 7y ago
    You should check out SBCL, it's competitive.
    - pron 7y ago
      It isn't. Perhaps you haven't seen what the JVM can do lately. It's got JIT compilers that do this[1], GCs that are getting close to 1ms max pause times on terabytes of heap [2], and low-overhead, in-production deep profiling [3]. Not to mention all of the classic capabilities of the JVM like hot code redefinition and exceptional monitoring. Lots of applications can certainly manage well without some or even all those things, and some want other tradeoffs (like no warmup or lower RAM footprint), but these days it's hard to compete with the JVM where it's strong. The technological gap between it and other runtimes is only growing. [1]: https://twitter.com/ChrisGSeaton/status/619885182104043520 https://twitter.com/ChrisGSeaton/status/619885182104043520 [2]: http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pdf http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pd... [3]: https://craftingjava.com/using-java-flight-recorder-with-openjdk-11/ https://craftingjava.com/using-java-flight-recorder-with-ope...

neilv 7y ago

From what I recall of Clojure's launch and the reactions I heard from people, the JVM aspect might've been 1/3 to 1/2 of the attraction to CL people: Java was more widely popular at the time, and Clojure said "here's our angle to get more people paid to Lisp". My self-interested perspective on Clojure today (as an expert in a couple other Lisp niches) is that I'd be happy to learn Clojure if someone would pay me to, but it's not relatively attractive to me now, in the ways that a Lisp is more attractive than a non-Lisp. (Nor in the way that Rust is in some ways more attractive than C and C++. I've been a senior developer in those, and Rust is sufficiently different, and might open some new doors.)

rcarmo 7y ago

I’ve played with LFE (http://lfe.io http://lfe.io) and found it quite enjoyable, but it isn’t Clojure and requires some understanding of Erlang-and some getting used to.