[erlang-questions] Erlang VM in Rust

[James Churchman]

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?

>
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170921/1927d193/attachment.htm>