Clojerl – Clojure for the Erlang VM

Post by macintux » Wed, Jun 19, 2019, 4:08 PM UTC

sbuttgereit wrote: post #82

macintux wrote: post #2

That’s very cool. I’ve added Clojerl to my list of alternative languages on the BEAM: https://gist.github.com/macintux/6349828#alternative-languag... Given the extent to which the Erlang VM is optimized for immutable data, network transparency, and message passing, I can see why Clojure on the JVM and CLR would not have had the same success with the actor model as Erlang has.

I like your list, but one thing that would be helpful for me is in the alternative languages available on the BEAM, make the distinction between those implementations which are "BEAM languages" vs those that are simply implemented on the BEAM. For example, Elixir is a proper BEAM language that targets the BEAM directly in a compile step.... but Luerl is not: Luerl is basically a Lua interpreter written in Erlang. I w…

Post by igouy » Wed, Jun 19, 2019, 4:30 PM UTC

chrisseaton wrote: post #88

igouy wrote: post #87

Earlier quoted context omitted.

> Why doesn't it have… Perhaps because it wasn't intended to be used for everything — "What sort of problems is Erlang not particularly suitable for? … Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic." h…

This seems like an argument being made backwards. > Most (all?) large systems developed using Erlang make heavy use of C for low-level code But they use C... because Erlang is too slow. Erlang isn't slow because they use C. This is actually an argument for the need to make Erlang faster - we've got proof it's not fast enough for what they want to do! And the worst thing is that when you start to use C code it's them…

Post by lliamander » Wed, Jun 19, 2019, 7:40 PM UTC

pron wrote: post #59

patrec wrote: post #57

Earlier quoted context omitted.

There is no doubt that JVM can provide massively better performance for a lot of stuff, but I wouldn't be suprised if Beam kicked JVM's butt in at least some areas. It's pretty much the only system I know of that provides for massive numbers of fairly scheduled, preemptive green threads. To do so it makes trade-offs that are not generally attractive, but I'd be surprised if it didn't beat the JVM here.

I would be. BEAM is just a very slow platform, not just compared to Java, but also compared to JavaScript and Go. Again, that's not to say it's not very useful for some things (although many Erlang apps are really mixed Erlang/C apps because of BEAM's performance). Hey, CPython is really slow, too and yet very useful. Green threads is another matter as it's not a feature that currently exists on the Java platform (th…

Post by yellowapple » Thu, Jun 20, 2019, 3:49 AM UTC

macintux wrote: post #2

That’s very cool. I’ve added Clojerl to my list of alternative languages on the BEAM: https://gist.github.com/macintux/6349828#alternative-languag... Given the extent to which the Erlang VM is optimized for immutable data, network transparency, and message passing, I can see why Clojure on the JVM and CLR would not have had the same success with the actor model as Erlang has.

Post by pdimitar » Thu, Jun 20, 2019, 2:39 PM UTC

valw wrote: post #47

tanzbaer wrote: post #3

Why would I use this over elixir?

Another reason might be the "cultural" aspects of Clojure, and their impacts on its ecosystem - in particular simplicity and stability are paramount, whereas the Elixir ecosystem seems to put more emphasis on immediate ease of use and elegance à la Ruby, at the cost of doing some "magical" designs which you tend to not see in the Clojure ecosystem.