<div dir="ltr">People interested in Rust and Erlang should look into Pony ( <a href="https://www.ponylang.org">https://www.ponylang.org</a>), which is an LLVM-targeting, actor-model, memory-safe, race-free language with rich types and a small but growing userbase.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 21, 2017 at 9:15 AM, James Churchman <span dir="ltr"><<a href="mailto:jameschurchman@gmail.com" target="_blank">jameschurchman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>The cost of the rewrite in rust would be quite large, including:</div><div><br></div><div>1) A time consuming, complex process for a full rewrite</div><div><br></div><div>2) New bugs in the new implementation that will take a while to trace down </div><div>( tho the prevalence of large code bases written in Erlang with randomised property tests would help find these a lot faster tho ) </div><div><br></div><div>3) Incompatibilities that are likely inevitable</div><div><br></div><div>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<br><div><br></div><div>5) New users asking "which VM should I chose for my deployment" and the lightly very complex answers that come back causing some confusion.</div><div><br></div><div>6) Breaking NIF & C driver compatibility ( tho, it may be possible to provide a compatibility layer in some circumstances )</div><div><br></div><div>7) Some tooling ( e.g. the debugger if its used by anyone etc.. ) no longer working </div><div><br></div><div>8) Platform portability being slightly different vs the current vm</div><div><br></div><div>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</div><div><br></div><div><br></div><div>The advantages going forward would be huge :</div><div><br></div><div>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 </div><div><br></div><div>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.. </div><div><br></div><div>3) Encouraging more open source contributions to the VM<br></div><div><br></div><div>4) Fantastic parallelism in the language + libraries too ( e.g. Rayon <a href="https://github.com/nikomatsakis/rayon" target="_blank">https://github.com/<wbr>nikomatsakis/rayon</a> )</div><div><br></div><div>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 </div><div><br></div><div>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</div><div><br></div><div>7) Writing more of the VM / BIF's in Erlang, due to the higher performance</div><div><br></div><div>8) Secure, crash resistant NIFS written in Rust </div><div><br></div><div>9) Far smaller more modern implementation </div><div><br></div><div>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 )</div><div><br></div><div>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</div><div><br></div><div>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.<br></div><div><br></div><div>13) A formally verified vm?</div><div><br></div><div>14) Setting a future direction where all low level code is written in secure, modern, memory safe languages </div><div><br></div><div><br></div><div>Anyhow my 2 pence !</div><div><br></div><div><br><div><br></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 20 September 2017 at 16:31, Jeremy Pierre <span dir="ltr"><<a href="mailto:j.14159@gmail.com" target="_blank">j.14159@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Begging the list's indulgence with tangential and possibly off-topic content.<br><br><div class="gmail_quote"><span><div dir="ltr">On Tue, Sep 19, 2017 at 7:57 AM Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div dir="ltr"><br></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>let record_example () =</div><div>  let r1 = {x="hello", y="world"} in</div><div>  {pi=3.14 | r1} </div><div><br></div><div>is perfectly legal without declaring those record types in advance.</div><div><br></div><div>r1:  {x: string, y: string}</div><div>record_example:  {pi: float, x: string, y: string}</div><div><br></div><div>There's a basic tour of the language here if you're further curious:  <a href="https://github.com/alpaca-lang/alpaca/blob/master/Tour.md" target="_blank">https://github.com/alpaca-lan<wbr>g/alpaca/blob/master/Tour.md</a></div><div><br></div><div>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!)<span class="m_2926157655760903620HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_2926157655760903620HOEnZb"><font color="#888888"><div>Jeremy</div></font></span><div><div class="m_2926157655760903620h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 19, 2017 at 8:57 AM Karl Nilsson <<a href="mailto:kjnilsson@gmail.com" target="_blank">kjnilsson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.c<wbr>om</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What's your opinion of F#?  It seems to be the language<br>
of choice for people who liked Caml but need to take advantage<br>
of multiple cores.  I haven't done any benchmarking; I doubt<br>
that it could match OCaml in raw speed.<br>
<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>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.</div><div><br></div><div>Given that it runs under a pretty powerful JIT, it could perform really well for a lot of tasks I think.</div></div><div class="gmail_quote"><br></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><span style="font-size:13px">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).</span><div style="font-size:13px"><br></div><div><span style="font-size:13px">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).</span></div><div><span style="font-size:13px"><br></span></div><div>I even like it so much I've started hacking on an fsharp to core erlang compiler. (<a href="https://github.com/kjnilsson/fez" target="_blank">https://github.com/kjnilsson/<wbr>fez</a>). </div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"></div><div class="gmail_quote">My "dream" would be an industry-supported parallel MLton :P<br></div></div>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
</blockquote></div></div>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
</blockquote></div></div>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
</blockquote></div></div></div></div>
<br>______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<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></blockquote></div><br></div>