<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 21 September 2017 at 21:37, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">The project that interest me would go in the opposite direction to<br>
reimplementing the VM in Rust.<br>
<br>
I'd like to make an extremely small extremely slow Ertang targeted to<br>
IOT devices - low power devices with small memory and slow clocks.<br>
<br>
The goal would be a smaller VM with fewer instructions<br>
and a highly portable ANSI C interpreter.<br>
<br>
I think the only way to make secure systems is to throw away as much as<br>
possible and retain a small kernel with very limited ability.<br>
<br>
I'd like to see lots of very small machines talking to each other with<br>
defined protocols.<br>
<br>
I managed to find an early erlang from 1991 (the compiler still works)<br>
the compiler in was 4000 line of Ertang and the emulator was 3800 lines of C<br>
<br>
We didn't have binarys and maps but I think the *goodness* comes from<br>
links and mailboxes.<br>
<br>
Software gets more complex with time *because* we build upon earlier work<br>
*without* throwing away stuff.<br>
<br>
The problem is we when we build on old stuff we don't know which of the old<br>
stuff we can throw away, so we include it "just in case"<br>
<br>
Then it gets so complex we give up - and we seal it off in a virtual machine<br>
or container and carry on.<br>
<br>
N. Wirth said when you add a new feature you should remove an old one<br>
but we don't do this.<br>
<br>
A new VM in Rust or anything would be a good excuse to re-look at the<br>
architectures we want and see how to implement them - Just reimplementing<br>
Erlang would be miss a good opportunity to chuck out some weird design<br>
decisions and do some good things.<br></blockquote><div>Sounds fantastic and with a truly ideal implementation the same small implementation would also be performant at large scale as well </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Pids should be planetary wide references with a DHT to find them - processes<br>
should be first class and movable - Protocols should be first class ...<br></blockquote><div>Would be amazing tho pids would become very complex with the lightly security needs added on top, becoming language agnostic, ( message reliability ) etc.. </div><div>Ps what does protocols being first class mean btw?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
My 10 cents worth<br>
<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-HOEnZb"><font color="#888888">
/Joe<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
<br>
On Thu, Sep 21, 2017 at 9:42 PM, James Churchman<br>
<<a href="mailto:jameschurchman@gmail.com">jameschurchman@gmail.com</a>> wrote:<br>
><br>
><br>
> On 21 September 2017 at 19:26, Felix Gallo <<a href="mailto:felixgallo@gmail.com">felixgallo@gmail.com</a>> wrote:<br>
>><br>
>> I think Rust takes several steps in wrong directions, but the answer to<br>
>> (2) is obvious -- even though we've had 40 years to learn how to 'better<br>
>> code our drivers', the world of software is a shaky, broken, rickety pile of<br>
>> insecure nonsense and it's only getting worse over time.  There is<br>
>> apparently no amount of learning we can do and we need the machines to help<br>
>> us.<br>
>><br>
>> Erlang solves the memory safety problem by enforcing immutability, which<br>
>> has incredibly low mechanical sympathy and ends up being unperformant for a<br>
>> large and useful set of problems.  Rust solves it by giving the developer a<br>
>> bewilderingly bedazzled straitjacket and telling them to sort it out if they<br>
>> want performance.  Pony's straitjacket has better affordances in my opinion<br>
>> but is still deeply confusing to developers.  The fact that we are all<br>
>> trying is no accident.<br>
><br>
><br>
> Indeed... there are some algorithms that are orders of magnitude slower to<br>
> write with immutability. The systems that Erlang is designed for quite often<br>
> are not these tho, + NIF's can fill the gap, tho not in an elegant way (<br>
> embedding a totally different language that forces you to give up all<br>
> guarantees that Erlang has, tho rust would help here as it should not crash<br>
> the VM )<br>
><br>
> You should try the borrow checker in rust.. it takes time to get used to and<br>
> there are few times you have rethink a way of coding something but it gives<br>
> memory safety with no GC .. really amazing .. on top of that you can write<br>
> "unsafe" rust with less guarantees, and do as you feel .. no restrictions at<br>
> all. Its also possible to write GC code too, have yet to try it but was<br>
> originally optional in the language & all the hooks left in the language in<br>
> the type system, so a few are available as installable as packages ... some<br>
> algorithms ( maybe writing a graph database or similar ? ) are easier with a<br>
> GC so you just create those objects as being handled by the GC ..<br>
><br>
><br>
> Its also worth remembering that the entire Erlang runtime has already been<br>
> re-written, in Java, with performance between beam and hype, able to run<br>
> apps like riak and the only downside being some small gc pauses, that may<br>
> not even happen on a modern JVM<br>
><br>
>><br>
>> F.<br>
>><br>
>> F.<br>
>> On 21 September 2017 at 18:12, Frank Muller <<a href="mailto:frank.muller.erl@gmail.com">frank.muller.erl@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Erlang newbie here ...  jumping into the subject.<br>
>>><br>
>>> While agree with most of the ideas about security, speed ... I still<br>
>>> can't get some really basic things.<br>
>>><br>
>>> 1. Why one should trade a time-proven, close to metal, fars language like<br>
>>> C with more than ~40yrs of existence with a new one? We don't even know if<br>
>>> Rust will exist in the near future. That's not gonna be the case for C<br>
>>> apparently (IoT, etc.).<br>
><br>
><br>
> Well the existence of Rust ( or any language ) will depend entirely on how<br>
> many new projects and existing ( c ) projects written in it!<br>
> Large sections of Firefox are now written in Rust ( in a version thats<br>
> shipping very soon ) cross ported from the Servo project, which gave rise to<br>
> rust in order to build a totally new browser engine .. given that browsers<br>
> are now some of the largest software projects on the planet this is a good<br>
> sign. These include the CSS parser, CSS matcher, the Compositor and several<br>
> more .. the eventual plan is to move everything over.<br>
> The benefits are many, and it still maintains C ABI compatibility if you<br>
> need it.<br>
><br>
><br>
>><br>
>><br>
>>><br>
>>> 2. Why simply not simply learn how to better code our NIF/Drivers<br>
>>> instead? C was/is my main programming language for many years now, and I<br>
>>> didn't have any major issue with it (medium to large projects) in production<br>
>>> environment so far. Maybe I'm just lucky, maybe not.<br>
>><br>
>><br>
><br>
> Well the more the tooling and language can do for you the better, and the<br>
> more guarantees of correctness the more secure your software is likely to<br>
> be. One of many reasons for rewriting Firefox in rust is security. Most C<br>
> projects probably don't have hundreds/thousands of security guys trying to<br>
> cause memory overflow errors, but for things like browsers, VM's, OS's they<br>
> do, and with the increase of IOT many products that were not traditionally<br>
> exposed to the internet now are .. and when one is discovered it's usually<br>
> game over!<br>
><br>
><br>
><br>
</div></div><div class="gmail-HOEnZb"><div class="gmail-h5">> ______________________________<wbr>_________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
><br>
</div></div></blockquote></div><br></div></div>