[erlang-questions] Erlang VM in Rust

[Joe Armstrong]

On Thu, Sep 21, 2017 at 10:48 PM, James Churchman
<jameschurchman@REDACTED> wrote:
>
>
> On 21 September 2017 at 21:37, Joe Armstrong <erlang@REDACTED> wrote:
>>
>> 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.
>
> Sounds fantastic and with a truly ideal implementation the same small
> implementation would also be performant at large scale as well
>>
>>
>> Pids should be planetary wide references with a DHT to find them -
>> processes
>> should be first class and movable - Protocols should be first class ...
>
> Would be amazing tho pids would become very complex with the lightly
> security needs added on top, becoming language agnostic, ( message
> reliability ) etc..
> Ps what does protocols being first class mean btw?

Protocols are implicit and you can imply them by reading the code.
I'd like a protocol declaration (like a module definition) that *defines*
the sequence of allowed operations. Some people call these session types :-)

-protocol(file_server)
-agents(client, server)

client ! server {send_file,F} -> server ! client ({ok,Bin} |enofile)

...

-end(protocol).

Then at run time you could query the protocol

-process(c1)
-implements(file_server, client)
...

...

/Joe



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