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.
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.
By using C++ and Rust obviously ARM was on my mind, and I have plenty of test boards ranging from 192kb to hundreds MB of RAM to experiment with. It just never reached that stage.
The two main ideas were to be different implementation for large machines (ErlangRT) or to be small (E4VM and gluonvm1).
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?
It is memory not CPU that is the main limitation. Under 20MB RAM you are entering a gray zone, where BEAM barely runs. You can keep removing modules from the standard library and optimising it fit into maybe 8MB RAM (as project GRISP did) but smaller than that BEAM VM would not even boot to shell.
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.
This would mean huge refactoring, which i'm sure they'd never accept. The only way to go was to start something my own or fork. OTP team prefers changes which do not degrade performance, as I'm essentially optimising for size, while they optimise for speed and compatibility.
For E4VM I engineered it so that my Huffman-compressed BEAM bytecode would be much smaller, at some reasonable performance cost. Something like 1:3..1:6 ratio, probably even better. The emulator code was also planned to be very limited, possibly the language will also become a subset of Erlang, to cut on the features. But there were no numbers, there was no definite goal how small I want it to be. Such talks begin when there is a project or a customer and a target to reach.
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.
That would be a very different project. No I didn't think about making a no-std web server. At least I don't know what is the demand there, and who's willing to pay for it.
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.
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.
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.
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).
Honestly I have never heard of any of those and so long as they aren't too close in what their intended use is I don't see the issue. Worse case it can just be called GluonVM then you have no ambiguity as to what you're talking about. Naming can be a pain. The worst I've seen so far was the WAMP protocol we saw posted sometime back.
Probably not. VMs are not universal. Things designed for shared memory model, like say GCs, make sacrifices that would not do so good for isolated processes. So a custom unoptimized VM might make more sense than an architecturally unfit VM.
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.
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.
"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.
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.
"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."
1.4 What sort of problems is Erlang not particularly suitable for?
"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."
While it would be nice this companys focus seems to be towards Erlang specifically so they may have their reasons not to have gone that route. Would be nice to hear what those reasons are for sure.
This is outdated article draft which wasn't published a few years ago when it was fresh, and now it is outdated. It accidentally escaped and now is automatically posted on HN.
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.