[erlang-questions] Erlang VM in Rust

[Joe Armstrong]

The project that interest me would go in the opposite direction to
reimplementing the VM in Rust.

I'd like to make an extremely small extremely slow Ertang targeted to
IOT devices - low power devices with small memory and slow clocks.

The goal would be a smaller VM with fewer instructions
and a highly portable ANSI C interpreter.

I think the only way to make secure systems is to throw away as much as
possible and retain a small kernel with very limited ability.

I'd like to see lots of very small machines talking to each other with
defined protocols.

I managed to find an early erlang from 1991 (the compiler still works)
the compiler in was 4000 line of Ertang and the emulator was 3800 lines of C

We didn't have binarys and maps but I think the *goodness* comes from
links and mailboxes.

Software gets more complex with time *because* we build upon earlier work
*without* throwing away stuff.

The problem is we when we build on old stuff we don't know which of the old
stuff we can throw away, so we include it "just in case"

Then it gets so complex we give up - and we seal it off in a virtual machine
or container and carry on.

N. Wirth said when you add a new feature you should remove an old one
but we don't do this.

A new VM in Rust or anything would be a good excuse to re-look at the
architectures we want and see how to implement them - Just reimplementing
Erlang would be miss a good opportunity to chuck out some weird design
decisions and do some good things.

Pids should be planetary wide references with a DHT to find them - processes
should be first class and movable - Protocols should be first class ...

My 10 cents worth

/Joe



On Thu, Sep 21, 2017 at 9:42 PM, James Churchman
<jameschurchman@REDACTED> wrote:
>
>
> On 21 September 2017 at 19:26, Felix Gallo <felixgallo@REDACTED> wrote:
>>
>> I think Rust takes several steps in wrong directions, but the answer to
>> (2) is obvious -- even though we've had 40 years to learn how to 'better
>> code our drivers', the world of software is a shaky, broken, rickety pile of
>> insecure nonsense and it's only getting worse over time.  There is
>> apparently no amount of learning we can do and we need the machines to help
>> us.
>>
>> Erlang solves the memory safety problem by enforcing immutability, which
>> has incredibly low mechanical sympathy and ends up being unperformant for a
>> large and useful set of problems.  Rust solves it by giving the developer a
>> bewilderingly bedazzled straitjacket and telling them to sort it out if they
>> want performance.  Pony's straitjacket has better affordances in my opinion
>> but is still deeply confusing to developers.  The fact that we are all
>> trying is no accident.
>
>
> Indeed... there are some algorithms that are orders of magnitude slower to
> write with immutability. The systems that Erlang is designed for quite often
> are not these tho, + NIF's can fill the gap, tho not in an elegant way (
> embedding a totally different language that forces you to give up all
> guarantees that Erlang has, tho rust would help here as it should not crash
> the VM )
>
> You should try the borrow checker in rust.. it takes time to get used to and
> there are few times you have rethink a way of coding something but it gives
> memory safety with no GC .. really amazing .. on top of that you can write
> "unsafe" rust with less guarantees, and do as you feel .. no restrictions at
> all. Its also possible to write GC code too, have yet to try it but was
> originally optional in the language & all the hooks left in the language in
> the type system, so a few are available as installable as packages ... some
> algorithms ( maybe writing a graph database or similar ? ) are easier with a
> GC so you just create those objects as being handled by the GC ..
>
>
> Its also worth remembering that the entire Erlang runtime has already been
> re-written, in Java, with performance between beam and hype, able to run
> apps like riak and the only downside being some small gc pauses, that may
> not even happen on a modern JVM
>
>>
>> F.
>>
>> F.
>> On 21 September 2017 at 18:12, Frank Muller <frank.muller.erl@REDACTED>
>> wrote:
>>>
>>> Erlang newbie here ...  jumping into the subject.
>>>
>>> While agree with most of the ideas about security, speed ... I still
>>> can't get some really basic things.
>>>
>>> 1. Why one should trade a time-proven, close to metal, fars language like
>>> C with more than ~40yrs of existence with a new one? We don't even know if
>>> Rust will exist in the near future. That's not gonna be the case for C
>>> apparently (IoT, etc.).
>
>
> Well the existence of Rust ( or any language ) will depend entirely on how
> many new projects and existing ( c ) projects written in it!
> Large sections of Firefox are now written in Rust ( in a version thats
> shipping very soon ) cross ported from the Servo project, which gave rise to
> rust in order to build a totally new browser engine .. given that browsers
> are now some of the largest software projects on the planet this is a good
> sign. These include the CSS parser, CSS matcher, the Compositor and several
> more .. the eventual plan is to move everything over.
> The benefits are many, and it still maintains C ABI compatibility if you
> need it.
>
>
>>
>>
>>>
>>> 2. Why simply not simply learn how to better code our NIF/Drivers
>>> instead? C was/is my main programming language for many years now, and I
>>> didn't have any major issue with it (medium to large projects) in production
>>> environment so far. Maybe I'm just lucky, maybe not.
>>
>>
>
> Well the more the tooling and language can do for you the better, and the
> more guarantees of correctness the more secure your software is likely to
> be. One of many reasons for rewriting Firefox in rust is security. Most C
> projects probably don't have hundreds/thousands of security guys trying to
> cause memory overflow errors, but for things like browsers, VM's, OS's they
> do, and with the increase of IOT many products that were not traditionally
> exposed to the internet now are .. and when one is discovered it's usually
> game over!
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>