
Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode - ghosthamlet
https://github.com/kvakvs/gluonvm1
======
kvakvs
Greetings!

Author is here.

We have no idea how this blog draft escaped into HN, but here it is a few
years too late. The Gluon project
[https://github.com/kvakvs/gluonvm1](https://github.com/kvakvs/gluonvm1) isn't
live anymore, it was using C++ and it was stopped a couple years ago giving
way to other experiments (
[https://github.com/kvakvs/E4VM](https://github.com/kvakvs/E4VM) ) and finally
to ErlangRT mentioned below
[https://github.com/kvakvs/ErlangRT](https://github.com/kvakvs/ErlangRT)

My talk with me explaining the whole thing on EUC 2017 (Stockholm) is here
[https://youtu.be/6NUPormxgw8?list=PLWbHc_FXPo2jAL3fm0YfN3nFV...](https://youtu.be/6NUPormxgw8?list=PLWbHc_FXPo2jAL3fm0YfN3nFVj6OyQcu2)

The new ErlangRT project in Rust is much more recent; clean strictly typed
code with some 'unsafe'ties and a good PoC progress. But it also was stopped
because the amount of work to do in it quickly grows but my free time doesn't
grow at all.

This increased interest might actually make me rethink my priorities and look
at it again.

~~~
rkangel
It's great to hear interest in this area - the more places I can run
Erlang/Elixir, the more likely I am to use it even in the places it can
traditionally run (it's a more useful language to me if I can use the same
codebase everywhere).

If you are looking to make an embedded focused VM, obviously ARM is the most
useful target to run on.

~~~
rubyn00bie
Is there a platform the BEAM doesn't currently target? I'm not aware of
anything that isn't completely esoteric... You can run it on ARM currently.

BEAM has been in use for over 20 years in telephone systems running on
insanely old and bizarre hardware. Is there a platform you have in mind
besides ARM?

~~~
baobrien
I could be wrong, but I don't think BEAM really runs on microcontrollers.
Erlang might be a good environment on the same sorts of micros (32 bit, dozens
of KB of ram) MicroPython targets.

~~~
marci
[https://github.com/bettio/AtomVM](https://github.com/bettio/AtomVM)

edit: it's a work in progress, but it's a start. Looks like the author is
actively working on it.

------
neya
Would Elixir be able to support this? If yes, then it could be a huge deal
(atleast for me). Imagine writing a POS system's code in Elixir. That'd be
very nice, although I understand at this point this is just wishful thinking.

~~~
mikece
I know of a company who implemented a POS in Elixir in Phoenix running in web
kiosk mode. I don’t know any further details and probably couldn’t share them
if I did but this scenarios has been done with BEAM.

~~~
neya
Wow, that's cool. Would be very interested to keep track of the progress of
that..

------
lucian
it looks there is also a more recent proof of concept work to implement the
Erlang VM in Rust:
[https://github.com/kvakvs/ErlangRT](https://github.com/kvakvs/ErlangRT)

~~~
akavel
Cool subtitle :) lighthearted, and gives good overview of author's position:
_" Good news: I know what to do. Bad news: I have no clue how to Rust"_

------
qop
"Last commit was over 2 years ago" is a common phrase when it comes to Erlang.

Of course, I'd consider Erlang to be one of the best platforms in terms of
stability. It's rare that they double back on old features.

------
hengestone
Check out [https://github.com/bettio/AtomVM](https://github.com/bettio/AtomVM)
which seems to be a similar project that's actively developed.

------
digitalzombie
Is the art created from the same artist that did art for the book
learnyousomeerlang.com?

I'm glad Erlang and Elixir are slowly getting popular and going into other
spaces such as hardware apparently.

~~~
kvakvs
The technology for the art is called Wacom Bamboo and I was overdrawing the
Erlang logo with some hand scribbles in Inkscape. In fact same technology
seems to be used for the original LYSE book and I was using it to translate
text in images in Russian translation for the LYSE book.

~~~
mononcqc
For Learn You Some Erlang, I used hand-made drawings that I would scan, and
then trace over using either photoshop (initially) and then Illustrator (when
I knew the book would go to print).

~~~
rs86
Is that de same technique as in learn you a haskell?

~~~
mononcqc
no idea, did not write that one.

------
mattparlane
$('img[alt="Draft"]').remove();

------
pjmlp
We barely had FB and Sonar, to just get yet another example of how badly to
name projects.

[http://gluonhq.com/](http://gluonhq.com/)

~~~
joshsharp
Gluon is also a language built on Rust: [https://github.com/gluon-
lang/gluon](https://github.com/gluon-lang/gluon)

~~~
kjeetgill
Which I heard of for the first time only weeks ago and thought this was.

------
_pmf_
Wouldn't targeting GraalVM make sense, too?

~~~
cube2222
Could you elaborate please? Why do you think would it make sense?

~~~
chrisseaton
It'd be great to see what a state-of-the-art optimising compiler can do for
the performance of Erlang and Elixir.

~~~
jerf
Given the not-all-that-great improvement of a targeted attempt to speed up
Erlang with HiPE, I wouldn't hold your breath for how well a non-targeted
approach would go. Unfortunately, Erlang-the-language has several features
that seem to be fundamentally slow, in that I've never seen any runtime that
goes quickly with them. (A lot of memory copying, for one, even after being as
clever as possible with optimizations on that front.)

(I no longer believe in the line that there are no slow languages. In
practice, there seem to be, and languages in practice seem to plateau at
certain performance levels no matter how much effort is put into them. Those
who wish to argue are welcome to produce the fast-as-C-at-everything
Javascript interpreter or some similar artifact and I will happily retract.)

Erlang is still a fine language and it's performance is well in line with
several other popular languages; by no means would I say it is unusable. It's
just that real engineers need to have clear understandings of the costs and
benefits of their tools, which includes understanding not all languages have
the same speed characteristics.

~~~
chrisseaton
HiPE was done a long time ago, and I don't think it tried to use any
particularly sophisticated techniques even at the time.

Modern compilation techniques such as powerful escape analysis and partial
evaluation may be able to do something new. GraalVM runs Ruby about 10x faster
than standard Ruby, for example.

~~~
jerf
"GraalVM runs Ruby about 10x faster than standard Ruby, for example."

Which puts it roughly up against the plateau I observe for dynamically-typed
languages across the board, except LuaJIT (which AIUI compromises the
dynamicness a bit to get there). Ruby is a great deal more than 10x slower
than optimal (which is still roughly C, though keep an eye out on that as
languages continue to challenge it).

Based on the way Erlang works, I wouldn't expect it to get much past two times
faster than it already is no matter how much money is poured into it.

I remember hearing the line about how there are no slow languages, only slow
implementations, back in the early 2000s, when we didn't have any
implementations of dynamic scripting languages that had really had a lot of
effort poured into them, by modern standards. In 2018, we have numerous such
implementations with vast, vast amounts of work poured into them. They are
faster than they used to be... and they are still meaningfully slower than
optimal. (And eat about 10-20x times the RAM in the process.) Erlang doesn't
do all the bad things that Python or Ruby do to make them slow, but it does
add a lot of memory copying that Python and Ruby don't do, and which is
probably not as reducible as you'd like no matter how you optimized it (the
low-hanging fruit, after all, is already in current Erlang).

To be honest, if you like Erlang but you need the next step up in performance
and are willing to lose a few guarantees to get there (a very common tradeoff
in optimization, after all), the answer is Go, not waiting for a much faster
Erlang. Go is significantly faster than Erlang, Go does not have Erlang's
memory isolation, and these statements are deeply connected together, not just
coincidence.

~~~
jashmatthews
What about Common Lisp using SBLC? That's dynamically typed and amazingly
fast.

LuaJIT is simply a very good optimizing JIT compiler. It's just as dynamic as
Lua.

BEAM is a register-based bytecode VM, which is dramatically slower than native
code. The fast JS implementations either don't bother with a bytecode VM (V8)
or baseline compile to native after only a few iterations (WebKit) because
bytecode VMs simply can't compete with a chunk of native code.

2018 MRI Ruby is ~14x faster than 2006 Ruby depending on how you measure.
Neither Python nor Ruby have seen anywhere near the resources put into JS
engines over the past 10 years.

Oracle dumped a ton of money into making the JVM support dynamic languages and
now Graal is bringing full Java performance to both Ruby and Python.

It's not really inherent language design flaws that make it difficult to
optimize Ruby and Python (they don't do anything "bad") but the community
dependence on compatability, particular with C extensions. PyPy does a ton of
crazy stuff to maintain compatability that then hurts performance, like faking
reference counts etc.

~~~
igouy
>> SBCL

Was `jerf` opining about "dynamically-typed languages" or just about "dynamic
scripting languages"? It matters.

>> inherent language design flaws

Not "design flaws" but design goals -- _Scripting languages are designed for
gluing_.

------
tgdn
Dead link

------
salimmadjd
Ot: please lessen the “DRAFT” stamp. It makes it very hard to read

~~~
sbr464
I just right click -> Adblock -> remove element

~~~
fnordsensei
Mobile user here… It's even worse (I imagine), and unfixable from mobile
Safari.

------
migueltarga
404

Ooops It looks like that page you tried to explore went extinct, or you typed
in the wrong address. Check the URL again or go back to our home page

~~~
kvakvs
I asked to unpublish it. Please read my top comment.

