Erlang VM in Rust

classic Classic list List threaded Threaded
79 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Anderson Torres
2017-09-16 8:18 GMT-03:00 Anthony Ramine <[hidden email]>:

> This is absolutely 100% wrong. This kind of code *is* hard to get correct. What about out of bound accesses or uses after free or data races like the bug I mentioned?
>
> --
> Anthony Ramine
>
>> Le 16 sept. 2017 à 12:03, Joe Armstrong <[hidden email]> a écrit :
>>
>> I'm not convinced that a better programming language to implement the VM helps -
>> the tricky bit is getting the VM machine instructions correct - at
>> this level of abstration
>> the VM is just moving memory around comparing things and jumping
>> around - which is pretty
>> easy inn *any* programming language.

It can be easy to implement, but ensure correctness is another thing.
As A. Ramine said, data races can surge almost from everywhere, and
even silly bugs as use-after-free.

If Rust can eliminate these things, it can be worth a looking, and if
not a full, from-scratch replacement, something more incremental: the
interpreters first, the "operating system" part after, and the
libraries can be changed on demand.

> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Jesper Louis Andersen-2
In reply to this post by Richard A. O'Keefe-2
On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <[hidden email]> 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.

My "dream" would be an industry-supported parallel MLton :P

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Karl Nilsson-2


On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <[hidden email]> wrote:
On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Richard Carlsson-3
2017-09-19 15:57 GMT+02:00 Karl Nilsson <[hidden email]>:
I even like it so much I've started hacking on an fsharp to core erlang compiler. (https://github.com/kjnilsson/fez).
 
You win the compiler naming contest.

    /Richard

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Daniel Goertzen-3
In reply to this post by Karl Nilsson-2
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.

On Tue, Sep 19, 2017 at 8:57 AM Karl Nilsson <[hidden email]> wrote:
On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <[hidden email]> wrote:
On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Zachary Kessin-2
I would love to see an Elm like language on the beam too, but I don't expect to see a first-class language of that type soon.

Zach

On Tue, Sep 19, 2017 at 5:57 PM, Daniel Goertzen <[hidden email]> 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.


On Tue, Sep 19, 2017 at 8:57 AM Karl Nilsson <[hidden email]> wrote:
On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <[hidden email]> wrote:
On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




--
Zach Kessin
Teaching Web Developers to test code to find more bugs in less time
Skype: zachkessin
+972 54 234 3956 / +44 203 734 9790 / +1 617 778 7213


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Jeremy Pierre
In reply to this post by Daniel Goertzen-3
Begging the list's indulgence with tangential and possibly off-topic content.

On Tue, Sep 19, 2017 at 7:57 AM Daniel Goertzen <[hidden email]> 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 <[hidden email]> wrote:
On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <[hidden email]> wrote:
On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

James Churchman
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 <[hidden email]> wrote:
Begging the list's indulgence with tangential and possibly off-topic content.

On Tue, Sep 19, 2017 at 7:57 AM Daniel Goertzen <[hidden email]> 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 <[hidden email]> wrote:
On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <[hidden email]> wrote:
On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

zxq9-2
On 2017年09月21日 木曜日 17:15:22 James Churchman wrote:
> ... or writing full apps in assembler ...

Have you any clue how many oversimplifications this implies?

I get the point you think you are trying to make but srsly, there is this thing called a processor, and IT IS ITS OWN GODDAM LANGUAGE WTF.

Trade one parade of blind-leading-the-blind for another.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Felix Gallo-2
In reply to this post by James Churchman
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 <[hidden email]> 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 <[hidden email]> wrote:
Begging the list's indulgence with tangential and possibly off-topic content.

On Tue, Sep 19, 2017 at 7:57 AM Daniel Goertzen <[hidden email]> 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 <[hidden email]> wrote:
On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <[hidden email]> wrote:
On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Loïc Hoguin-3
In reply to this post by James Churchman
On 09/21/2017 06:15 PM, James Churchman 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

There's a reason Netscape died...

Perhaps Rust can and should be used for parts of the VM, but a full
rewrite would be suicide, especially considering BEAM development does
not have gigantic resources to begin with.

Even if you rewrite only parts of the VM, while you're rewriting you're
not improving the features stack.

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Frank Muller
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.).

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.

Thanks for your comments and feedbacks.

/Frank

On 09/21/2017 06:15 PM, James Churchman 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

There's a reason Netscape died...

Perhaps Rust can and should be used for parts of the VM, but a full
rewrite would be suicide, especially considering BEAM development does
not have gigantic resources to begin with.

Even if you rewrite only parts of the VM, while you're rewriting you're
not improving the features stack.

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Felix Gallo-2
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.

F.

F.

On Thu, Sep 21, 2017 at 10:12 AM, Frank Muller <[hidden email]> 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.).

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.

Thanks for your comments and feedbacks.

/Frank

On 09/21/2017 06:15 PM, James Churchman 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

There's a reason Netscape died...

Perhaps Rust can and should be used for parts of the VM, but a full
rewrite would be suicide, especially considering BEAM development does
not have gigantic resources to begin with.

Even if you rewrite only parts of the VM, while you're rewriting you're
not improving the features stack.

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

James Churchman


On 21 September 2017 at 19:26, Felix Gallo <[hidden email]> 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 <[hidden email]> 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!



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Joe Armstrong-2
The project that interest me would go in the opposite direction to
reimplementing the VM in Rust.

I'd like to make an extremely small extremely slow Ertang targeted to
IOT devices - low power devices with small memory and slow clocks.

The goal would be a smaller VM with fewer instructions
and a highly portable ANSI C interpreter.

I think the only way to make secure systems is to throw away as much as
possible and retain a small kernel with very limited ability.

I'd like to see lots of very small machines talking to each other with
defined protocols.

I managed to find an early erlang from 1991 (the compiler still works)
the compiler in was 4000 line of Ertang and the emulator was 3800 lines of C

We didn't have binarys and maps but I think the *goodness* comes from
links and mailboxes.

Software gets more complex with time *because* we build upon earlier work
*without* throwing away stuff.

The problem is we when we build on old stuff we don't know which of the old
stuff we can throw away, so we include it "just in case"

Then it gets so complex we give up - and we seal it off in a virtual machine
or container and carry on.

N. Wirth said when you add a new feature you should remove an old one
but we don't do this.

A new VM in Rust or anything would be a good excuse to re-look at the
architectures we want and see how to implement them - Just reimplementing
Erlang would be miss a good opportunity to chuck out some weird design
decisions and do some good things.

Pids should be planetary wide references with a DHT to find them - processes
should be first class and movable - Protocols should be first class ...

My 10 cents worth

/Joe



On Thu, Sep 21, 2017 at 9:42 PM, James Churchman
<[hidden email]> wrote:

>
>
> On 21 September 2017 at 19:26, Felix Gallo <[hidden email]> 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 <[hidden email]>
>> 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!
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

James Churchman


On 21 September 2017 at 21:37, Joe Armstrong <[hidden email]> wrote:
The project that interest me would go in the opposite direction to
reimplementing the VM in Rust.

I'd like to make an extremely small extremely slow Ertang targeted to
IOT devices - low power devices with small memory and slow clocks.

The goal would be a smaller VM with fewer instructions
and a highly portable ANSI C interpreter.

I think the only way to make secure systems is to throw away as much as
possible and retain a small kernel with very limited ability.

I'd like to see lots of very small machines talking to each other with
defined protocols.

I managed to find an early erlang from 1991 (the compiler still works)
the compiler in was 4000 line of Ertang and the emulator was 3800 lines of C

We didn't have binarys and maps but I think the *goodness* comes from
links and mailboxes.

Software gets more complex with time *because* we build upon earlier work
*without* throwing away stuff.

The problem is we when we build on old stuff we don't know which of the old
stuff we can throw away, so we include it "just in case"

Then it gets so complex we give up - and we seal it off in a virtual machine
or container and carry on.

N. Wirth said when you add a new feature you should remove an old one
but we don't do this.

A new VM in Rust or anything would be a good excuse to re-look at the
architectures we want and see how to implement them - Just reimplementing
Erlang would be miss a good opportunity to chuck out some weird design
decisions and do some good things.
Sounds fantastic and with a truly ideal implementation the same small implementation would also be performant at large scale as well 

Pids should be planetary wide references with a DHT to find them - processes
should be first class and movable - Protocols should be first class ...
Would be amazing tho pids would become very complex with the lightly security needs added on top, becoming language agnostic, ( message reliability ) etc.. 
Ps what does protocols being first class mean btw?

My 10 cents worth



 
/Joe



On Thu, Sep 21, 2017 at 9:42 PM, James Churchman
<[hidden email]> wrote:
>
>
> On 21 September 2017 at 19:26, Felix Gallo <[hidden email]> 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 <[hidden email]>
>> 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!
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Joe Armstrong-2
On Thu, Sep 21, 2017 at 10:48 PM, James Churchman
<[hidden email]> wrote:

>
>
> On 21 September 2017 at 21:37, Joe Armstrong <[hidden email]> wrote:
>>
>> The project that interest me would go in the opposite direction to
>> reimplementing the VM in Rust.
>>
>> I'd like to make an extremely small extremely slow Ertang targeted to
>> IOT devices - low power devices with small memory and slow clocks.
>>
>> The goal would be a smaller VM with fewer instructions
>> and a highly portable ANSI C interpreter.
>>
>> I think the only way to make secure systems is to throw away as much as
>> possible and retain a small kernel with very limited ability.
>>
>> I'd like to see lots of very small machines talking to each other with
>> defined protocols.
>>
>> I managed to find an early erlang from 1991 (the compiler still works)
>> the compiler in was 4000 line of Ertang and the emulator was 3800 lines of
>> C
>>
>> We didn't have binarys and maps but I think the *goodness* comes from
>> links and mailboxes.
>>
>> Software gets more complex with time *because* we build upon earlier work
>> *without* throwing away stuff.
>>
>> The problem is we when we build on old stuff we don't know which of the
>> old
>> stuff we can throw away, so we include it "just in case"
>>
>> Then it gets so complex we give up - and we seal it off in a virtual
>> machine
>> or container and carry on.
>>
>> N. Wirth said when you add a new feature you should remove an old one
>> but we don't do this.
>>
>> A new VM in Rust or anything would be a good excuse to re-look at the
>> architectures we want and see how to implement them - Just reimplementing
>> Erlang would be miss a good opportunity to chuck out some weird design
>> decisions and do some good things.
>
> Sounds fantastic and with a truly ideal implementation the same small
> implementation would also be performant at large scale as well
>>
>>
>> Pids should be planetary wide references with a DHT to find them -
>> processes
>> should be first class and movable - Protocols should be first class ...
>
> Would be amazing tho pids would become very complex with the lightly
> security needs added on top, becoming language agnostic, ( message
> reliability ) etc..
> Ps what does protocols being first class mean btw?

Protocols are implicit and you can imply them by reading the code.
I'd like a protocol declaration (like a module definition) that *defines*
the sequence of allowed operations. Some people call these session types :-)

-protocol(file_server)
-agents(client, server)

client ! server {send_file,F} -> server ! client ({ok,Bin} |enofile)

...

-end(protocol).

Then at run time you could query the protocol

-process(c1)
-implements(file_server, client)
...

...

/Joe



>>
>>
>> My 10 cents worth
>>
>
>
>
>>
>> /Joe
>>
>>
>>
>> On Thu, Sep 21, 2017 at 9:42 PM, James Churchman
>> <[hidden email]> wrote:
>> >
>> >
>> > On 21 September 2017 at 19:26, Felix Gallo <[hidden email]> 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
>> >> <[hidden email]>
>> >> 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!
>> >
>> >
>> >
>> > _______________________________________________
>> > erlang-questions mailing list
>> > [hidden email]
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> >
>
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Attila Rajmund Nohl
In reply to this post by Frank Muller
2017-09-21 19:12 GMT+02:00 Frank Muller <[hidden email]>:
[...]
> 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.

Probably you're lucky. Last time I worked on a C code, there was a
mysterious (but thankfully reproducable) crash. According to the core
file the process tried to follow a null pointer variable, but if I
checked the memory where the variable was, it was not null. I went
down to the assembly code and the contents of the registers, there was
nothing that explained the crash. The variable was in a structure that
was initialized at startup, then never written. In final despair I
moved the initialization from runtime to compile time and made that
structure const hoping that the compiler/linker/kernel will put the
structure into read-only memory so if anything tries to write to it,
I'd get the crash at that time. Guess what happened: the original
crash went away. Probably the memory was reorganized in a way that the
stray overwrite now didn't touch this particular variable. And no,
memory debuggers didn't help, ElectricFence didn't found the error,
Valgrind didn't worked in that environment. I'm so glad that I don't
have to work on that kind of C code anymore.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

scott ribe
> Probably you're lucky. Last time I worked on a C code, there was a
> mysterious (but thankfully reproducable) crash. According to the core
> file the process tried to follow a null pointer variable, but if I
> checked the memory where the variable was, it was not null. I went
> down to the assembly code and the contents of the registers, there was
> nothing that explained the crash. The variable was in a structure that
> was initialized at startup, then never written. In final despair I
> moved the initialization from runtime to compile time and made that
> structure const hoping that the compiler/linker/kernel will put the
> structure into read-only memory so if anything tries to write to it,
> I'd get the crash at that time. Guess what happened: the original
> crash went away. Probably the memory was reorganized in a way that the
> stray overwrite now didn't touch this particular variable. And no,
> memory debuggers didn't help, ElectricFence didn't found the error,
> Valgrind didn't worked in that environment. I'm so glad that I don't
> have to work on that kind of C code anymore.

And that's why I'm hesitant to ever start another major project in C. I've got them out there that are pretty reliable, but it takes a lot of work to get to that point, and one single tiny error within a huge code base can lead to what you describe.

--
Scott Ribe
[hidden email]
(303) 722-0567

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Anthony Ramine-4
In reply to this post by Joe Armstrong-2
Joe you are still ignoring the elephant in the room that C is a memory-unsafe programming language and that you are suggesting putting it in IoT stuff. That's a security disaster waiting to happen.

> Le 21 sept. 2017 à 22:37, Joe Armstrong <[hidden email]> a écrit :
>
> I'd like to make an extremely small extremely slow Ertang targeted to
> IOT devices - low power devices with small memory and slow clocks.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
1234