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 would expect different trade-offs from Elixir vs. Luerl as such. For example, I have a project where I need a limited, embedded scripting environment inside of an otherwise Elixir project. Using a BEAM language seems to be difficult to impose the desired limitations for such scripting environment, but in Luerl it seems I can do just that... limiting the scripting to a-less-than-system-wide scope. Of course... I expect a fairly substantial performance penalty for that... but trade-offs :-).
Benchmarking Clojure (both JVM and JS) vs Erlang immutable data structures would be very interesting given the focus on clever implemeations (persistent data structures) on the Clojure side and the VM level specialization on the Erlang side.
Interesting! I posted Erjang (JVM based Erlang VM)[0] a few days ago, I guess I missed this one. I have a fascination with both Erlang and Lisp. I love Erlang because it is definitely a back-end language. I also love it's resiliency. I like how expressive Lisp languages can be. So maybe we'll just run Clojerl on top of Erjang, which is on the JVM, and Clojerl is based on a JVM language, talk about an onion.
Putting an Erlang-like language on the JVM would really lose all the advantages of Erlang, wouldn't it. The syntax, while very useful, isn't the real strength of the language. It's the BEAM.
You should play with them both, and see what you like more. I don't feel like one is objectively "better" than the other, it's mostly a matter of preference.
I personally like LFE a bit better, because of the more-direct mappings to BEAM (as you mentioned). Lisp-Flavoured-Erlang is a very honest name; it feels like you're writing Erlang, just a nice and consistent Lisp syntax.
That said, I think Clojerl is pretty neat. I tend to find Clojure's macro syntax a bit cleaner than LFE's Common-Lisp style (I still get tripped up on commas). Also, Lisp-1 semantics are a lot more reasonable...I still hate putting `funcall`s everywhere.
I'm a shallow Clojure user, I like Clojure but every time I look into 'modern' Clojure code base I would see a lot stuartsierra/component. I know this is quite a library with high quality, but it's more like a sign of compromise - 'we still need stateful component eventually, although we already have 5 different ways to deal with the state, we need another one'.
Despite what Rich said about Actors, the state in Erlang/OTP is more well-modeled. The state(process mechanism) is not only playing well with immutable functional languages but also much more robust than OO languages. And it also largely simpifies the mental model - it removes the need of atom/agent/variable/object, etc.
Another neat thing, of course, no awkward loop/recur anymore.
i especially like the QA section explaining "why do it if Hickey said actors are bad" (intentional strawman there):
> The points he makes are of course very good. For example, when no state is shared between processes there is some communication overhead, but this isolation is also an advantage under a lot of circumstances. He also mentions here that building for the distributed case (a.k.a processes and message passing) is more complex and not always necessary, so he decided to optimise for the non-distributed case and add distribution to the parts of the system that need it. Rich Hickey calls Erlang "quite impressive", so my interpretation of these writings is that they are more about exposing the rationale behind the decisions and the trade-offs he made when designing Clojure (on the JVM), than about disregarding the actor model.
That would be my understanding as well. Clojure and Erlang are ideologically quite close, just made with slightly different purposes. Erlang - to be distributed from the ground up. Clojure - to handle mutability on somewhat lower level and be on JVM, where mutability is the norm.
I taught myself Clojure with [Clojure for the Brave and True](https://www.braveclojure.com). It's a silly (free) online resource. I grew up learning Common Lisp and Scheme, and it was really easy for me to get into. That just meant I skipped the first chapter. It quickly got into doing things the Clojure Way™ and how to leverage its strengths. Highly recommended.
Joy of Clojure is my favorite whirl wind tour of the language. I generally suggest also pairing it with Clojure Applied, which deals with the larger "assembling the pieces into a whole" side of things.
I bought Clojure in Action and The Joy of Clojure , both from Manning. I found Clojure in Action to be better suited to me as I too had little exposure to Lisps. Everybody raves about Joy of Clojure but it did not work for me. But now my favourite book is Clojure for the Brave and True -- it is awesome and fun.
I am thinking the onerous part of learning to use Clojure is not the lisp parts but the Java/JVM part, to the point I felt, if one is new to Java/JVM it is very difficult to use Clojure.
Just use Erlang with Dialyzer. It's not quite as nice as a lanugage with types built-in, but if you're strict about using it, it does work. I won't code without it.
> Clojure is a Lisp and as such comes with all the goodies Lisps provide. Apart from these Clojure also introduces powerful abstractions such as protocols, multimethods and seqs, to name a few. [...] It is fair to say that combining the power of the Erlang VM with the expressiveness of Clojure could provide an interesting, useful result to make the lives of many programmers simpler and make the world a happier place.
Also, at this point Clojure is becoming a kind of nice foundational language with multi-host targets. So if you know Clojure, you can now leverage the JVM, various JS runtimes, the CLR, now also the BEAM, etc. So there's that too. So basically, to someone already knowing Clojure it's a nice way to have access to more platforms.
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.
If you want a Lisp (although there are multiple Lisps for the BEAM). If you want to help build a new language. If you don’t like Elixir’s syntax (raises hand).
I think the more interesting question would be why Clojerl over LFE (http://lfe.io/)?
Yes, there is a community around Clojure that would feel more at home with the BEAM if they could use Clojure there... and this is likely the answer to my first sentence... but once you get to a Lisp it seems like the leap is less far to another Lisp and LFE, I would think, is better established.
So I guess the real question would be, for those outside the Clojerl project, are the benefits Clojure more specifically on the BEAM worth the costs of foregoing a (possibly/likely) more mature Lisp that already exists for the BEAM?
Interesting. I'd really like to see Pytherl. Use the easy-to-learn Python syntax, as best as possible, but on the BEAM. I think that would be even better than Elixir for getting people on board.
[+] [-] macintux|6 years ago|reply
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.
[+] [-] sbuttgereit|6 years ago|reply
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 would expect different trade-offs from Elixir vs. Luerl as such. For example, I have a project where I need a limited, embedded scripting environment inside of an otherwise Elixir project. Using a BEAM language seems to be difficult to impose the desired limitations for such scripting environment, but in Luerl it seems I can do just that... limiting the scripting to a-less-than-system-wide scope. Of course... I expect a fairly substantial performance penalty for that... but trade-offs :-).
[+] [-] fulafel|6 years ago|reply
[+] [-] yellowapple|6 years ago|reply
Nice!
As a bit of a shameless plug, I have an entry for your list: https://otpcl.github.io/ (GitHub repo: https://github.com/otpcl/otpcl)
[+] [-] jacobush|6 years ago|reply
[+] [-] giancarlostoro|6 years ago|reply
[0]: https://news.ycombinator.com/item?id=20174830
[+] [-] starman100|6 years ago|reply
[+] [-] alexeiz|6 years ago|reply
[+] [-] tombert|6 years ago|reply
I personally like LFE a bit better, because of the more-direct mappings to BEAM (as you mentioned). Lisp-Flavoured-Erlang is a very honest name; it feels like you're writing Erlang, just a nice and consistent Lisp syntax.
That said, I think Clojerl is pretty neat. I tend to find Clojure's macro syntax a bit cleaner than LFE's Common-Lisp style (I still get tripped up on commas). Also, Lisp-1 semantics are a lot more reasonable...I still hate putting `funcall`s everywhere.
[+] [-] namelosw|6 years ago|reply
I'm a shallow Clojure user, I like Clojure but every time I look into 'modern' Clojure code base I would see a lot stuartsierra/component. I know this is quite a library with high quality, but it's more like a sign of compromise - 'we still need stateful component eventually, although we already have 5 different ways to deal with the state, we need another one'.
Despite what Rich said about Actors, the state in Erlang/OTP is more well-modeled. The state(process mechanism) is not only playing well with immutable functional languages but also much more robust than OO languages. And it also largely simpifies the mental model - it removes the need of atom/agent/variable/object, etc.
Another neat thing, of course, no awkward loop/recur anymore.
[+] [-] keymone|6 years ago|reply
> The points he makes are of course very good. For example, when no state is shared between processes there is some communication overhead, but this isolation is also an advantage under a lot of circumstances. He also mentions here that building for the distributed case (a.k.a processes and message passing) is more complex and not always necessary, so he decided to optimise for the non-distributed case and add distribution to the parts of the system that need it. Rich Hickey calls Erlang "quite impressive", so my interpretation of these writings is that they are more about exposing the rationale behind the decisions and the trade-offs he made when designing Clojure (on the JVM), than about disregarding the actor model.
That would be my understanding as well. Clojure and Erlang are ideologically quite close, just made with slightly different purposes. Erlang - to be distributed from the ground up. Clojure - to handle mutability on somewhat lower level and be on JVM, where mutability is the norm.
[+] [-] noncoml|6 years ago|reply
Any good recommendations for a Clojure book for a seasoned programmer but with little exposure to Lisps?
[+] [-] ashton314|6 years ago|reply
[+] [-] goostavos|6 years ago|reply
[+] [-] pixelperfect|6 years ago|reply
[+] [-] manishsharan|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] billfruit|6 years ago|reply
[+] [-] vbuwivbiu|6 years ago|reply
[+] [-] tosh|6 years ago|reply
https://github.com/clojerl/clojerl/blob/0.5.0/CHANGELOG.md
[+] [-] ggregoire|6 years ago|reply
I really want to love Elixir but dynamic typing is a NO for me.
[+] [-] macintux|6 years ago|reply
* https://github.com/alpaca-lang/alpaca
* https://github.com/wende/elchemy
[+] [-] toastal|6 years ago|reply
[+] [-] starman100|6 years ago|reply
[+] [-] johnsimer|6 years ago|reply
[+] [-] tanzbaer|6 years ago|reply
[+] [-] didibus|6 years ago|reply
> Clojure is a Lisp and as such comes with all the goodies Lisps provide. Apart from these Clojure also introduces powerful abstractions such as protocols, multimethods and seqs, to name a few. [...] It is fair to say that combining the power of the Erlang VM with the expressiveness of Clojure could provide an interesting, useful result to make the lives of many programmers simpler and make the world a happier place.
Also, at this point Clojure is becoming a kind of nice foundational language with multi-host targets. So if you know Clojure, you can now leverage the JVM, various JS runtimes, the CLR, now also the BEAM, etc. So there's that too. So basically, to someone already knowing Clojure it's a nice way to have access to more platforms.
[+] [-] valw|6 years ago|reply
[+] [-] macintux|6 years ago|reply
[+] [-] sbuttgereit|6 years ago|reply
Yes, there is a community around Clojure that would feel more at home with the BEAM if they could use Clojure there... and this is likely the answer to my first sentence... but once you get to a Lisp it seems like the leap is less far to another Lisp and LFE, I would think, is better established.
So I guess the real question would be, for those outside the Clojerl project, are the benefits Clojure more specifically on the BEAM worth the costs of foregoing a (possibly/likely) more mature Lisp that already exists for the BEAM?
[+] [-] rlander|6 years ago|reply
[+] [-] fouc|6 years ago|reply
[+] [-] starman100|6 years ago|reply
[+] [-] didibus|6 years ago|reply
Otherwise, none of the Python semantics make any sense on the BEAM, so I'm not sure that's that helpful, but who knows.
[+] [-] DanielDent|6 years ago|reply
[+] [-] macintux|6 years ago|reply
http://reia-lang.org/
[+] [-] cupidtrails|6 years ago|reply
[deleted]
[+] [-] _jayhack_|6 years ago|reply
[+] [-] _pmf_|6 years ago|reply
[+] [-] fouc|6 years ago|reply