Live data from Hacker News

Clojerl – Clojure for the Erlang VM

github.com

31–40 of 105 posts

Re: Clojerl – Clojure for the Erlang VM

#32

Any 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.

I have burned more time than I care to admit trying to decipher dialyzer output shenanigans. I love dialyzer when my code doesn't generate any errors, and the rest of the time I kind of want to cry.

Re: Clojerl – Clojure for the Erlang VM

#34
post #6

Earlier 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.

Clojure doesn't use the actor model...

Re: Clojerl – Clojure for the Erlang VM

#35

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. [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.

It looks like this is actually running the real Erlang/OTP, just with some amount of performance penalty from not being on the BEAM. This could be fantastic for fans of BEAM languages who now have a low-profile way to introduce, say, an Elixir proof of concept into a JVM-dominated infrastructure.

Re: Clojerl – Clojure for the Erlang VM

#36
post #34

Earlier 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...

Which was part of the discussion at the linked article.

Re: Clojerl – Clojure for the Erlang VM

#37

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.

I mean, at that point the only difference with Elixir is that you want whitespace delimited blocks over using DO/END.

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

#39
post #34

Earlier quoted context omitted.

Clojure doesn't use the actor model...

Which was part of the discussion at the linked article.

Oh okay, sorry I misunderstood your comment the first time.

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

#40

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.

You might like Reia. http://reia-lang.org/

Sadly it seems like all work on it has been stopped and they recommend using Elixir instead.
Post reply on HN