9 ms·

The fact that Clojure runs on JVM turns me off. I find that Elixir is very similar to Coljure, with a runtime that better supports immutability and concurrency.

by erokar 7y ago

cabernal 7y ago
There is a version of Clojure that runs on BEAM: https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl
- arunix 7y ago
  Recently discussed here: https://news.ycombinator.com/item?id=20219563 https://news.ycombinator.com/item?id=20219563
jwr 7y ago
Why does it matter to you? I mean, I know why I find it to be a positive: implementing a runtime is a vast and complex task, and doing it well is way too expensive for most projects (see for example the problems Python has had over the years with the global interpreter lock). If you can use a runtime with gazillions of man-hours invested into making it better, and get easy access to bazillions of native libraries, why not?
- tdbgamer 7y ago
  While I agree with you that the JVM is great, I think most people that don't like it really just hate Oracle. It's not really a technical argument as much as it is philosophical. I don't really care either way, but I can see why people would mistrust Oracle knowing their history.
  - pjmlp 7y ago
    Yeah, because Sun never did wrong stuff and everyone was queuing up to buy it.
  - ilikehurdles 7y ago
    I switched to openJDK implementations after JDK 8 and lately that seems to be the way the entire community is going, due to Oracle’s new licensing restrictions.
  - jwr 7y ago
    I understand the sentiment, Oracle is a terrible company and I don't like it either. But at this point we have the OpenJDK and you can use the JVM without caring about Oracle at all.
  - balfirevic 7y ago
    I remember seeing complaints about Clojure running on JVM even before Oracle bought Sun.
- Veedrac 7y ago
  > If you can use a runtime with gazillions of man-hours invested into making it better, and get easy access to bazillions of native libraries, why not? Note that this same comment argues for Electron.
  - didibus 7y ago
    Yup, and there's ClojureScript for that one :p
- ken 7y ago
  As a Clojure user, I've only fairly recently moved from "the JVM is a boat-anchor on this design" to "the JVM is not an advantage, but it's not so terrible, either". So I'll answer. > a runtime with gazillions of man-hours invested into making it better, "Man-hours" are such a non-measure of productivity that the classic software engineering book in our industry has a title that declares them a "myth". The JVM turns out to work fine for functional languages like Clojure, but from my perspective, there's no inherent reason it necessarily should. There's a huge impedance mismatch, as Clojure is not much like Java, and the priorities are completely different. Bragging that some C program has had a gazillion people work on it means either it has a gazillion special cases (not an advantage), or it has a gazillion bugs fixed (most of which were probably caused by using a low-level unsafe language like C in the first place). Yay but ouch. (Implementing a new programming language is also typically a vast and complex task, but Clojure has an impressively small number of contributors. When you think through the design first and focus on simplicity, you don't need a gazillion special cases.) Coming from the Common Lisp world, there's gobs of pure-Lisp programs and libraries I've used which are absolutely a joy to work with, at every level. They don't need many contributors because the code is drastically shorter and simpler. There's lots of Lisp libraries with only a dozen commits, which haven't been touched in years, and a version number way less than 1.0, which work great. That's all they need. > and get easy access to bazillions of native libraries, I can see why these can be important when bootstrapping a new language environment, but in practice, beyond version 1.0, I really don't care about them at all. The interfaces I use from Clojure tend to be "return a function", or even "return a function which returns a function". No Java library is designed like this. They're designed around mutable classes, which makes them pretty awkward to use from a functional language. I'll go find a 100-line native Clojure library instead, and by now, there's 100-line native Clojure libraries for almost everything I need. For another example, the numeric tower is part of the core of Common Lisp, so it's usable from anywhere. BigInteger is a library in Java, and Java still doesn't seem to have rational or complex types, so Clojure does the best it can, but anything beyond fixnum arithmetic is basically opt-in, and almost no libraries use it. Debugging is even worse, because while there are a million google hits for "java library X", and a thousand hits for "lisp library Y", there's often almost no hits for "java library X with clojure". I have to mentally translate the Java X solutions into Clojure, and figure out any JVM/Clojure interop issues myself from first principles. That said, Clojure overall works great in practice, and for the most part you can ignore the JVM and its issues. But any time I'm forced to become aware that the JVM exists, my life ends up being worse than the equivalent scenario in the turtles-all-the-way-down world of other Lisps.
tdbgamer 7y ago
If you just hate the JVM, Clojure was designed in such a way that it could be hosted on many VMs which is nice. As others have pointed out, it can run on BEAM VM or even V8 with Clojurescript I believe.
dudul 7y ago
How is Elixir similar to Clojure? Their syntaxes are nothing alike, their core principles are not the same, not sure I follow. As for the JVM, I would be curious to know why it's a turn off. It has been worked on for decades and powers mission critical systems everywhere. Unless you are doing something where the size of the VM matters, or where GC as implemented in the JVM is a non-starter I'm not sure why it matters.
- vaer-k 7y ago
  They have a lot in common. They are both fringe languages that compile to run on more popular established VMs, both with strong support for meta programming, both encouraging a functional programming approach, and both employed to tackle roughly the same kinds of projects. The kind of people that are attracted to one are often also interested in the other. I think it's perfectly reasonable to draw comparisons.
  - cpursley 7y ago
    Closure and Elixir are hardly fringe languages... https://elixir-companies.com/en https://elixir-companies.com/en https://clojure.org/community/companies https://clojure.org/community/companies
    - vaer-k 7y ago
      They certainly are compared to say, Javascript or Python. There is nothing wrong with being fringe.
blunte 7y ago
Elixir and Clojure are much more different than they are alike. Having used both on projects, I found Clojure to be much faster to code with. But if you want all the great features that Erlang/BEAM provide, then Elixir is great.
garren 7y ago
I've only just started looking at Clojure and I've been a little leery about the JVM as well (Windows/.Net guy). However, my experience so far has been pretty positive, and it's given me a reason to get more familiar with Emacs. Additionally, there's a CLR version of Clojure as well [0] and I'm surprised that doesn't pop up very frequently. It seems to have a fairly active community around it as well [1]. I haven't looked into it yet, but I intend to once I'm more familiar with the JVM version. [0] https://github.com/clojure/clojure-clr https://github.com/clojure/clojure-clr [1] https://groups.google.com/forum/#!forum/clojure-clr https://groups.google.com/forum/#!forum/clojure-clr
- didibus 7y ago
  I feel the CLR version doesn't get as much love, because it doesn't really bring much over the JVM. It's a pretty comparable all around VM, with pretty much the same trade offs and use cases. I think that's part of it. And since the JVM one is always getting features first and has a more active community, there's little reason to try out the CLR one. That said, some do, and the maintainers are active, so I'm sure it works well if you had reason too.
1ark 7y ago
I think someone mentioned clojerl [1] already. There are alternative methodologies and languages that are similar to BEAM and Clojure otoh. Perhaps not comparable to BEAM when it comes to concurrency. Racket + ZeroMQ for those kind of problems, immutability and concurrency, is a very interesting combo though. Sidenote: You could run on Javascript runtimes with ClojureScript, but given your statement, I don't believe that is interesting to you :) [1] https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl
zmmmmm 7y ago
I'm curious about VM support for immutability. I think it's a really interesting idea whether low level runtime support can significantly enhance performance of immutable data structures - is that what you're suggesting? Would you be willing to expand on it? (My perspective: I am turned off by any language that doesn't have a JVM implementation because I have so much knowledge and trust of that runtime. But I have to acknowledge, byte-code level support for immutability is thin to non-existent).
iLemming 7y ago
When people complain about JVM, very often it turns out that they hate the first letter in it. I felt the same, for very long time I ignored Clojure because I hated "Java" part of JVM. It turns out - JVM in fact is a pretty solid piece of tech. And not once I had to deal with Java code since I started writing Clojure. Don't hate JVM because you don't like Java. Bashing on Java might be well reasoned, but hating JVM (most of the time) is completely baseless.

The fact that Clojure runs on JVM turns me off. I find that Elixir is very similar to Coljure, with a runtime that better supports immutability and concurrency.

by erokar 7y ago

The fact that Clojure runs on JVM turns me off. I find that Elixir is very similar to Coljure, with a runtime that better supports immutability and concurrency.

cabernal 7y ago

There is a version of Clojure that runs on BEAM: https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl

arunix 7y ago
Recently discussed here: https://news.ycombinator.com/item?id=20219563 https://news.ycombinator.com/item?id=20219563

jwr 7y ago

Why does it matter to you? I mean, I know why I find it to be a positive: implementing a runtime is a vast and complex task, and doing it well is way too expensive for most projects (see for example the problems Python has had over the years with the global interpreter lock). If you can use a runtime with gazillions of man-hours invested into making it better, and get easy access to bazillions of native libraries, why not?

tdbgamer 7y ago
While I agree with you that the JVM is great, I think most people that don't like it really just hate Oracle. It's not really a technical argument as much as it is philosophical. I don't really care either way, but I can see why people would mistrust Oracle knowing their history.
- pjmlp 7y ago
  Yeah, because Sun never did wrong stuff and everyone was queuing up to buy it.
- ilikehurdles 7y ago
  I switched to openJDK implementations after JDK 8 and lately that seems to be the way the entire community is going, due to Oracle’s new licensing restrictions.
- jwr 7y ago
  I understand the sentiment, Oracle is a terrible company and I don't like it either. But at this point we have the OpenJDK and you can use the JVM without caring about Oracle at all.
- balfirevic 7y ago
  I remember seeing complaints about Clojure running on JVM even before Oracle bought Sun.
Veedrac 7y ago
> If you can use a runtime with gazillions of man-hours invested into making it better, and get easy access to bazillions of native libraries, why not? Note that this same comment argues for Electron.
- didibus 7y ago
  Yup, and there's ClojureScript for that one :p
ken 7y ago
As a Clojure user, I've only fairly recently moved from "the JVM is a boat-anchor on this design" to "the JVM is not an advantage, but it's not so terrible, either". So I'll answer. > a runtime with gazillions of man-hours invested into making it better, "Man-hours" are such a non-measure of productivity that the classic software engineering book in our industry has a title that declares them a "myth". The JVM turns out to work fine for functional languages like Clojure, but from my perspective, there's no inherent reason it necessarily should. There's a huge impedance mismatch, as Clojure is not much like Java, and the priorities are completely different. Bragging that some C program has had a gazillion people work on it means either it has a gazillion special cases (not an advantage), or it has a gazillion bugs fixed (most of which were probably caused by using a low-level unsafe language like C in the first place). Yay but ouch. (Implementing a new programming language is also typically a vast and complex task, but Clojure has an impressively small number of contributors. When you think through the design first and focus on simplicity, you don't need a gazillion special cases.) Coming from the Common Lisp world, there's gobs of pure-Lisp programs and libraries I've used which are absolutely a joy to work with, at every level. They don't need many contributors because the code is drastically shorter and simpler. There's lots of Lisp libraries with only a dozen commits, which haven't been touched in years, and a version number way less than 1.0, which work great. That's all they need. > and get easy access to bazillions of native libraries, I can see why these can be important when bootstrapping a new language environment, but in practice, beyond version 1.0, I really don't care about them at all. The interfaces I use from Clojure tend to be "return a function", or even "return a function which returns a function". No Java library is designed like this. They're designed around mutable classes, which makes them pretty awkward to use from a functional language. I'll go find a 100-line native Clojure library instead, and by now, there's 100-line native Clojure libraries for almost everything I need. For another example, the numeric tower is part of the core of Common Lisp, so it's usable from anywhere. BigInteger is a library in Java, and Java still doesn't seem to have rational or complex types, so Clojure does the best it can, but anything beyond fixnum arithmetic is basically opt-in, and almost no libraries use it. Debugging is even worse, because while there are a million google hits for "java library X", and a thousand hits for "lisp library Y", there's often almost no hits for "java library X with clojure". I have to mentally translate the Java X solutions into Clojure, and figure out any JVM/Clojure interop issues myself from first principles. That said, Clojure overall works great in practice, and for the most part you can ignore the JVM and its issues. But any time I'm forced to become aware that the JVM exists, my life ends up being worse than the equivalent scenario in the turtles-all-the-way-down world of other Lisps.

tdbgamer 7y ago

If you just hate the JVM, Clojure was designed in such a way that it could be hosted on many VMs which is nice. As others have pointed out, it can run on BEAM VM or even V8 with Clojurescript I believe.

dudul 7y ago

How is Elixir similar to Clojure? Their syntaxes are nothing alike, their core principles are not the same, not sure I follow. As for the JVM, I would be curious to know why it's a turn off. It has been worked on for decades and powers mission critical systems everywhere. Unless you are doing something where the size of the VM matters, or where GC as implemented in the JVM is a non-starter I'm not sure why it matters.

vaer-k 7y ago
They have a lot in common. They are both fringe languages that compile to run on more popular established VMs, both with strong support for meta programming, both encouraging a functional programming approach, and both employed to tackle roughly the same kinds of projects. The kind of people that are attracted to one are often also interested in the other. I think it's perfectly reasonable to draw comparisons.
- cpursley 7y ago
  Closure and Elixir are hardly fringe languages... https://elixir-companies.com/en https://elixir-companies.com/en https://clojure.org/community/companies https://clojure.org/community/companies
  - vaer-k 7y ago
    They certainly are compared to say, Javascript or Python. There is nothing wrong with being fringe.

blunte 7y ago

Elixir and Clojure are much more different than they are alike. Having used both on projects, I found Clojure to be much faster to code with. But if you want all the great features that Erlang/BEAM provide, then Elixir is great.

garren 7y ago

I've only just started looking at Clojure and I've been a little leery about the JVM as well (Windows/.Net guy). However, my experience so far has been pretty positive, and it's given me a reason to get more familiar with Emacs. Additionally, there's a CLR version of Clojure as well [0] and I'm surprised that doesn't pop up very frequently. It seems to have a fairly active community around it as well [1]. I haven't looked into it yet, but I intend to once I'm more familiar with the JVM version. [0] https://github.com/clojure/clojure-clr https://github.com/clojure/clojure-clr [1] https://groups.google.com/forum/#!forum/clojure-clr https://groups.google.com/forum/#!forum/clojure-clr

didibus 7y ago
I feel the CLR version doesn't get as much love, because it doesn't really bring much over the JVM. It's a pretty comparable all around VM, with pretty much the same trade offs and use cases. I think that's part of it. And since the JVM one is always getting features first and has a more active community, there's little reason to try out the CLR one. That said, some do, and the maintainers are active, so I'm sure it works well if you had reason too.

1ark 7y ago

I think someone mentioned clojerl [1] already. There are alternative methodologies and languages that are similar to BEAM and Clojure otoh. Perhaps not comparable to BEAM when it comes to concurrency. Racket + ZeroMQ for those kind of problems, immutability and concurrency, is a very interesting combo though. Sidenote: You could run on Javascript runtimes with ClojureScript, but given your statement, I don't believe that is interesting to you :) [1] https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl

zmmmmm 7y ago

I'm curious about VM support for immutability. I think it's a really interesting idea whether low level runtime support can significantly enhance performance of immutable data structures - is that what you're suggesting? Would you be willing to expand on it? (My perspective: I am turned off by any language that doesn't have a JVM implementation because I have so much knowledge and trust of that runtime. But I have to acknowledge, byte-code level support for immutability is thin to non-existent).

iLemming 7y ago

When people complain about JVM, very often it turns out that they hate the first letter in it. I felt the same, for very long time I ignored Clojure because I hated "Java" part of JVM. It turns out - JVM in fact is a pretty solid piece of tech. And not once I had to deal with Java code since I started writing Clojure. Don't hate JVM because you don't like Java. Bashing on Java might be well reasoned, but hating JVM (most of the time) is completely baseless.