4 ms·

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/kvak

by kvakvs 8y ago

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

deleted 8y ago
[deleted]
rkangel 8y ago
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.
- kvakvs 8y ago
  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).
- rubyn00bie 8y ago
  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 8y ago
    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 8y ago
      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.
  - kvakvs 8y ago
    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.
liveoneggs 8y ago
were you ever able to feed in size savings back to Ericsson? Especially since OTP got relicensed?
- kvakvs 8y ago
  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.
  - sa2ajj 8y ago
    I'm curious whether you had in mind any kind of benchmarks (which have not been implemented) for checking size and/or performance differences...
    - kvakvs 8y ago
      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.
sctb 8y ago
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.
- kvakvs 8y ago
  The original gluonvm1 project link is fine, as in its description there are links to its successors. Thank you for caring!
MrBuddyCasino 8y ago
Why Erlang in Rust? Ever thought about a no-std Actix clone?
- kvakvs 8y ago
  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.
  - MrBuddyCasino 8y ago
    Didn't know your Erlang stuff was paid work. Lucky you!
- hayd 8y ago
  How much std is used in actix? Is no-std a big project/possible refactor?

by kvakvs 8y ago

deleted 8y ago

[deleted]

rkangel 8y ago

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.

kvakvs 8y ago
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).
rubyn00bie 8y ago
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 8y ago
  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 8y ago
    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.
- kvakvs 8y ago
  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.

liveoneggs 8y ago

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

kvakvs 8y ago
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.
- sa2ajj 8y ago
  I'm curious whether you had in mind any kind of benchmarks (which have not been implemented) for checking size and/or performance differences...
  - kvakvs 8y ago
    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.

sctb 8y ago

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.

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

MrBuddyCasino 8y ago

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

kvakvs 8y ago
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.
- MrBuddyCasino 8y ago
  Didn't know your Erlang stuff was paid work. Lucky you!
hayd 8y ago
How much std is used in actix? Is no-std a big project/possible refactor?