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 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 ) and finally to ErlangRT mentioned below 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...
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.
If you are looking to make an embedded focused VM, obviously ARM is the most useful target to run on.
The two main ideas were to be different implementation for large machines (ErlangRT) or to be small (E4VM and gluonvm1).
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?
edit: it's a work in progress, but it's a start. Looks like the author is actively working on it.
For ErlangRT the original idea was to reproduce some subset of existing Erlang/OTP emulator features and then optimize from there. It resembles Erlang/OTP data formats and data structures, so it would begin at 1:1 ratio or maybe a little worse like 1.1:1 or something because Rust incurs some costs for compound types where for C it was enough to have an integer.
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.
I'm glad Erlang and Elixir are slowly getting popular and going into other spaces such as hardware apparently.
Gluon had the complete opposite goal. lua would be an idea for a small BEAM engine. It would also be much faster.
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.
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.
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.
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.
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.
Also lets not forget C was quite slow in 8 and 16 bit systems, and it only became as fast thanks to the joy of UB and -O3.
"Scripting languages are designed for gluing."
"Programming languages are compared against each other as though their designers intended them to be used for the exact same purpose - that just isn't so."
For example, real engineers read the FAQ.
"Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."
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