[erlang-questions] Erlang VM in Rust

Thu Sep 21 18:42:06 CEST 2017

People interested in Rust and Erlang should look into Pony (
https://www.ponylang.org), which is an LLVM-targeting, actor-model,
memory-safe, race-free language with rich types and a small but growing
userbase.

On Thu, Sep 21, 2017 at 9:15 AM, James Churchman <jameschurchman@REDACTED>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/ca3a0efb/attachment.htm>