[erlang-questions] Erlang VM in Rust

Thu Sep 21 18:15:22 CEST 2017

My opinion is that a full re-write of all VM's in Rust, especially the
Erlang VM should be a very very high priority in the world of computing ..
the benefit of memory safety in all languages, including low level, can not
be underestimated in all of security, reliability and developer
productivity. Over time, code that is not written in memory safe languages
will be viewed in the same way as coding full of goto's or writing full
apps in assembler.

The cost of the rewrite in rust would be quite large, including:

1) A time consuming, complex process for a full rewrite

2) New bugs in the new implementation that will take a while to trace down
( tho the prevalence of large code bases written in Erlang with randomised
property tests would help find these a lot faster tho )

3) Incompatibilities that are likely inevitable

4) Wide performance differences : tho its lightly the rewrite could be
gigantically faster ( judging by the performance of Hype alone ) there
would be large scale Erlang systems that are tuned for the current VM ..
some of these may expect very specific behaviour in scheduling, the GC,
networking & more and would lightly need some heavy profiling and re-tuning
to perform well. Also as the new VM would become popular the opposite would
happen: some library's would run very fast on the new VM and slower on the
old one

5) New users asking "which VM should I chose for my deployment" and the
lightly very complex answers that come back causing some confusion.

6) Breaking NIF & C driver compatibility ( tho, it may be possible to
provide a compatibility layer in some circumstances )

7) Some tooling ( e.g. the debugger if its used by anyone etc.. ) no longer
working

8) Platform portability being slightly different vs the current vm

9) A pause in curent VM development while the new one is built if its a
full rebuild, tho an incremental rebuild or the development of a small mini
proof of concept / embeddable vm would not have this issue

The advantages going forward would be huge :

1) An ahead-of-time (AOT) optimising compiler targeting a high level
machine code ( say LLVR IR ) could give a 10x performance boost, if not
more. This would be far easer to write in rust

2) Hugely higher level of innovation ( once written & complete ) and future
progress in the VM. Rust is so much more productive than C its crazy .. the
borrow checker, tighter type system, no memory allocation errors, pattern
matching, better macros, cleaner higher level syntax, inbuilt & safe
mutex's, better inbuilt data structures and standard library, type classes,
a package manager etc..

3) Encouraging more open source contributions to the VM

4) Fantastic parallelism in the language + libraries too ( e.g. Rayon
https://github.com/nikomatsakis/rayon )

5) Far higher security in the VM .. this is not to say the current VM has
any issues with security, but this is ensured by very high quality of
coding and putting trust in that. Rust will eliminate the most common
security issues found in code today. This extends into both future
developments ( you can't guarantee secure code to day is secure after code
changes ) and security of all included libaries. Tho Erlang was not
effected by openSSL issues ( due to what parts it did / did not use ) it
still included a code base with a gigantic security issue .. importing (
mostly ) native rust libraries and their updates would improve this greatly

6) Reducing the need for nifs : most NIF's ( tho not all ) are written for
performance, with a much faster VM these may not be needed

7) Writing more of the VM / BIF's in Erlang, due to the higher performance

8) Secure, crash resistant NIFS written in Rust

9) Far smaller more modern implementation

10) Far more portable & embeddable implementation. It would be fantastic to
be able to compile the VM and run it in the browser using WebAssembly, be
able to embed Erlang into a desktop app, maybe simply to use its networking
functionality, embed it into other libraries for other languages etc.. (
like Lua embedded for example )

11) Making use of the Cargo packages and package manager for Rust. A huge
benefit to rust is how good the package manager is and the amazing number
of amazing packages. There are for example a huge range of lock free
concurrent data structures right there in Cargo. These could be very useful
in building the erlang VM

12) Far more modular implementation. Modern Rust applications are a
collection of modest sized packages, built using Cargo rather than one
gigantic code base. This allows far better code sharing between unrelated
projects + often far better testing of each model & often more stable /
better API designs per module.

13) A formally verified vm?

14) Setting a future direction where all low level code is written in
secure, modern, memory safe languages

Anyhow my 2 pence !

On 20 September 2017 at 16:31, Jeremy Pierre <j.14159@REDACTED> wrote:

> Begging the list's indulgence with tangential and possibly off-topic
> content.
>
> On Tue, Sep 19, 2017 at 7:57 AM Daniel Goertzen <daniel.goertzen@REDACTED>
> wrote:
>
>> How does Alpaca compare to F#/Ocaml?  After tasting some Rust and Elm,
>> working in Erlang makes me a bit nervous too.  My dream is to see a BEAM
>> ML-like achieve Elixir stature.
>>
>>
> In terms of syntax it's closest to OCaml but it's worth noting we still
> lack some significant features one would be used to, e.g. ML's module
> system (and functors, etc) and you'll see hints of Elm in some places like
> our records.  We kept things like adding fields to records, e.g.
>
> let record_example () =
>   let r1 = {x="hello", y="world"} in
>   {pi=3.14 | r1}
>
> is perfectly legal without declaring those record types in advance.
>
> r1:  {x: string, y: string}
> record_example:  {pi: float, x: string, y: string}
>
> There's a basic tour of the language here if you're further curious:
> https://github.com/alpaca-lang/alpaca/blob/master/Tour.md
>
> The pending v0.2.8 release (held up by me being super slow on a couple of
> bugs I should have fixed months ago) adds some substantial stuff like type
> annotations and better compiler feedback (both community contributions!)
>
> Jeremy
>
>
>>
>> On Tue, Sep 19, 2017 at 8:57 AM Karl Nilsson <kjnilsson@REDACTED> wrote:
>>
>>> On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <
>>> jesper.louis.andersen@REDACTED> wrote:
>>>
>>>> On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <ok@REDACTED>
>>>> wrote:
>>>>
>>>>> What's your opinion of F#?  It seems to be the language
>>>>> of choice for people who liked Caml but need to take advantage
>>>>> of multiple cores.  I haven't done any benchmarking; I doubt
>>>>> that it could match OCaml in raw speed.
>>>>>
>>>>>
>>>> I have not used it enough to have an opinion (yet). Were I to
>>>> communicate a lot with the .NET platform, I'd probably pick it because it
>>>> has a null value and this is a necessity when talking to C# I'm told.
>>>>
>>>> Given that it runs under a pretty powerful JIT, it could perform really
>>>> well for a lot of tasks I think.
>>>>
>>>>
>>> F# doesn't typically have any speed advantages of any other .NET
>>> languages and in every comparison I've seen to OCaml it has performed
>>> worse. If anything the allocation costs induced by a functional first
>>> programming style means it is typically a bit slower than the equivalent C#
>>> code (also there is no goto).
>>>
>>> As a language F# is the nicest I've ever used substantially. I find it
>>> easy (and fun) to write reasonably correct code in. Also I hardly ever fear
>>> refactoring (compared to erlang where I break out in cold sweats even for
>>> code bases that pass dialyzer).
>>>
>>> I even like it so much I've started hacking on an fsharp to core erlang
>>> compiler. (https://github.com/kjnilsson/fez).
>>>
>>>
>>>
>>>> My "dream" would be an industry-supported parallel MLton :P
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> 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/9c4e7bfe/attachment.htm>