
Clojure for the Erlang VM - lsh
http://clojerl.org/
======
tombert
Clojerl is really cool, and you should play with it; it's actually surprising
how well the semantics transfer over to the Erlang VM.

If anyone wants something that feels a bit more vanilla-erlang-ish, one should
also check out Lisp Flavoured Erlang. It is almost a direct one-to-one
translation of Erlang into Lisp-land (actually made by one of Erlang's co-
creators), but also provides Common-Lisp-Style macros, and a much more
consistent, cleaner syntax than vanilla Erlang.

~~~
appleflaxen
Links to your references for the lazy:

[http://docs.lfe.io/current/](http://docs.lfe.io/current/)

[https://github.com/rvirding/lfe](https://github.com/rvirding/lfe)

~~~
alexeiz
It doesn't look like the LFE project on github received many commits recently.
Is this a sign of maturity or abandonment?

~~~
tombert
Virding is pretty active on Slack on the LFE channel (at least he was the last
time I was on there a few months ago); I don't think it's abandoned.

------
reilly3000
With the ability to reach Java, JavaScript, .Net, and Erlang runtimes, plus
interop with many other languages via GraalVM, Clojure has incredible reach
across runtimes, perhaps more than any other modern programming language,
certainly among Lisps. That said, its pretty gnarly to try to navigate all of
the implementation differences among platforms. I wonder if there is a subset
of Clojure that is 'safe' to run on any of its supported environments.

This list is pretty long: [https://clojerl.github.io/differences-with-
clojure/](https://clojerl.github.io/differences-with-clojure/)

For now, the JVM is the only way to get the full Clojure experience.

~~~
dwohnitmok
The Clojure community believes strongly in the idea that it is a hosted
language, and therefore prioritizes maintaining the semantics of its host
(whether that be the JVM, a JS engine, or some other VM) over independent,
consistent semantics for Clojure itself.

That being said they've made some concessions to the fact that it would be
really nice to have portable Clojure code with `.cljc` files, but those are
only portable Clojure code by matter of convention (the only technical thing
`.cljc` files accomplish is allowing you to use reader conditionals).

Personally, I wish Clojure went further. Even with the commitment to being a
hosted language, it still is clunkier at interop than Scala or Kotlin, two
languages which nonetheless do have independent semantics as specified in
their respective language specifications. It kind of seems you end up with the
worst of both worlds (worse interop and no consistent semantics), although to
be fair Clojure also commits far more heavily to the FP paradigm than Kotlin
or even Scala, which makes it intrinsically more difficult to have seamless
interop with Java (yes yes yes its interop with Java is already quite good,
just not quite at the level of the others).

~~~
moomin
Yeah, I’ve developed some clj/cljs code. It’s full of conditional compilation.
It’s even full of conditional compilation expressions in the ns header.

------
macintux
There are at least 19 alternative languages for the BEAM[1]. If anyone knows
of any I’ve missed, let me know.

[1]: [https://gist.github.com/macintux/6349828#alternative-
languag...](https://gist.github.com/macintux/6349828#alternative-languages-
targeting-the-erlang-vm)

~~~
BoiledCabbage
There are 4 relevant VMs: .net, java, js and erlang.

If you're making a language and not targeting one of them, you're DOA.

~~~
unlinked_dll
And none of them guarantee tail call optimization leading to trade offs in the
design of particular languages that may or may not be acceptable.

~~~
sb8244
What does "guarantee" mean here? If you end a function in BEAM with another
function call, it's TCO.

~~~
bad_login
Tail Call Optimization is an optimization done by the compile/vm that replace
(in assembly terms) a CALL by a JMP. Therefore removing a call stack.

~~~
sb8244
Correct. BEAM does real TCO as far as I'm aware. LYSE has a blurb about it and
seems to agree
([https://learnyousomeerlang.com/recursion](https://learnyousomeerlang.com/recursion)).

------
whalesalad
The site does a great job explaining what Clojure features exist in this port
... but what about Erlang features? There doesn't appear to be a first-class
adoption of things like supervisors and actors like you see in Elixir, for
example. Or at least the docs don't do a great job explaining it?

~~~
verttii
That was also the first thing I was looking for in the docs. I mean how it
ties to the Erlang OTP. It's the reason why anyone would use Erlang's platform
after all.

~~~
lsh
I found the project via this article:

[https://medium.com/clojure-on-the-
beam/agents-9de923017adf](https://medium.com/clojure-on-the-
beam/agents-9de923017adf)

that discusses why Clojure 'agents' haven't been implemented in BEAM yet. I
_think_ (and I'm not familiar with Erlang) that Clojure agents are very
similar to Erlang actors.

~~~
weego
This is my understanding of agents vs actors, I may be naive or wrong:

Actors are an instance of an object that has inherent logic and maintains
mutable state within itself

Agents are state with logic attached to them that are immutable and return a
new instance of the state (along with attached logic)

------
andreareina
Page is a frameset around
[https://clojerl.github.io](https://clojerl.github.io), which breaks the
mobile experience (fixed width, content too small). Going directly to the
github.io copy scales the content correctly and provides https.

------
abjKT26nO8

        <frameset rows='100%, *' frameborder=no framespacing=0 border=0>
            <frame src="https://clojerl.github.io/" name=mainwindow frameborder=no framespacing=0 marginheight=0 marginwidth=0></frame>
        </frameset>
    

What...? Why...? I just can't...

~~~
speps
Custom domains on GitHub are not free... people find ways.

~~~
weavie
I'm pretty sure they are.

------
Vizarddesky
I'm curious to see a detailed list of language constructs and features that
are and aren't supported.

------
kopos
Why Clojerl when LFE maps directly to the best of what BEAM offers -
supervisor trees and pattern matching?

------
ishankhare07
I don't see how this brings anything new to the ecosystem. Clojure is a LISP
and we already have lfe ([http://lfe.io/](http://lfe.io/)) - LISP floured
Erlang for quiet a while now, hence it will definitely be more mature than a
new implementation altogether. Moreover I feel, seeing the the currently more
effort should be made in maturing the classic clojure implementation and the
tooling around it itself, rather than diverting the community into fancy new
(not so useful) ports of the same syntax for other runtimes. Seriously, just
go improve clojure itself. And if you want to be able to write lisp for BEAM,
just use lfe.

~~~
keymone
one does not simply say one lisp dialect is better than the other.

~~~
ishankhare07
I never said one is better than the other. All I said is, if you want lisp on
BEAM, you already have lfe.

~~~
keymone
> if you want lisp on BEAM, you already have lfe

if you want lisp <insert condition>, you already have <insert lisp satisfying
condition>.

your assumed condition is wrong, a person may not just want lisp on beam, they
may want clojure on beam.

~~~
ishankhare07
the only major difference I see between what you're calling 'clojure' and a
lisp is that clojure compiles to JVM. That alone goes for a toss when you say
you're porting it to BEAM. There is no more java in the equation. Its interop
with erlang/elixir ecosystem. Which is exactly what lfe is (apart from some
minute differences in syntax which may or may not be there).

~~~
keymone
> the only major difference I see between what you're calling 'clojure' and a
> lisp is that clojure compiles to JVM

it's always better to ask than to make incorrect assumptions

------
zelly
Now I want to see a port to the Low Level Virtual Machine

~~~
valvar
LLVM has not been an acronym for Low Level Virtual Machine for quite a while
now [1].

[1] - [http://lists.llvm.org/pipermail/llvm-
dev/2011-December/04644...](http://lists.llvm.org/pipermail/llvm-
dev/2011-December/046445.html)

------
crimsonalucard
Does anyone know if there are any languages with ADTs running on top of the
erlang vm?

~~~
dwohnitmok
There are, in various stages of experimentation.

Haskerl, a subset of Haskell for the BEAM VM.

Alpaca, a version of ML.

A Purescript BEAM back end.

An Idris BEAM backend.

See
[https://github.com/llaisdy/beam_languages/blob/master/README...](https://github.com/llaisdy/beam_languages/blob/master/README.org)

