Erlang VM in Rust

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Anthony Ramine-4
C++ would never avoid crappy things from happening, such as silly data races because someone used a static variable in the middle of nowhere[1].

Rust would.

Rewriting something in C++ in the year of our lord of 2017 isn't the smartest move when there are better tools available. Well I guess it's good for job security, but there is Erlang itself for that already.

As for the emulator loop which requires computed gotos to be implemented, it could instead be generated from a higher-level description of the opcodes directly to an LLVM IR module, which would be faster to compile because the CFG would be less silly written by hand. Using LLVM IR is also something the JIT project I don't remember the name wants to do anyway.

As for what would Rust bring us (apart from a massive improvement of the memory safety of the whole VM), Rust allows people to be way more reckless when writing code, and that usually ends up with less runtime safety belts in the system [2].

I started writing a BEAM module loader in Rust (but I work on it only during holidays because I am actually busy at Mozilla working on things 10 years ahead of the rest of the world), and I think I found some issues in BEAM's code already. I will try to cook some BEAM compiled modules that weird out the VM in the near future.

[1]: https://github.com/erlang/otp/pull/643
[2]: http://www.randomhacks.net/2014/09/19/rust-lifetimes-reckless-cxx/

> Le 13 sept. 2017 à 03:30, zxq9 <[hidden email]> a écrit :
>
> On 2017年09月12日 火曜日 17:05:33 Tristan Sloughter wrote:
>> Maybe Tony 'the tiger' Ramine would come back to working on Erlang if it
>> was in Rust!
>
> Hey!
> I really like that guy.
>
> Almost a good enough reason on its own. But I'm being selfish. ;-)
>
> -Craig
> _______________________________________________
> 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

Roman Galeev
In reply to this post by Jesper Louis Andersen-2
 > don't underestimate how productive Erlang 

I don't. In Erlang, I can make a system to work relatively quickly, and with all these features like resilience and concurrency, even with some distribution, and I like it. On the other hand, a powerful type system can ease life a lot too. Kind of a tradeoff you've mentioned I guess. Anyway, thank you for the detailed response.

On Wed, Sep 13, 2017 at 1:43 PM, Jesper Louis Andersen <[hidden email]> wrote:
On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <[hidden email]> wrote:
> Personally, I'd just throw some more time after concurrent OCaml, and then write a translator from Erlang to OCaml :P

Do you think concurrent OCaml has advantages over Erlang? And if yes, what are they, in your opinion?

You are making tradeoffs whenever you choose another language.

* Semantically, OCaml is far superior to Erlang in any conceivable way.
* OCaml has a powerful type system, which Erlang doesn't.
* The native code generator in OCaml easily surpasses the bytecode interpreter in Erlang.

On the other hand:

* OCaml is currently not parallel in any way. There has been a long effort in fixing this, but even *if* it gets released, we are looking at years of maturing needed before we can hope for robust operation.
* OCaml currently uses something like Lwt and/or Async for concurrent work. This is Node.js in disguise. I don't believe in indirect concurrency codings in general, far preferring Erlang or Go's direct approaches (in which you favor preemption over cooperation in multitasking).
* OCaml is unlikely to ever support hot code upgrade.
* OCaml currently has no dTrace-style production ad-hoc tracing facilities where Erlang has it naturally.
* OCaml programs are easy to make robust (cope with unknown input), but harder to make resilient (coping gracefully with internal failure).

So proviso OCaml gets a good parallel story, and we can implement the important parts of Erlang on top of that, then I think there are programs which can be written in OCaml with advantage. In particular those which can afford to be restarted once in a while. This is true for many modern systems in which you are deploy clusters of nodes() and provisioning them this way. The prime candidate programs are those which require the efficiency the OCaml native code compiler provides and where you can't just run the OCaml program behind an Erlang Port easily.

The *current* state of the art: use OCaml whenever you have a problem requiring the combination of functional abstraction and efficiency[0]. If you don't require the abstraction levels OCaml provide, go for C, C++, Rust, Go, etc. But chances are that the added productivity of OCaml will get you a far better and faster program when you are working with a limited time frame, since you can try more solutions, quicker.

If your problem doesn't require efficient use of the CPU core, don't underestimate how productive Erlang is. Since everything are just Erlang terms, you can often write a good program in a fraction of the time it requires to come up with a good type model in something like OCaml. All tooling supports Erlang terms. This is a powerful abstraction which can be put to good use. And you get resilience on top. I should really blog about how unfairly effective Erlang is at being productive. Efficiency is far from the only important factor in software development.


[0] Haskell is another excellent candidate here.



--
With best regards,
     Roman Galeev,
     +420 702 817 968

_______________________________________________
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

Heinz Nikolaus Gies-2
In reply to this post by zxq9-2
There are some really big point to consider for not doing it too:

For once Rust is in it’s infancy, the whole language still changes, code that works today might not work tomorrow and libraries often depend on nightly builds and new features. This goes 100% against the erlang philosophy if a long time maintained system. A large project like erlang will amplify this problem even more then small projects do.

Rust supports a lot less platforms then C, erlang runs perfectly fine on nearly everything, rust won’t even run on FreeBSD 12 at this point. It would turn erlang on yet another ‘We only care about Linux’ project which would make me vomit. (Depending on who you ask making me vomit might not be a bad thing …)

That said rust is cool for NIFs and small projects, but the requirements for a platform like erlang are vastly different.

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

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Daniel Goertzen-3
In reply to this post by zxq9-2
- Rust got C-like unions as of 1.19 (20 July 2017).  This is primarily for interfacing with C code; in native Rust you almost always opt for enums (aka tagged unions, sum types).

- Rust does not have bitfields but it does have the same bit mashing operators as C (& | ^ !  << >>).   C bitfields have different memory layouts on different platforms which limits their usefulness.  All the microcontroller C code I've ever seen has opted for explicit bit mashing instead of bitfields.

- There is an OS written in Rust, https://www.redox-os.org/ .  The drivers are all in Rust.




On Tue, Sep 12, 2017 at 9:27 PM zxq9 <[hidden email]> wrote:
On 2017年09月13日 水曜日 01:47:08 Thom Cherryhomes wrote:
> For a language that purports to be a replacement for low-level systems
> programming, Rust not having bitfields or unions, would be a real pain in
> the ass to do any intricate hardware driver work... I'm guessing that Rust
> is designed by 20-somethings who have never done a line of assembler in
> their lives?

That is curious. I wonder if these have been deferred for the time being in favor of using C as an extension (as Rust conforms to the C ABI)?

-Craig
_______________________________________________
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 A. O'Keefe-2
In reply to this post by Jesper Louis Andersen-2


On 13/09/17 11:43 PM, Jesper Louis Andersen wrote:
[OCaml is better than Erlang in many ways]
[OCaml is not parallel]

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.

_______________________________________________
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 A. O'Keefe-2
In reply to this post by Daniel Goertzen-3


On 14/09/17 7:46 AM, Daniel Goertzen wrote:
> - Rust does not have bitfields but it does have the same bit mashing
> operators as C (& | ^ !  << >>).   C bitfields have different memory
> layouts on different platforms which limits their usefulness.  All the
> microcontroller C code I've ever seen has opted for explicit bit mashing
> instead of bitfields.

Back in the 1980s, I learned very quickly that bitfield manipulation in
C was (a) more portable and (b) faster if I used masking and shifting
than if I used bitfield syntax.  Compilers have got a lot better since
then, but (a) is still an issue.  However, when you want bitfields in C,
it's usually to interface with something that is platform-specific
anyway.  For example, code to get at the fields of an IEEE floating-
point number.
_______________________________________________
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 Heinz Nikolaus Gies-2
Just don't use unstable features. You can do a damn lot without them, like the whole style system of Servo that is landing in Firefox 57.

        https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/

That may not be the correct venue to discuss this, of course. :)

The argument about embedded platforms in 100% correct, though. Rust isn't ready yet on that front.

> Le 13 sept. 2017 à 17:11, Heinz N. Gies <[hidden email]> a écrit :
>
> For once Rust is in it’s infancy, the whole language still changes, code that works today might not work tomorrow and libraries often depend on nightly builds and new features.

_______________________________________________
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

Tristan Sloughter-4
In reply to this post by Jesper Louis Andersen-2
Alternatively, work on Alpaca (https://github.com/alpaca-lang/alpaca) and improvements to BEAM :)

--
  Tristan Sloughter
  "I am not a crackpot" - Abe Simpson


On Wed, Sep 13, 2017, at 04:43 AM, Jesper Louis Andersen wrote:
On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <[hidden email]> wrote:
> Personally, I'd just throw some more time after concurrent OCaml, and then write a translator from Erlang to OCaml :P

Do you think concurrent OCaml has advantages over Erlang? And if yes, what are they, in your opinion?

You are making tradeoffs whenever you choose another language.

* Semantically, OCaml is far superior to Erlang in any conceivable way.
* OCaml has a powerful type system, which Erlang doesn't.
* The native code generator in OCaml easily surpasses the bytecode interpreter in Erlang.

On the other hand:

* OCaml is currently not parallel in any way. There has been a long effort in fixing this, but even *if* it gets released, we are looking at years of maturing needed before we can hope for robust operation.
* OCaml currently uses something like Lwt and/or Async for concurrent work. This is Node.js in disguise. I don't believe in indirect concurrency codings in general, far preferring Erlang or Go's direct approaches (in which you favor preemption over cooperation in multitasking).
* OCaml is unlikely to ever support hot code upgrade.
* OCaml currently has no dTrace-style production ad-hoc tracing facilities where Erlang has it naturally.
* OCaml programs are easy to make robust (cope with unknown input), but harder to make resilient (coping gracefully with internal failure).

So proviso OCaml gets a good parallel story, and we can implement the important parts of Erlang on top of that, then I think there are programs which can be written in OCaml with advantage. In particular those which can afford to be restarted once in a while. This is true for many modern systems in which you are deploy clusters of nodes() and provisioning them this way. The prime candidate programs are those which require the efficiency the OCaml native code compiler provides and where you can't just run the OCaml program behind an Erlang Port easily.

The *current* state of the art: use OCaml whenever you have a problem requiring the combination of functional abstraction and efficiency[0]. If you don't require the abstraction levels OCaml provide, go for C, C++, Rust, Go, etc. But chances are that the added productivity of OCaml will get you a far better and faster program when you are working with a limited time frame, since you can try more solutions, quicker.

If your problem doesn't require efficient use of the CPU core, don't underestimate how productive Erlang is. Since everything are just Erlang terms, you can often write a good program in a fraction of the time it requires to come up with a good type model in something like OCaml. All tooling supports Erlang terms. This is a powerful abstraction which can be put to good use. And you get resilience on top. I should really blog about how unfairly effective Erlang is at being productive. Efficiency is far from the only important factor in software development.


[0] Haskell is another excellent candidate here.
_______________________________________________
erlang-questions mailing list


_______________________________________________
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
It seems to me an Idea that is interesting in theory but would involve a *LOT* of work for an unclear benefit.

Zach

On Thu, Sep 14, 2017 at 1:54 AM, Tristan Sloughter <[hidden email]> wrote:
Alternatively, work on Alpaca (https://github.com/alpaca-lang/alpaca) and improvements to BEAM :)

--
  Tristan Sloughter
  "I am not a crackpot" - Abe Simpson


On Wed, Sep 13, 2017, at 04:43 AM, Jesper Louis Andersen wrote:
On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <[hidden email]> wrote:
> Personally, I'd just throw some more time after concurrent OCaml, and then write a translator from Erlang to OCaml :P

Do you think concurrent OCaml has advantages over Erlang? And if yes, what are they, in your opinion?

You are making tradeoffs whenever you choose another language.

* Semantically, OCaml is far superior to Erlang in any conceivable way.
* OCaml has a powerful type system, which Erlang doesn't.
* The native code generator in OCaml easily surpasses the bytecode interpreter in Erlang.

On the other hand:

* OCaml is currently not parallel in any way. There has been a long effort in fixing this, but even *if* it gets released, we are looking at years of maturing needed before we can hope for robust operation.
* OCaml currently uses something like Lwt and/or Async for concurrent work. This is Node.js in disguise. I don't believe in indirect concurrency codings in general, far preferring Erlang or Go's direct approaches (in which you favor preemption over cooperation in multitasking).
* OCaml is unlikely to ever support hot code upgrade.
* OCaml currently has no dTrace-style production ad-hoc tracing facilities where Erlang has it naturally.
* OCaml programs are easy to make robust (cope with unknown input), but harder to make resilient (coping gracefully with internal failure).

So proviso OCaml gets a good parallel story, and we can implement the important parts of Erlang on top of that, then I think there are programs which can be written in OCaml with advantage. In particular those which can afford to be restarted once in a while. This is true for many modern systems in which you are deploy clusters of nodes() and provisioning them this way. The prime candidate programs are those which require the efficiency the OCaml native code compiler provides and where you can't just run the OCaml program behind an Erlang Port easily.

The *current* state of the art: use OCaml whenever you have a problem requiring the combination of functional abstraction and efficiency[0]. If you don't require the abstraction levels OCaml provide, go for C, C++, Rust, Go, etc. But chances are that the added productivity of OCaml will get you a far better and faster program when you are working with a limited time frame, since you can try more solutions, quicker.

If your problem doesn't require efficient use of the CPU core, don't underestimate how productive Erlang is. Since everything are just Erlang terms, you can often write a good program in a fraction of the time it requires to come up with a good type model in something like OCaml. All tooling supports Erlang terms. This is a powerful abstraction which can be put to good use. And you get resilience on top. I should really blog about how unfairly effective Erlang is at being productive. Efficiency is far from the only important factor in software development.


[0] Haskell is another excellent candidate here.
_______________________________________________
erlang-questions mailing list


_______________________________________________
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

Raimo Niskanen-2
In reply to this post by Thom Cherryhomes
On Wed, Sep 13, 2017 at 01:47:08AM +0000, Thom Cherryhomes wrote:
:
> the ass to do any intricate hardware driver work... I'm guessing that Rust
> is designed by 20-somethings who have never done a line of assembler in
> their lives?

That was a bit offensive...

>
> sigh.
> -Thom


--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
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

Max Lapshin-2
Good topic =)

We are writing right now IP camera firmware in Rust and I can tell you: it is COMPLICATED =)

When Rust comes to Future and Stream, it becomes a really cryptic thing for a newcomer.

However, one can wait that writing something in Rust will allow to use all power of LLVM.

_______________________________________________
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 Thom Cherryhomes

> Le 13 sept. 2017 à 03:47, Thom Cherryhomes <[hidden email]> a écrit :
>
> For a language that purports to be a replacement for low-level systems programming, Rust not having bitfields or unions, would be a real pain in the ass to do any intricate hardware driver work... I'm guessing that Rust is designed by 20-somethings who have never done a line of assembler in their lives?

It must be a real treat to work with you!

You seem to be working on "a next generation smart home system", so how do you feel about the inevitable breach of security your product will be hit with for not using memory-safe languages? Or are you one of these people who think "only bad programmers write insecure C/C++ code"?

Anyway, you are the one who sounds like an immature 20-somethings here.
_______________________________________________
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

Heinz Nikolaus Gies-2
In reply to this post by Anthony Ramine-4
Oh yes don’t get me wrong, rust IS great, I use it for some applications myself, but those applications are short running or frequently restarting (like a browse ;) the occasional update there is not a problem at all, but yea the kind of things erlang is often used probably doesn’t share that characteristic.

> On 14. Sep 2017, at 00:25, Anthony Ramine <[hidden email]> wrote:
>
> Just don't use unstable features. You can do a damn lot without them, like the whole style system of Servo that is landing in Firefox 57.
>
> https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/
>
> That may not be the correct venue to discuss this, of course. :)
>
> The argument about embedded platforms in 100% correct, though. Rust isn't ready yet on that front.
>
>> Le 13 sept. 2017 à 17:11, Heinz N. Gies <[hidden email]> a écrit :
>>
>> For once Rust is in it’s infancy, the whole language still changes, code that works today might not work tomorrow and libraries often depend on nightly builds and new features.
>

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

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Benoit Chesneau-2
While we are on it , does rust run on solaris?

- benoit

> On 14 Sep 2017, at 23:49, Heinz N. Gies <[hidden email]> wrote:
>
> Oh yes don’t get me wrong, rust IS great, I use it for some applications myself, but those applications are short running or frequently restarting (like a browse ;) the occasional update there is not a problem at all, but yea the kind of things erlang is often used probably doesn’t share that characteristic.
>> On 14. Sep 2017, at 00:25, Anthony Ramine <[hidden email]> wrote:
>>
>> Just don't use unstable features. You can do a damn lot without them, like the whole style system of Servo that is landing in Firefox 57.
>>
>> https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/
>>
>> That may not be the correct venue to discuss this, of course. :)
>>
>> The argument about embedded platforms in 100% correct, though. Rust isn't ready yet on that front.
>>
>>> Le 13 sept. 2017 à 17:11, Heinz N. Gies <[hidden email]> a écrit :
>>>
>>> For once Rust is in it’s infancy, the whole language still changes, code that works today might not work tomorrow and libraries often depend on nightly builds and new features.
>>
>
> _______________________________________________
> 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

Sergej Jurečko
In reply to this post by Max Lapshin-2

> On 14 Sep 2017, at 13:10, Max Lapshin <[hidden email]> wrote:
>
> Good topic =)
>
> We are writing right now IP camera firmware in Rust and I can tell you: it is COMPLICATED =)
>
> When Rust comes to Future and Stream, it becomes a really cryptic thing for a newcomer.

Rust Futures are way overhyped, overused and I think the last thing a newcomer should be using.

Regards,
Sergej



_______________________________________________
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

Heinz Nikolaus Gies-2
In reply to this post by Benoit Chesneau-2
The answer would have to be “a bit” it’s on and off depending on packages available and versions, same goes for BSD sadly.

While rust does make an real effort to run outside of linux it’s very much “linux or good luck to you my frinbed” these days ...

> On 15. Sep 2017, at 17:28, Benoit Chesneau <[hidden email]> wrote:
>
> While we are on it , does rust run on solaris?
>
> - benoit
>> On 14 Sep 2017, at 23:49, Heinz N. Gies <[hidden email]> wrote:
>>
>> Oh yes don’t get me wrong, rust IS great, I use it for some applications myself, but those applications are short running or frequently restarting (like a browse ;) the occasional update there is not a problem at all, but yea the kind of things erlang is often used probably doesn’t share that characteristic.
>>> On 14. Sep 2017, at 00:25, Anthony Ramine <[hidden email]> wrote:
>>>
>>> Just don't use unstable features. You can do a damn lot without them, like the whole style system of Servo that is landing in Firefox 57.
>>>
>>> https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/
>>>
>>> That may not be the correct venue to discuss this, of course. :)
>>>
>>> The argument about embedded platforms in 100% correct, though. Rust isn't ready yet on that front.
>>>
>>>> Le 13 sept. 2017 à 17:11, Heinz N. Gies <[hidden email]> a écrit :
>>>>
>>>> For once Rust is in it’s infancy, the whole language still changes, code that works today might not work tomorrow and libraries often depend on nightly builds and new features.
>>>
>>
>> _______________________________________________
>> 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

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Sergej Jurečko

> On 15 Sep 2017, at 19:47, Heinz N. Gies <[hidden email]> wrote:
>
> The answer would have to be “a bit” it’s on and off depending on packages available and versions, same goes for BSD sadly.
>
> While rust does make an real effort to run outside of linux it’s very much “linux or good luck to you my frinbed” these days …

Linux or good luck is far from true. Rust works just fine and is well supported on Windows, macOS, iOS and Android. All giant platforms, though user not server oriented. Obviously a consequence of the largest Rust user being Mozilla.

Regards,
Sergej
_______________________________________________
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

Heinz Nikolaus Gies-2
True macOS and Windows are both tier 1 platforms for rust (along with linux as 3 rd option). I don’t think it’s very relevant however, as you said yourself neither are server oriented systems (windows might a bit be). But for the majority of users it’d effectively be ‘linux or good luck’ unless they plan to deploy on a macbook.

> On 15. Sep 2017, at 20:01, Sergej Jurečko <[hidden email]> wrote:
>
>
>> On 15 Sep 2017, at 19:47, Heinz N. Gies <[hidden email]> wrote:
>>
>> The answer would have to be “a bit” it’s on and off depending on packages available and versions, same goes for BSD sadly.
>>
>> While rust does make an real effort to run outside of linux it’s very much “linux or good luck to you my frinbed” these days …
>
> Linux or good luck is far from true. Rust works just fine and is well supported on Windows, macOS, iOS and Android. All giant platforms, though user not server oriented. Obviously a consequence of the largest Rust user being Mozilla.
>
> Regards,
> Sergej

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

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Joe Armstrong-2
Reimplementing Erlang in Rust would be a huge task if you want 100%
compatibility

Erlang is several things

1) A programming language
2) A huge set of libraries
3) A large set of tools

The language can be implemented as a byte code emulator (or threaded
word emulator)
+ a load of BIFs (or NIFs)

The emulator bit is easy (apart from the GC and process management) -
the problem is
all the BIFs and NIFs that are not written in Erlang but written in C.

If I was going to re-implement Erlang I'd try to define a subset of
Erlang with which the
entire emulator GC and process management code could be written.
This subset would be such that it could be cross-compiled to C (or
Rust, or anything)

The goal would be to write MORE in Erlang not less - unfortunately the
trend of the
last few years has been to write LESS in Erlang and more in C (ie with
NIFS) - this improves
performance but makes reimplementation far more difficult.

The path we took in the early 1990's was to make erlang more
performant at the expense of portability. So we moved from a byte
coded machine (JAM) to a threaded word interpretor
(BEAM) - the machine got bigger not smaller.

What we never tried was moving in the opposite direction of making the
machine smaller
and more portable - I'm thinking an ANSI C interpreter and huffman
encoded instructions.
In the 1990's this would have been far slower than the JAM - but today
we're talking GHz
whereas it was MHz in the 1990's.

It would be great tor re-engineer Erlang, and to take the opportunity
to make it more
portable and smaller.

If we had in mind the goals "very small", "very portable", "as much as
possible in erlang, as little as is necessary in C/rust" we might end
up with a nice machine.

I think the gains would come from a careful re-design of the VM not
changing the machine in which the VM is implemented. I believe the Lua
VM has 37 instructions and a small emulator.
The trick is having a VM with correct instructions for implementing Erlang .

The JVM and .NET have the wrong instructions - the JAM and BEAM have
(or had) single
instructions for spawning processes and sending messages - I guess
these could be
augmented with Opcodes for micro GCs and process management.

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.

In my opinion the great progenitor of VMs was the Pascal P-code
machine (from which
.NET and JVM derive) - then came the WAM (for Prolog) then we added opcodes for
process spawning and message passing (JAM) and turned this into
threaded code (BEAM) .

What would be an interesting experiment would be re-engineer the VM
turning all the
things essential to Erlang and Elixir  into opcodes and make an
emulator for this.

The emulator should (or course) we written in a dialect of Erlang and
cross-compiled to C
(or Rust()

Note: This is how we didn't implement Erlang. I designed and
implemented the original VM and opcodes in Prolog - then Mike William
re-implemented the Prolog emulator in C.

The mistake here was that Prolog has built-in GC and C does not - so
there were no
instructions in the JAM for GC (just an instruction so say when the
stack and heap were in
a safe state for GC to occur)

By all means re-implement Erlang - but make it smaller and more
portable, and forget the NIFs


Cheers

/Joe







On Fri, Sep 15, 2017 at 9:20 PM, Heinz N. Gies <[hidden email]> wrote:

> True macOS and Windows are both tier 1 platforms for rust (along with linux as 3 rd option). I don’t think it’s very relevant however, as you said yourself neither are server oriented systems (windows might a bit be). But for the majority of users it’d effectively be ‘linux or good luck’ unless they plan to deploy on a macbook.
>
>> On 15. Sep 2017, at 20:01, Sergej Jurečko <[hidden email]> wrote:
>>
>>
>>> On 15 Sep 2017, at 19:47, Heinz N. Gies <[hidden email]> wrote:
>>>
>>> The answer would have to be “a bit” it’s on and off depending on packages available and versions, same goes for BSD sadly.
>>>
>>> While rust does make an real effort to run outside of linux it’s very much “linux or good luck to you my frinbed” these days …
>>
>> Linux or good luck is far from true. Rust works just fine and is well supported on Windows, macOS, iOS and Android. All giant platforms, though user not server oriented. Obviously a consequence of the largest Rust user being Mozilla.
>>
>> Regards,
>> Sergej
>
>
> _______________________________________________
> 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

Anthony Ramine-4
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.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
123