Hacker News Reader

Comment by kvakvs | Hacker News Reader

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

View on HN

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?

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.

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.

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.

If you'd like to update the post instead of removing it altogether we can put the link back, but we've gone with the GitHub repo for now.

The original gluonvm1 project link is fine, as in its description there are links to its successors. Thank you for caring!

were you ever able to feed in size savings back to Ericsson? Especially since OTP got relicensed?

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.

I'm curious whether you had in mind any kind of benchmarks (which have not been implemented) for checking size and/or performance differences...

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.

Why Erlang in Rust? Ever thought about a no-std Actix clone?

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.

Didn't know your Erlang stuff was paid work. Lucky you!

How much std is used in actix? Is no-std a big project/possible refactor?

Reply on news.ycombinator.com