[erlang-questions] Erlang VM in Rust

[James Churchman]

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