
Clojerl – Clojure for the Erlang VM - tosh
https://github.com/clojerl/clojerl
======
macintux
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...](https://gist.github.com/macintux/6349828#alternative-languages-
targeting-the-erlang-vm)

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
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 :-).

~~~
macintux
I think if I were running this as a repo with the possibility of pull requests
I’d get more granular, but I can rarely be bothered to do much more than
occasionally add a link.

To be pedantic, btw, Elixir compiles to Erlang Abstract Format, not the BEAM
itself.

------
giancarlostoro
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]:
[https://news.ycombinator.com/item?id=20174830](https://news.ycombinator.com/item?id=20174830)

~~~
starman100
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.

~~~
brianpgordon
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.

~~~
cuddlecake
Would it really matter though, whether the underlying VM is JVM or BEAM, if
people don't want to code in Erlang or Elixir?

I don't think introducing the BEAM is the hard part, I think it's all about
the language barrier.

~~~
verttii
Personally I spent most of my learning curve on the BEAM facilities rather
than Elixir itself. Elixir as a language is simple and fairly imperative, it's
quick to pick up.

Using the language for data transformations and such is a breeze but learning
the concurrency primitives, message passing, OTP tooling and behaviors is
where the real work is in my opinion, when building distributed systems on top
of BEAM.

------
alexeiz
How does Clojerl compare to Lisp Flavored Erlang
([http://lfe.io/](http://lfe.io/))? LFE looks like a quite mature project and
it maps Lisp directly to BEAM. Interestingly, LFE has a collection of Clojure-
like macros
([https://github.com/rvirding/lfe/blob/develop/doc/lfe_clj.txt](https://github.com/rvirding/lfe/blob/develop/doc/lfe_clj.txt)).

~~~
tombert
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.

------
namelosw
This is brilliant.

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

------
noncoml
Sorry for the off topic.

Any good recommendations for a Clojure book for a seasoned programmer but with
little exposure to Lisps?

~~~
ashton314
I taught myself Clojure with [Clojure for the Brave and
True]([https://www.braveclojure.com](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.

~~~
gleenn
I second this resource, it's well explained and was also concise enough so
that I actually finished it. Definitely covers the the important bits and a
lot of advanced bits like macros and atoms, etc.

------
tosh
Changelog for 0.5.0

[https://github.com/clojerl/clojerl/blob/0.5.0/CHANGELOG.md](https://github.com/clojerl/clojerl/blob/0.5.0/CHANGELOG.md)

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

~~~
starman100
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.

~~~
PopeDotNinja
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.

~~~
_asummers
Not sufficient, and not for Erlang, but Dialyxir has a `mix dialyzer.explain`
command, which gives an example of code that might cause a certain error. Some
errors I have been unable to reproduce and I welcome examples of code that
would produce them, so PRs are welcome =). Here is what I say for no_return,
for example [0].

I maintain a library for converting Erlang Dialyzer messages to Elixir (Erlex
[1]) which I hope to one day be able to retire with a stronger Elixir/Erlang
communication (AST instead of string communication, e.g., and direct diffs
between types).

[0]
[https://github.com/jeremyjh/dialyxir/blob/master/lib/dialyxi...](https://github.com/jeremyjh/dialyxir/blob/master/lib/dialyxir/warnings/no_return.ex#L42)
[1] [https://github.com/asummers/erlex](https://github.com/asummers/erlex)

~~~
PopeDotNinja
Ah, neat. I didn't know about dialyzer.explain. Will most def investigate.

------
tanzbaer
Why would I use this over elixir?

~~~
didibus
From the readme of the project:

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

~~~
ngcc_hk
There are a bit different due to the host environment.

Btw, use the iOS version a lot to learn

------
starman100
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
You might like Reia.

[http://reia-lang.org/](http://reia-lang.org/)

~~~
notamy
Sadly it seems like all work on it has been stopped and they recommend using
Elixir instead.

------
_jayhack_
Love how puns are the go-to in CS

------
_pmf_
Good fit, but I think Elixir already _is_ Clojure on BEAM in spirit (sans Lisp
syntax).

~~~
fouc
How true is that?

