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.
Clojerl – Clojure for the Erlang VM
31–40 of 105 posts
Re: Clojerl – Clojure for the Erlang VM
#32Any initiative like this (language on top of the Erlang VM) with static typing out-of-the-box? I really want to love Elixir but dynamic typing is a NO for me.
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.
Re: Clojerl – Clojure for the Erlang VM
#33Sorry for the off topic. Any good recommendations for a Clojure book for a seasoned programmer but with little exposure to Lisps?
Re: Clojerl – Clojure for the Erlang VM
#34Earlier quoted context omitted.
The JVM is a kitchen sink environment. The BEAM is very opinionated. I would expect the VM built from the ground up to support a specific programming model to be superior at doing just that.
In addition, every library written for the BEAM in any language is designed for message passing and the actor model. Clojure would not have that advantage on the JVM.
Re: Clojerl – Clojure for the Erlang VM
#35Interesting! 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. [0]: http…
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.
Re: Clojerl – Clojure for the Erlang VM
#36Earlier quoted context omitted.
In addition, every library written for the BEAM in any language is designed for message passing and the actor model. Clojure would not have that advantage on the JVM.
Clojure doesn't use the actor model...
Re: Clojerl – Clojure for the Erlang VM
#37Interesting. 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.
Otherwise, none of the Python semantics make any sense on the BEAM, so I'm not sure that's that helpful, but who knows.
Re: Clojerl – Clojure for the Erlang VM
#38Re: Clojerl – Clojure for the Erlang VM
#39Earlier quoted context omitted.
Clojure doesn't use the actor model...
Which was part of the discussion at the linked article.
The rationale for why Rich Hickey didn't go for the actor model are actually documented here: https://clojure.org/about/state
I agree with you, that the JVM also would have probably made it more difficult to incorporate and leverage, though Scala seems to have pretty successfully done that, and Fantom has gone that route as well successfully (though the language is niche) on the JVM. So I'm not totally sure either.
Re: Clojerl – Clojure for the Erlang VM
#40Interesting. 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.
You might like Reia. http://reia-lang.org/