Discussion:
Erlang VM in Rust
(too old to reply)
austin aigbe
2017-09-12 20:10:24 UTC
Permalink
Hello,

Any consideration for implementing the Erlang VM in Rust?

Regards,
Austin
Dmytro Lytovchenko
2017-09-12 20:25:48 UTC
Permalink
I tried to begin once.

Here's the catch:

- Rust had no unions at the time of my experiments (added in 1.19 - July
2017)
- Rust has no bit fields (some libraries exist trying to alleviate this)
- Erlang process heap is created and maintained by abusing pointers and
bits in them. Casting integers to pointers and back i believe is possible
but will give you some pain.
- A really fast VM loop is done using C/C++ goto (void*) extension, in
Rust you will probably have to use old good switch/case (slower)

When you overcome these base problems, it should be possible to proceed
carefully :)

2017-09-12 22:10 GMT+02:00 austin aigbe <***@gmail.com>:

> Hello,
>
> Any consideration for implementing the Erlang VM in Rust?
>
> Regards,
> Austin
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
Thom Cherryhomes
2017-09-13 01:47:08 UTC
Permalink
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?

sigh.
-Thom

On Tue, Sep 12, 2017 at 3:25 PM Dmytro Lytovchenko <
***@gmail.com> wrote:

> I tried to begin once.
>
> Here's the catch:
>
> - Rust had no unions at the time of my experiments (added in 1.19 -
> July 2017)
> - Rust has no bit fields (some libraries exist trying to alleviate
> this)
> - Erlang process heap is created and maintained by abusing pointers
> and bits in them. Casting integers to pointers and back i believe is
> possible but will give you some pain.
> - A really fast VM loop is done using C/C++ goto (void*) extension, in
> Rust you will probably have to use old good switch/case (slower)
>
> When you overcome these base problems, it should be possible to proceed
> carefully :)
>
> 2017-09-12 22:10 GMT+02:00 austin aigbe <***@gmail.com>:
>
>> Hello,
>>
>> Any consideration for implementing the Erlang VM in Rust?
>>
>> Regards,
>> Austin
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
zxq9
2017-09-13 02:26:46 UTC
Permalink
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
Daniel Goertzen
2017-09-13 19:46:08 UTC
Permalink
- 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 <***@zxq9.com> 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
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
Richard A. O'Keefe
2017-09-13 22:01:48 UTC
Permalink
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.
Joshua Barney
2017-09-13 02:57:18 UTC
Permalink
Rust supports inline assembly https://doc.rust-lang.org/1.8.0/book/inline-assembly.html

Sent from my iPhone

> On Sep 12, 2017, at 9:47 PM, Thom Cherryhomes <***@gmail.com> 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?
>
> sigh.
> -Thom
>
>> On Tue, Sep 12, 2017 at 3:25 PM Dmytro Lytovchenko <***@gmail.com> wrote:
>> I tried to begin once.
>>
>> Here's the catch:
>> Rust had no unions at the time of my experiments (added in 1.19 - July 2017)
>> Rust has no bit fields (some libraries exist trying to alleviate this)
>> Erlang process heap is created and maintained by abusing pointers and bits in them. Casting integers to pointers and back i believe is possible but will give you some pain.
>> A really fast VM loop is done using C/C++ goto (void*) extension, in Rust you will probably have to use old good switch/case (slower)
>> When you overcome these base problems, it should be possible to proceed carefully :)
>>
>> 2017-09-12 22:10 GMT+02:00 austin aigbe <***@gmail.com>:
>>> Hello,
>>>
>>> Any consideration for implementing the Erlang VM in Rust?
>>>
>>> Regards,
>>> Austin
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-***@erlang.org
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
Max Lapshin
2017-09-14 11:10:34 UTC
Permalink
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.
Sergej Jurečko
2017-09-15 16:05:45 UTC
Permalink
> On 14 Sep 2017, at 13:10, Max Lapshin <***@gmail.com> 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
Anthony Ramine
2017-09-14 11:11:12 UTC
Permalink
> Le 13 sept. 2017 à 03:47, Thom Cherryhomes <***@gmail.com> 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.
Loïc Hoguin
2017-09-12 22:27:00 UTC
Permalink
Any thoughts on the benefits existing Erlang programs would get from a
VM implemented in Rust?

It may or may not simplify working on the VM and may or may not make it
more solid. But what would it improve for the programs written in Erlang
themselves?

Cheers,

On 09/12/2017 10:10 PM, austin aigbe wrote:
> Hello,
>
> Any consideration for implementing the Erlang VM in Rust?
>
> Regards,
> Austin
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
zxq9
2017-09-12 22:41:43 UTC
Permalink
On 2017年09月13日 水曜日 00:27:00 Loïc Hoguin wrote:
> Any thoughts on the benefits existing Erlang programs would get from a
> VM implemented in Rust?
>
> It may or may not simplify working on the VM and may or may not make it
> more solid. But what would it improve for the programs written in Erlang
> themselves?

In an ideal world, nothing. I would hope that the only benefit to
those coding in Erlang is that maintenance would become more of a sure
thing for the OTP maintainers and that, in particular, new feature
implementation and performance improvements would become more obvious
and safer to implement over time. Those benefits would be beneficial
only indirectly.

That said... I really can't imagine such a large, old, well documented,
well explored runtime known to such a large team would be rewritten to
a new language. I can imagine that some of us (probably including some
of the OTP team itself) would enjoy working on a rewrite in Rust that
is an alternative to, but not a replacement for, the current runtime.

Competing runtimes occasionally expose hidden benefits. But a blanket
replacement would be a massive, end-of-Netscape type upheaval. It is
not as though Erlang is implemented in an obfuscated style of C++ that
suffers from fundamental structure and human incompatability issues.

-Craig
Paul Oliver
2017-09-12 22:48:08 UTC
Permalink
On Wed, Sep 13, 2017 at 10:42 AM zxq9 <***@zxq9.com> wrote:

> On 2017幎09月13日 氎曜日 00:27:00 Loïc Hoguin wrote:
> > Any thoughts on the benefits existing Erlang programs would get from a
> > VM implemented in Rust?
> >
> > It may or may not simplify working on the VM and may or may not make it
> > more solid. But what would it improve for the programs written in Erlang
> > themselves?
>
> In an ideal world, nothing. I would hope that the only benefit to
> those coding in Erlang is that maintenance would become more of a sure
> thing for the OTP maintainers and that, in particular, new feature
> implementation and performance improvements would become more obvious
> and safer to implement over time. Those benefits would be beneficial
> only indirectly.
>
> That said... I really can't imagine such a large, old, well documented,
> well explored runtime known to such a large team would be rewritten to
> a new language. I can imagine that some of us (probably including some
> of the OTP team itself) would enjoy working on a rewrite in Rust that
> is an alternative to, but not a replacement for, the current runtime.
>
> Competing runtimes occasionally expose hidden benefits. But a blanket
> replacement would be a massive, end-of-Netscape type upheaval. It is
> not as though Erlang is implemented in an obfuscated style of C++ that
> suffers from fundamental structure and human incompatability issues.
>
>
Large C projects can potentially be rewritten in Rust gradually. An example
of this can be found in Remacs (
http://www.wilfred.me.uk/blog/2017/01/11/announcing-remacs-porting-emacs-to-rust/
).
Richard A. O'Keefe
2017-09-13 01:28:18 UTC
Permalink
As I see it, the main problem rewriting (or better still, rebuilding)
Erlang in Rust is that I'd rather see that human time spent on
improving the system we already have.

As an open source project, Erlang is or was eligible for free
checking by Coverity. I see on the Coverity web site that the
last check was in August 2015, a little over 2 years ago. Is
there a plan to have it checked again?
Heinz N. Gies
2017-09-13 15:11:12 UTC
Permalink
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.
Anthony Ramine
2017-09-13 22:25:01 UTC
Permalink
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 <***@licenser.net> 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.
Heinz N. Gies
2017-09-14 21:49:43 UTC
Permalink
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 <***@gmail.com> 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 <***@licenser.net> 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.
>
Benoit Chesneau
2017-09-15 15:28:16 UTC
Permalink
While we are on it , does rust run on solaris?

- benoit
> On 14 Sep 2017, at 23:49, Heinz N. Gies <***@licenser.net> 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 <***@gmail.com> 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 <***@licenser.net> 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
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
Heinz N. Gies
2017-09-15 17:47:29 UTC
Permalink
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 <***@gmail.com> wrote:
>
> While we are on it , does rust run on solaris?
>
> - benoit
>> On 14 Sep 2017, at 23:49, Heinz N. Gies <***@licenser.net> 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 <***@gmail.com> 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 <***@licenser.net> 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
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>
Sergej Jurečko
2017-09-15 18:01:28 UTC
Permalink
> On 15 Sep 2017, at 19:47, Heinz N. Gies <***@licenser.net> 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
Heinz N. Gies
2017-09-15 19:20:28 UTC
Permalink
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 <***@gmail.com> wrote:
>
>
>> On 15 Sep 2017, at 19:47, Heinz N. Gies <***@licenser.net> 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
Joe Armstrong
2017-09-16 10:03:40 UTC
Permalink
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 <***@licenser.net> 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 <***@gmail.com> wrote:
>>
>>
>>> On 15 Sep 2017, at 19:47, Heinz N. Gies <***@licenser.net> 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
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
Anthony Ramine
2017-09-16 11:18:42 UTC
Permalink
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 <***@gmail.com> 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.
Anderson Torres
2017-09-16 12:42:41 UTC
Permalink
2017-09-16 8:18 GMT-03:00 Anthony Ramine <***@gmail.com>:
> 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 <***@gmail.com> 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
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
Joshua Barney
2017-09-12 22:48:49 UTC
Permalink
I think the real point of implementing the Erlang VM in Rust is to increase the awesomeness 100 fold

But really, the only thing I can think of that affects erlang programs is that it could make is simpler to write nifs that can't crash your whole vm. I don't know how, however.

I feel like cargo could have a similar community building effect as npm has had for nodejs--an explosion of creativity that resulted in a lot of good quality tools for everyone to use. It's conceivable to me that development of a rust/erl VM could move very quickly by leveraging cargo crates

Sent from my iPhone

> On Sep 12, 2017, at 6:27 PM, Loïc Hoguin <***@ninenines.eu> wrote:
>
> Any thoughts on the benefits existing Erlang programs would get from a VM implemented in Rust?
>
> It may or may not simplify working on the VM and may or may not make it more solid. But what would it improve for the programs written in Erlang themselves?
>
> Cheers,
>
>> On 09/12/2017 10:10 PM, austin aigbe wrote:
>> Hello,
>> Any consideration for implementing the Erlang VM in Rust?
>> Regards,
>> Austin
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> --
> Loïc Hoguin
> https://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
scott ribe
2017-09-12 22:50:48 UTC
Permalink
> On Sep 12, 2017, at 4:48 PM, Joshua Barney <***@icloud.com> wrote:
>
> But really, the only thing I can think of that affects erlang programs is that it could make is simpler to write nifs that can't crash your whole vm. I don't know how, however.
>

There's already a Rust library to support exactly that.

--
Scott Ribe
***@elevated-dev.com
(303) 722-0567
Tristan Sloughter
2017-09-13 00:05:33 UTC
Permalink
Maybe Tony 'the tiger' Ramine would come back to working on Erlang if it
was in Rust!

--
Tristan Sloughter
"I am not a crackpot" - Abe Simpson
***@crashfast.com
zxq9
2017-09-13 01:30:28 UTC
Permalink
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
Anthony Ramine
2017-09-13 12:10:30 UTC
Permalink
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 <***@zxq9.com> 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
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
David Goehrig
2017-09-13 01:08:05 UTC
Permalink
Based on past experience, every rewrite in solution/language du jour merely
fragments the community and introduces new classes of incompatible bugs.
The broad cost in social capital outweighs any narrow technical benefits.

I have seen it in my own projects. Even projects like Python, Ruby, and
Perl are suffering the social costs of rewrites.

We should remember language is a tool for communication between humans, and
they are not as easy to program :)

Dave

On Sep 12, 2017 6:27 PM, "Loïc Hoguin" <***@ninenines.eu> wrote:

> Any thoughts on the benefits existing Erlang programs would get from a VM
> implemented in Rust?
>
> It may or may not simplify working on the VM and may or may not make it
> more solid. But what would it improve for the programs written in Erlang
> themselves?
>
> Cheers,
>
> On 09/12/2017 10:10 PM, austin aigbe wrote:
>
>> Hello,
>>
>> Any consideration for implementing the Erlang VM in Rust?
>>
>> Regards,
>> Austin
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
> --
> Loïc Hoguin
> https://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
Jesper Louis Andersen
2017-09-13 11:11:36 UTC
Permalink
On Tue, Sep 12, 2017 at 10:10 PM austin aigbe <***@gmail.com> wrote:

> Hello,
>
> Any consideration for implementing the Erlang VM in Rust?
>
>
I think the problem is roughly the same as with any other language: A lot
of good effort has been sunk into the current VM in C and this makes a
switch harder. Rust has ABI compatibility with C in some ways, which makes
interoperability simpler, so one could imagine taking some of the more
security-oriented parts of the VM and rewriting those in Rust or some other
language of the more restrictive kind.

If you want to rewrite all of it, a good approach is to start by making
changes to the current VM which makes it smaller:

* Move more work out into NIFs. Reimplement those in Rust
* Coalesce more work on Dirty Schedulers
* Implement Native Processes, so you can start running Rust-native-processes
* Write an AOT or JIT compiler pass. Move ETS into pure Erlang. Move a lot
of the BIF optimized functions into pure Erlang.

A smaller core is way easier to replace.

Personally, I'd just throw some more time after concurrent OCaml, and then
write a translator from Erlang to OCaml :P
Roman Galeev
2017-09-13 11:20:05 UTC
Permalink
> 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?

On Wed, Sep 13, 2017 at 1:11 PM, Jesper Louis Andersen <
***@gmail.com> wrote:

> On Tue, Sep 12, 2017 at 10:10 PM austin aigbe <***@gmail.com> wrote:
>
>> Hello,
>>
>> Any consideration for implementing the Erlang VM in Rust?
>>
>>
> I think the problem is roughly the same as with any other language: A lot
> of good effort has been sunk into the current VM in C and this makes a
> switch harder. Rust has ABI compatibility with C in some ways, which makes
> interoperability simpler, so one could imagine taking some of the more
> security-oriented parts of the VM and rewriting those in Rust or some other
> language of the more restrictive kind.
>
> If you want to rewrite all of it, a good approach is to start by making
> changes to the current VM which makes it smaller:
>
> * Move more work out into NIFs. Reimplement those in Rust
> * Coalesce more work on Dirty Schedulers
> * Implement Native Processes, so you can start running
> Rust-native-processes
> * Write an AOT or JIT compiler pass. Move ETS into pure Erlang. Move a lot
> of the BIF optimized functions into pure Erlang.
>
> A smaller core is way easier to replace.
>
> Personally, I'd just throw some more time after concurrent OCaml, and then
> write a translator from Erlang to OCaml :P
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


--
With best regards,
Roman Galeev,
+420 702 817 968
Jesper Louis Andersen
2017-09-13 11:43:16 UTC
Permalink
On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <***@gmail.com> 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.
Roman Galeev
2017-09-13 12:24:48 UTC
Permalink
> 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 <
***@gmail.com> wrote:

> On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <***@gmail.com> 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
Richard A. O'Keefe
2017-09-13 21:37:55 UTC
Permalink
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.
Jesper Louis Andersen
2017-09-19 11:41:19 UTC
Permalink
On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <***@cs.otago.ac.nz>
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
Karl Nilsson
2017-09-19 13:57:08 UTC
Permalink
This post might be inappropriate. Click to display it.
Richard Carlsson
2017-09-19 14:32:06 UTC
Permalink
2017-09-19 15:57 GMT+02:00 Karl Nilsson <***@gmail.com>:
>
> 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
Daniel Goertzen
2017-09-19 14:57:40 UTC
Permalink
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 <***@gmail.com> wrote:

> On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <
> ***@gmail.com> wrote:
>
>> On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <***@cs.otago.ac.nz>
>> 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
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
Zachary Kessin
2017-09-20 07:55:32 UTC
Permalink
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 <***@gmail.com>
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 <***@gmail.com> wrote:
>
>> On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <
>> ***@gmail.com> wrote:
>>
>>> On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <***@cs.otago.ac.nz>
>>> 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
>>> erlang-***@erlang.org
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> 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
Jeremy Pierre
2017-09-20 15:31:22 UTC
Permalink
Begging the list's indulgence with tangential and possibly off-topic
content.

On Tue, Sep 19, 2017 at 7:57 AM Daniel Goertzen <***@gmail.com>
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 <***@gmail.com> wrote:
>
>> On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <
>> ***@gmail.com> wrote:
>>
>>> On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <***@cs.otago.ac.nz>
>>> 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
>>> erlang-***@erlang.org
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
James Churchman
2017-09-21 16:15:22 UTC
Permalink
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 <***@gmail.com> wrote:

> Begging the list's indulgence with tangential and possibly off-topic
> content.
>
> On Tue, Sep 19, 2017 at 7:57 AM Daniel Goertzen <***@gmail.com>
> 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 <***@gmail.com> wrote:
>>
>>> On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <
>>> ***@gmail.com> wrote:
>>>
>>>> On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <***@cs.otago.ac.nz>
>>>> 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
>>>> erlang-***@erlang.org
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-***@erlang.org
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
zxq9
2017-09-21 16:25:42 UTC
Permalink
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
Felix Gallo
2017-09-21 16:42:06 UTC
Permalink
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 <***@gmail.com>
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 <***@gmail.com> wrote:
>
>> Begging the list's indulgence with tangential and possibly off-topic
>> content.
>>
>> On Tue, Sep 19, 2017 at 7:57 AM Daniel Goertzen <
>> ***@gmail.com> 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 <***@gmail.com>
>>> wrote:
>>>
>>>> On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <
>>>> ***@gmail.com> wrote:
>>>>
>>>>> On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <***@cs.otago.ac.nz>
>>>>> 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
>>>>> erlang-***@erlang.org
>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-***@erlang.org
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-***@erlang.org
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
Loïc Hoguin
2017-09-21 16:45:01 UTC
Permalink
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
Frank Muller
2017-09-21 17:12:14 UTC
Permalink
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
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
Felix Gallo
2017-09-21 18:26:32 UTC
Permalink
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 <***@gmail.com>
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
>> erlang-***@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
James Churchman
2017-09-21 19:42:11 UTC
Permalink
On 21 September 2017 at 19:26, Felix Gallo <***@gmail.com> 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 <***@gmail.com>
> 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!
Joe Armstrong
2017-09-21 20:37:17 UTC
Permalink
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
<***@gmail.com> wrote:
>
>
> On 21 September 2017 at 19:26, Felix Gallo <***@gmail.com> 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 <***@gmail.com>
>> 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
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
James Churchman
2017-09-21 20:48:37 UTC
Permalink
On 21 September 2017 at 21:37, Joe Armstrong <***@gmail.com> 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
> <***@gmail.com> wrote:
> >
> >
> > On 21 September 2017 at 19:26, Felix Gallo <***@gmail.com> 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 <***@gmail.com
> >
> >> 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
> > erlang-***@erlang.org
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
>
Joe Armstrong
2017-09-21 20:56:43 UTC
Permalink
On Thu, Sep 21, 2017 at 10:48 PM, James Churchman
<***@gmail.com> wrote:
>
>
> On 21 September 2017 at 21:37, Joe Armstrong <***@gmail.com> 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
>> <***@gmail.com> wrote:
>> >
>> >
>> > On 21 September 2017 at 19:26, Felix Gallo <***@gmail.com> 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
>> >> <***@gmail.com>
>> >> 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
>> > erlang-***@erlang.org
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> >
>
>
Anthony Ramine
2017-09-22 12:39:17 UTC
Permalink
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 <***@gmail.com> 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.
zxq9
2017-09-22 13:21:53 UTC
Permalink
On 2017年09月22日 金曜日 14:39:17 Anthony Ramine wrote:
> That's a security disaster waiting to happen.

Oh, its not waiting for anything or anyone...

/(O.o)\

-Craig
Joe Armstrong
2017-09-22 14:33:47 UTC
Permalink
You're quite right C is memory unsafe, and the large quantity of C code
in IoT devices is as you rightly say a disaster - only it has already happened
no waiting is involved.

I would like to *reduce* the amount of C - write an emulator for language X
in C, then write everything in X. X would be a "better" language than C
in some sense. X should compile to a small instruction set such that
the implementation of the VM would be a simple and hopefully correct program.

if we go back to the P-code machine the design was very simple and the
implementation a few hundred lines of pascal (or C) - I'm pretty sure
one could write a memory safe P-code interpreter in a memory-unsafe
language like C.

Security (since you mentioned it) ultimately relies on trust. Do you trust the
compiler? do you trust the programmers? Do you trust the hardware?

If I were building a secure system I would try to trust as little as possible
putting firewalls and checks between components.

Given a pure choice between a language that offered memory safety
and one that did not I'd obviously choose the memory-safe language
all other things being equal.

Trouble is all other things are not equal.

For me:

Time to solve problem =
Time to understand problem (T1) +
Time to learn language X (T2) +
Time to write program in X (T3)

If I choose C then T2 is very small. Usually T1 >> T3.

The "elephant in the room" is the time to be productive and know the
idioms of programming in X. T3 is small when you are proficient
in the language otherwise large.

I have said before - I think it takes about 3 weeks to learn a language
6-24 months to know your way around the libraries and 10+ years to know
how to solve a problem in your favorite language.

I dabble with new languages, not to become productive in them,
but to see what new ideas they embody.

Niklas Wirth said many years ago that it was far better to be very good at one
language than having superficial knowledge of many.

Cheers

/Joe



On Fri, Sep 22, 2017 at 2:39 PM, Anthony Ramine <***@gmail.com> wrote:
> 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 <***@gmail.com> 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.
>
Peer Stritzinger
2017-09-22 16:37:33 UTC
Permalink
If you are not aiming at super small hardware but lets say in the 100-300 MHz 32bit controller range there is
another way to protect agains C problems at least in the application domain:

Running Erlang directly on the hardware as we do frees the Translation Lookaside Buffers that are used for
virtual memory. These small chips have some which allows very inefficiently to run Unix alike systems.

If we use those VM features to jail in the C code in a NIF it can’t escape its little box.

Therefore we can use Erlang and safe C NIFs on these embedded systems without the overhead
of Unix alike OS, full virtual memory and OS processes.

That eliminates trusting the application level C code. Unikernel and Erlang VM remain though.

Best,
-- Peer

> On 22.09.2017, at 16:33, Joe Armstrong <***@gmail.com> wrote:
>
> You're quite right C is memory unsafe, and the large quantity of C code
> in IoT devices is as you rightly say a disaster - only it has already happened
> no waiting is involved.
>
> I would like to *reduce* the amount of C - write an emulator for language X
> in C, then write everything in X. X would be a "better" language than C
> in some sense. X should compile to a small instruction set such that
> the implementation of the VM would be a simple and hopefully correct program.
>
> if we go back to the P-code machine the design was very simple and the
> implementation a few hundred lines of pascal (or C) - I'm pretty sure
> one could write a memory safe P-code interpreter in a memory-unsafe
> language like C.
>
> Security (since you mentioned it) ultimately relies on trust. Do you trust the
> compiler? do you trust the programmers? Do you trust the hardware?
>
> If I were building a secure system I would try to trust as little as possible
> putting firewalls and checks between components.
>
> Given a pure choice between a language that offered memory safety
> and one that did not I'd obviously choose the memory-safe language
> all other things being equal.
>
> Trouble is all other things are not equal.
>
> For me:
>
> Time to solve problem =
> Time to understand problem (T1) +
> Time to learn language X (T2) +
> Time to write program in X (T3)
>
> If I choose C then T2 is very small. Usually T1 >> T3.
>
> The "elephant in the room" is the time to be productive and know the
> idioms of programming in X. T3 is small when you are proficient
> in the language otherwise large.
>
> I have said before - I think it takes about 3 weeks to learn a language
> 6-24 months to know your way around the libraries and 10+ years to know
> how to solve a problem in your favorite language.
>
> I dabble with new languages, not to become productive in them,
> but to see what new ideas they embody.
>
> Niklas Wirth said many years ago that it was far better to be very good at one
> language than having superficial knowledge of many.
>
> Cheers
>
> /Joe
>
>
>
> On Fri, Sep 22, 2017 at 2:39 PM, Anthony Ramine <***@gmail.com> wrote:
>> 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 <***@gmail.com> 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
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
Max Lapshin
2017-09-22 16:40:29 UTC
Permalink
This is a nice discussion and it is hard to track all messages here.

I just want to insert that rust is in a beginning of its way. There are
lots of places that can degrade performance very seriously and are far for
C level. So keep it calm =)

However it is possible to make parts of system in it and it is good.
Technion
2017-09-27 07:00:58 UTC
Permalink
Hi,


A thing to think about is third party non-Erlang.


For example, an awful lot of Erlang projects utilise a C based JSON parser. I don't think anyone does that because they prefer C - it happens because the existing pure Erlang JSON parsers work well and are safer - but hit performance issues at a certain scale.


I'm sure there are similar examples such as database drivers you could refer to. You could remove a lot of C from the average Erlang project by tackling the things that aren't parts of the usual distribution, whether that's "write it in Rust" or, more controversially, "make Erlang fast enough that pure Erlang JSON is acceptable".


________________________________
From: erlang-questions-***@erlang.org <erlang-questions-***@erlang.org> on behalf of Max Lapshin <***@gmail.com>
Sent: Saturday, 23 September 2017 2:40 AM
To: Peer Stritzinger
Cc: erlang-questions Questions
Subject: Re: [erlang-questions] Erlang VM in Rust

This is a nice discussion and it is hard to track all messages here.

I just want to insert that rust is in a beginning of its way. There are lots of places that can degrade performance very seriously and are far for C level. So keep it calm =)

However it is possible to make parts of system in it and it is good.
o***@cs.otago.ac.nz
2017-09-23 07:09:19 UTC
Permalink
> 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.

These days I am getting a little confused about what "IoT" actually
means. I thought it was lots of small devices, but the last couple
of talks I've view seem to take it as synonymous with the cloud.
Let's go with the first definition: talking teddy bears, internet-
connected lightbulbs, sensors using MPS430 CPUs and the like.

All the "IoT" operating systems I know of are written in C
(like Zephyr and RIOT) or C++ (like mbed OS). Putting C in
IoT stuff is not a new suggestion. (Nor is the claim that
it's the internet of insecure things new (:-).)

Joe was explicitly talking about much as much as practically
possible to Erlang, reducing the amount of C to perhaps just
the emulator. C was originally designed for small systems
(MPS430 size, in fact) where it was possible for one person
to read all the code carefully in a reasonable time.

I note that there are a number of tools to dramatically
improve the reliability of C programs. For just one
example, there is the "Memory-Safe C compiler".
http://www.seclab.cs.sunysb.edu/mscc/
(It's remarkable how many let's-make-C-better tools have
been developed in CAML.)

There's even a memory safety checker nesCheck for the
nesC C-like language used with TinyOS.
https://nebelwelt.net/publications/files/17AsiaCCS2.pdf

I could sit here all night citing papers about static
and dynamic checkers and verifiers for C. "In C" and
"in a memory-safe language" do NOT have to be exclusive
alternatives.
Oliver Korpilla
2017-09-23 07:28:37 UTC
Permalink
Hello.

>These days I am getting a little confused about what "IoT" actually
>means. I thought it was lots of small devices, but the last couple
>of talks I've view seem to take it as synonymous with the cloud.
>Let's go with the first definition: talking teddy bears, internet-
>connected lightbulbs, sensors using MPS430 CPUs and the like.

I think what makes it an "Internet of Things" is really the cloud aspect, not the micro-controller aspect. So, the foremost concern would be to allow these devices to interact with each other locally in a safe and defined way and to let them occasionally connect to the cloud as needed.

So, it's not basically about the first definition. We already had that. It's like saying "Let's not have an internet of things."

Having said that I see no immense security risk in writing code for a remote sensor in C. It avoids one of the prime security risks: human user interactions and all the buffer overrun problems and string processing stuff that is so hard to do safely that there are still books being written about.

The question is when an individual device gets complex enough to warrant using proper abstractions - like using Erlang. That might not be a good business case for the smallest micro-controllers, but any device actually having to manage a more serious kind of network interaction might hugely benefit. The more the device is intended to do outside the cloud - or the more complex its interaction with other devices or the cloud becomes - the more readily I would say moving away from C would yield benefits.

Of course that is a huge sidetrack from the discussion if the Erlang VM could benefit from a Rust rewrite. ;-) I mean, are we really arguing here that C is a good answer to the problem of writing networked software? Really??

Tongue in cheek implied.

Cheers,
Oliver
Anthony Ramine
2017-09-23 08:29:15 UTC
Permalink
Just forge input to the sensor in such a way it triggers a buffer overflow or something else in it.

Nowadays we can even forge DNA strands to confuse DNA readers so…

https://twitter.com/bldgblog/status/895728956724322304

> Le 23 sept. 2017 à 09:28, Oliver Korpilla <***@gmx.de> a écrit :
>
> Having said that I see no immense security risk in writing code for a remote sensor in C. It avoids one of the prime security risks: human user interactions
Oliver Korpilla
2017-09-23 09:23:40 UTC
Permalink
_______________________________________________
erlang-questions mailing list
erlang-***@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Attila Rajmund Nohl
2017-09-25 09:41:52 UTC
Permalink
2017-09-23 9:28 GMT+02:00 Oliver Korpilla <***@gmx.de>:
[...]
> Having said that I see no immense security risk in writing code for a remote sensor in C. It avoids one of the prime security risks: human user interactions and all the buffer overrun problems and string processing stuff that is so hard to do safely that there are still books being written about.

If it is connected to the internet (the first letter in IoT), then it
at least needs to handle IPv4 - and it involves parsing of potentially
untrusted data.
Richard A. O'Keefe
2017-09-25 21:15:52 UTC
Permalink
On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:
> 2017-09-23 9:28 GMT+02:00 Oliver Korpilla <***@gmx.de>:
> [...]
>> Having said that I see no immense security risk in writing code for a remote sensor in C. It avoids one of the prime security risks: human user interactions and all the buffer overrun problems and string processing stuff that is so hard to do safely that there are still books being written about.
>
> If it is connected to the internet (the first letter in IoT), then it
> at least needs to handle IPv4 - and it involves parsing of potentially
> untrusted data.

The remote sensors I am interested in are *not* connected to the
internet. They are connected via radio to each other and to base
stations, and the base stations may then be connected to the
internet (probably using an OS and IP stack written in C).

There is a serious point here that *end* devices are likely to be
as small as you can get away with. Instead of spending money on
bigger/faster machines, it's rather more useful to have *more*
machines that are just capable enough to do the job.

Other people may be interested in other things.
Karlo Kuna
2017-09-25 21:38:59 UTC
Permalink
Just to add a voice in this discussion ,
i would love to see c++ implementation of erlang, and it soul be possible
due power of templates get much more
safe and easily extendible code base IMHO. It would require lot of
expertise and _discipline_ but i cold be fun project

also I wold love to have erlang implementation for IoT, as erlang seems to
be great fit for that
for this one i am with Joe, we need something small portable (and written
in c++ of course)


On Mon, Sep 25, 2017 at 11:15 PM, Richard A. O'Keefe <***@cs.otago.ac.nz>
wrote:

>
>
> On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:
>
>> 2017-09-23 9:28 GMT+02:00 Oliver Korpilla <***@gmx.de>:
>> [...]
>>
>>> Having said that I see no immense security risk in writing code for a
>>> remote sensor in C. It avoids one of the prime security risks: human user
>>> interactions and all the buffer overrun problems and string processing
>>> stuff that is so hard to do safely that there are still books being written
>>> about.
>>>
>>
>> If it is connected to the internet (the first letter in IoT), then it
>> at least needs to handle IPv4 - and it involves parsing of potentially
>> untrusted data.
>>
>
> The remote sensors I am interested in are *not* connected to the
> internet. They are connected via radio to each other and to base
> stations, and the base stations may then be connected to the
> internet (probably using an OS and IP stack written in C).
>
> There is a serious point here that *end* devices are likely to be
> as small as you can get away with. Instead of spending money on
> bigger/faster machines, it's rather more useful to have *more*
> machines that are just capable enough to do the job.
>
> Other people may be interested in other things.
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
Oliver Korpilla
2017-09-25 21:53:00 UTC
Permalink
Hi.

This is, of course, something that can easily devolve into a holy war where everyone clamors for their favorite programming language.

But cannot resist... XD

I never felt empowered by C++ templates. I find that code written heavily depending on templates to drastically decrease in readability (and hence maintainability) while the compile times of C++ are just plain horrible (btw a side effect of how templates were put into the language in the first place). It has been a major pain at my workplace when it comes to running continuous integration.

I learned about a dozen languages well enough to do projects in them, and C++ will always be the ugly one that I want to get away from but which is without alternative in the minds of project managers.

*ducks*

Oliver


 
 

Gesendet: Montag, 25. September 2017 um 23:38 Uhr
Von: "Karlo Kuna" <***@gmail.com>
An: "Erlang-Questions Questions" <erlang-***@erlang.org>
Betreff: Re: [erlang-questions] Erlang VM in Rust

Just to add a voice in this discussion ,
i would love to see c++ implementation of erlang, and it soul be possible due power of templates get much more 
safe and easily extendible code base IMHO. It would require lot of expertise and _discipline_  but i cold be fun project
 
also I wold love to have erlang implementation for IoT, as erlang seems to be great fit for that
for this one i am with Joe, we need something small portable (and written in c++ of course) 
 
 
On Mon, Sep 25, 2017 at 11:15 PM, Richard A. O'Keefe <***@cs.otago.ac.nz[mailto:***@cs.otago.ac.nz]> wrote:

On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:2017-09-23 9:28 GMT+02:00 Oliver Korpilla <***@gmx.de[mailto:***@gmx.de]>:
[...]Having said that I see no immense security risk in writing code for a remote sensor in C. It avoids one of the prime security risks: human user interactions and all the buffer overrun problems and string processing stuff that is so hard to do safely that there are still books being written about.
If it is connected to the internet (the first letter in IoT), then it
at least needs to handle IPv4 - and it involves parsing of potentially
untrusted data.
The remote sensors I am interested in are *not* connected to the
internet.  They are connected via radio to each other and to base
stations, and the base stations may then be connected to the
internet (probably using an OS and IP stack written in C).

There is a serious point here that *end* devices are likely to be
as small as you can get away with.  Instead of spending money on
bigger/faster machines, it's rather more useful to have *more*
machines that are just capable enough to do the job.

Other people may be interested in other things.

_______________________________________________
erlang-questions mailing list
erlang-***@erlang.org[mailto:erlang-***@erlang.org]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list erlang-***@erlang.org http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
Karlo Kuna
2017-09-25 22:22:59 UTC
Permalink
sure thing, it is matter of taste and experience and whole lot of factors
i agree that compile times are abysmal (that's due C legacy which was major
goal for C++ and of course hardware limitations back in 80's)

but for me quality of interfaces that you can achieve is stunning (again my
view)

to add criticism, macros should be banished, and OOP is overused in C++,
implicit conversions are not nice, visitor pattern is problem, etc.
discipline is the thing in c++

but as it has memory model defined, lifetime management and things like
that i think it would be good fit for implementing erlang for IoT



On Mon, Sep 25, 2017 at 11:53 PM, Oliver Korpilla <***@gmx.de>
wrote:

> Hi.
>
> This is, of course, something that can easily devolve into a holy war
> where everyone clamors for their favorite programming language.
>
> But cannot resist... XD
>
> I never felt empowered by C++ templates. I find that code written heavily
> depending on templates to drastically decrease in readability (and hence
> maintainability) while the compile times of C++ are just plain horrible
> (btw a side effect of how templates were put into the language in the first
> place). It has been a major pain at my workplace when it comes to running
> continuous integration.
>
> I learned about a dozen languages well enough to do projects in them, and
> C++ will always be the ugly one that I want to get away from but which is
> without alternative in the minds of project managers.
>
> *ducks*
>
> Oliver
>
>
>
>
>
> Gesendet: Montag, 25. September 2017 um 23:38 Uhr
> Von: "Karlo Kuna" <***@gmail.com>
> An: "Erlang-Questions Questions" <erlang-***@erlang.org>
> Betreff: Re: [erlang-questions] Erlang VM in Rust
>
> Just to add a voice in this discussion ,
> i would love to see c++ implementation of erlang, and it soul be possible
> due power of templates get much more
> safe and easily extendible code base IMHO. It would require lot of
> expertise and _discipline_ but i cold be fun project
>
> also I wold love to have erlang implementation for IoT, as erlang seems to
> be great fit for that
> for this one i am with Joe, we need something small portable (and written
> in c++ of course)
>
>
> On Mon, Sep 25, 2017 at 11:15 PM, Richard A. O'Keefe <***@cs.otago.ac.nz
> [mailto:***@cs.otago.ac.nz]> wrote:
>
> On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:2017-09-23 9:28 GMT+02:00
> Oliver Korpilla <***@gmx.de[mailto:***@gmx.de]>:
> [...]Having said that I see no immense security risk in writing code for a
> remote sensor in C. It avoids one of the prime security risks: human user
> interactions and all the buffer overrun problems and string processing
> stuff that is so hard to do safely that there are still books being written
> about.
> If it is connected to the internet (the first letter in IoT), then it
> at least needs to handle IPv4 - and it involves parsing of potentially
> untrusted data.
> The remote sensors I am interested in are *not* connected to the
> internet. They are connected via radio to each other and to base
> stations, and the base stations may then be connected to the
> internet (probably using an OS and IP stack written in C).
>
> There is a serious point here that *end* devices are likely to be
> as small as you can get away with. Instead of spending money on
> bigger/faster machines, it's rather more useful to have *more*
> machines that are just capable enough to do the job.
>
> Other people may be interested in other things.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org[mailto:erlang-***@erlang.org]
> http://erlang.org/mailman/listinfo/erlang-questions_____
> __________________________________________ erlang-questions mailing list
> erlang-***@erlang.org http://erlang.org/mailman/
> listinfo/erlang-questions[http://erlang.org/mailman/
> listinfo/erlang-questions]
>
Grzegorz Junka
2017-09-25 22:27:11 UTC
Permalink
Is it only me who thinks that implementing an actor-oriented functional
language in an object-oriented C++ is kind of weird?

GrzegorzJ


On 25/09/2017 22:22, Karlo Kuna wrote:
> sure thing, it is matter of taste and experience and whole lot of factors
> i agree that compile times are abysmal (that's due C legacy which was
> major goal for C++ and of course hardware limitations back in 80's)
>
> but for me quality of interfaces that you can achieve is stunning
> (again my view)
>
> to add criticism, macros should be banished, and OOP is overused in
> C++, implicit conversions are not nice, visitor pattern is problem, etc.
> discipline is the thing in c++
>
> but as it has memory model defined, lifetime management and things
> like that i think it would be good fit for implementing erlang for IoT
>
>
>
> On Mon, Sep 25, 2017 at 11:53 PM, Oliver Korpilla
> <***@gmx.de <mailto:***@gmx.de>> wrote:
>
> Hi.
>
> This is, of course, something that can easily devolve into a holy
> war where everyone clamors for their favorite programming language.
>
> But cannot resist... XD
>
> I never felt empowered by C++ templates. I find that code written
> heavily depending on templates to drastically decrease in
> readability (and hence maintainability) while the compile times of
> C++ are just plain horrible (btw a side effect of how templates
> were put into the language in the first place). It has been a
> major pain at my workplace when it comes to running continuous
> integration.
>
> I learned about a dozen languages well enough to do projects in
> them, and C++ will always be the ugly one that I want to get away
> from but which is without alternative in the minds of project
> managers.
>
> *ducks*
>
> Oliver
>
>
>
>
>
> Gesendet: Montag, 25. September 2017 um 23:38 Uhr
> Von: "Karlo Kuna" <***@gmail.com <mailto:***@gmail.com>>
> An: "Erlang-Questions Questions" <erlang-***@erlang.org
> <mailto:erlang-***@erlang.org>>
> Betreff: Re: [erlang-questions] Erlang VM in Rust
>
> Just to add a voice in this discussion ,
> i would love to see c++ implementation of erlang, and it soul be
> possible due power of templates get much more
> safe and easily extendible code base IMHO. It would require lot of
> expertise and _discipline_ but i cold be fun project
>
> also I wold love to have erlang implementation for IoT, as erlang
> seems to be great fit for that
> for this one i am with Joe, we need something small portable (and
> written in c++ of course)
>
>
> On Mon, Sep 25, 2017 at 11:15 PM, Richard A. O'Keefe
> <***@cs.otago.ac.nz
> <mailto:***@cs.otago.ac.nz>[mailto:***@cs.otago.ac.nz
> <mailto:***@cs.otago.ac.nz>]> wrote:
>
> On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:2017-09-23 9:28
> GMT+02:00 Oliver Korpilla <***@gmx.de
> <mailto:***@gmx.de>[mailto:***@gmx.de
> <mailto:***@gmx.de>]>:
> [...]Having said that I see no immense security risk in writing
> code for a remote sensor in C. It avoids one of the prime security
> risks: human user interactions and all the buffer overrun problems
> and string processing stuff that is so hard to do safely that
> there are still books being written about.
> If it is connected to the internet (the first letter in IoT), then it
> at least needs to handle IPv4 - and it involves parsing of potentially
> untrusted data.
> The remote sensors I am interested in are *not* connected to the
> internet. They are connected via radio to each other and to base
> stations, and the base stations may then be connected to the
> internet (probably using an OS and IP stack written in C).
>
> There is a serious point here that *end* devices are likely to be
> as small as you can get away with. Instead of spending money on
> bigger/faster machines, it's rather more useful to have *more*
> machines that are just capable enough to do the job.
>
> Other people may be interested in other things.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> <mailto:erlang-***@erlang.org>[mailto:erlang-***@erlang.org
> <mailto:erlang-***@erlang.org>]
> http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________
> <http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________>
> erlang-questions mailing list erlang-***@erlang.org
> <mailto:erlang-***@erlang.org>
> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
> <http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
Karlo Kuna
2017-09-25 22:35:19 UTC
Permalink
maybe, but then again machine architectures are Von Neuman models

so in a way you are forced to work with that and languages that have as a
goal, to be a low as possible when needed seem to be
good choices for implementing many kinds of abstractions including actors

and OOP is a choice in C++, as i have sad before, overused one

On Tue, Sep 26, 2017 at 12:27 AM, Grzegorz Junka <***@gjunka.com> wrote:

> Is it only me who thinks that implementing an actor-oriented functional
> language in an object-oriented C++ is kind of weird?
>
> GrzegorzJ
>
> On 25/09/2017 22:22, Karlo Kuna wrote:
>
> sure thing, it is matter of taste and experience and whole lot of factors
> i agree that compile times are abysmal (that's due C legacy which was
> major goal for C++ and of course hardware limitations back in 80's)
>
> but for me quality of interfaces that you can achieve is stunning (again
> my view)
>
> to add criticism, macros should be banished, and OOP is overused in C++,
> implicit conversions are not nice, visitor pattern is problem, etc.
> discipline is the thing in c++
>
> but as it has memory model defined, lifetime management and things like
> that i think it would be good fit for implementing erlang for IoT
>
>
>
> On Mon, Sep 25, 2017 at 11:53 PM, Oliver Korpilla <***@gmx.de>
> wrote:
>
>> Hi.
>>
>> This is, of course, something that can easily devolve into a holy war
>> where everyone clamors for their favorite programming language.
>>
>> But cannot resist... XD
>>
>> I never felt empowered by C++ templates. I find that code written heavily
>> depending on templates to drastically decrease in readability (and hence
>> maintainability) while the compile times of C++ are just plain horrible
>> (btw a side effect of how templates were put into the language in the first
>> place). It has been a major pain at my workplace when it comes to running
>> continuous integration.
>>
>> I learned about a dozen languages well enough to do projects in them, and
>> C++ will always be the ugly one that I want to get away from but which is
>> without alternative in the minds of project managers.
>>
>> *ducks*
>>
>> Oliver
>>
>>
>>
>>
>>
>> Gesendet: Montag, 25. September 2017 um 23:38 Uhr
>> Von: "Karlo Kuna" <***@gmail.com>
>> An: "Erlang-Questions Questions" <erlang-***@erlang.org>
>> Betreff: Re: [erlang-questions] Erlang VM in Rust
>>
>> Just to add a voice in this discussion ,
>> i would love to see c++ implementation of erlang, and it soul be possible
>> due power of templates get much more
>> safe and easily extendible code base IMHO. It would require lot of
>> expertise and _discipline_ but i cold be fun project
>>
>> also I wold love to have erlang implementation for IoT, as erlang seems
>> to be great fit for that
>> for this one i am with Joe, we need something small portable (and written
>> in c++ of course)
>>
>>
>> On Mon, Sep 25, 2017 at 11:15 PM, Richard A. O'Keefe <***@cs.otago.ac.nz
>> [mailto:***@cs.otago.ac.nz]> wrote:
>>
>> On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:2017-09-23 9:28 GMT+02:00
>> Oliver Korpilla <***@gmx.de[mailto:***@gmx.de]>:
>> [...]Having said that I see no immense security risk in writing code for
>> a remote sensor in C. It avoids one of the prime security risks: human user
>> interactions and all the buffer overrun problems and string processing
>> stuff that is so hard to do safely that there are still books being written
>> about.
>> If it is connected to the internet (the first letter in IoT), then it
>> at least needs to handle IPv4 - and it involves parsing of potentially
>> untrusted data.
>> The remote sensors I am interested in are *not* connected to the
>> internet. They are connected via radio to each other and to base
>> stations, and the base stations may then be connected to the
>> internet (probably using an OS and IP stack written in C).
>>
>> There is a serious point here that *end* devices are likely to be
>> as small as you can get away with. Instead of spending money on
>> bigger/faster machines, it's rather more useful to have *more*
>> machines that are just capable enough to do the job.
>>
>> Other people may be interested in other things.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-***@erlang.org[mailto:erlang-***@erlang.org]
>> http://erlang.org/mailman/listinfo/erlang-questions_________
>> ______________________________________ erlang-questions mailing list
>> erlang-***@erlang.org http://erlang.org/mailman/list
>> info/erlang-questions[http://erlang.org/mailman/listinfo/
>> erlang-questions]
>>
>
>
>
> _______________________________________________
> erlang-questions mailing listerlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
zxq9
2017-09-25 22:36:55 UTC
Permalink
On 2017年09月25日 月曜日 22:27:11 Grzegorz Junka wrote:
> Is it only me who thinks that implementing an actor-oriented functional
> language in an object-oriented C++ is kind of weird?

This implies C++ has actual objects or encapsulation.

<Drops mic. Runs...>

-Craig
Richard A. O'Keefe
2017-09-26 02:02:23 UTC
Permalink
Given that the motivation for the OP suggesting Rust
was memory safety, it is not without significance that
C++ is in no way a memory-safe language.

C++ is a wee bit fragile in the template area.
The type checking process is Turing-complete (because
the template language is a Turing-complete functional
language) and the C++ standard allows C++ compilers
to give up, but it does not require them to give up at
the same point. Nor, unless/until "concepts" are
adopted are C++ templates type-checkable at the point
of definition, unlike ML functors.
Anthony Ramine
2017-09-23 08:22:20 UTC
Permalink
It is if you don't have the deep pockets to actually get licenses or the checkers, and developers experimented enough to comprehend them.

> Le 23 sept. 2017 à 09:09, ***@cs.otago.ac.nz a écrit :
>
> I could sit here all night citing papers about static
> and dynamic checkers and verifiers for C. "In C" and
> "in a memory-safe language" do NOT have to be exclusive
> alternatives.
Attila Rajmund Nohl
2017-09-22 10:42:58 UTC
Permalink
2017-09-21 19:12 GMT+02:00 Frank Muller <***@gmail.com>:
[...]
> 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.
scott ribe
2017-09-22 11:08:36 UTC
Permalink
> 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
***@elevated-dev.com
(303) 722-0567
Tristan Sloughter
2017-09-13 22:54:04 UTC
Permalink
Alternatively, work on Alpaca (https://github.com/alpaca-lang/alpaca)
and improvements to BEAM :)
--
Tristan Sloughter
"I am not a crackpot" - Abe Simpson
***@crashfast.com


On Wed, Sep 13, 2017, at 04:43 AM, Jesper Louis Andersen wrote:
> On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev
> <***@gmail.com> 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-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
Zachary Kessin
2017-09-14 06:15:34 UTC
Permalink
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 <***@crashfast.com> wrote:

> Alternatively, work on Alpaca (https://github.com/alpaca-lang/alpaca) and
> improvements to BEAM :)
>
> --
> Tristan Sloughter
> "I am not a crackpot" - Abe Simpson
> ***@crashfast.com
>
>
> On Wed, Sep 13, 2017, at 04:43 AM, Jesper Louis Andersen wrote:
>
> On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <***@gmail.com> 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-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> 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
Dmytro Lytovchenko
2017-09-13 11:47:54 UTC
Permalink
I am a strong proponent for rewriting parts of BEAM VM in C++, and I've
even made a list of points to consider and benefits it would bring:
http://beam-wisdoms.clau.se/en/latest/otp-cpp-ramblings.html I was
personally ready to sink a lot of my time into this both paid (we have our
ways to get paid for helping OTP team) and unpaid. But i never started
because OTP team wasn't happy with this idea.

Main problem with all these rewritings, is that either you fork and take
over the fork completely, i.e. maintain version and all bugfixes and all
new developments, or you listen what OTP team has got to say. And so far
they say no to any major rewrite.

2017-09-13 13:11 GMT+02:00 Jesper Louis Andersen <
***@gmail.com>:

> On Tue, Sep 12, 2017 at 10:10 PM austin aigbe <***@gmail.com> wrote:
>
>> Hello,
>>
>> Any consideration for implementing the Erlang VM in Rust?
>>
>>
> I think the problem is roughly the same as with any other language: A lot
> of good effort has been sunk into the current VM in C and this makes a
> switch harder. Rust has ABI compatibility with C in some ways, which makes
> interoperability simpler, so one could imagine taking some of the more
> security-oriented parts of the VM and rewriting those in Rust or some other
> language of the more restrictive kind.
>
> If you want to rewrite all of it, a good approach is to start by making
> changes to the current VM which makes it smaller:
>
> * Move more work out into NIFs. Reimplement those in Rust
> * Coalesce more work on Dirty Schedulers
> * Implement Native Processes, so you can start running
> Rust-native-processes
> * Write an AOT or JIT compiler pass. Move ETS into pure Erlang. Move a lot
> of the BIF optimized functions into pure Erlang.
>
> A smaller core is way easier to replace.
>
> Personally, I'd just throw some more time after concurrent OCaml, and then
> write a translator from Erlang to OCaml :P
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
zxq9
2017-09-13 11:49:36 UTC
Permalink
On 2017年09月13日 水曜日 13:47:54 Dmytro Lytovchenko wrote:
> I am a strong proponent for rewriting parts of BEAM VM in C++

As a serious thought, or as satire?
Dmytro Lytovchenko
2017-09-13 11:53:40 UTC
Permalink
Absolutely serious.
It is all listed in that article I linked, I wrote it.

2017-09-13 13:49 GMT+02:00 zxq9 <***@zxq9.com>:

> On 2017幎09月13日 氎曜日 13:47:54 Dmytro Lytovchenko wrote:
> > I am a strong proponent for rewriting parts of BEAM VM in C++
>
> As a serious thought, or as satire?
> _______________________________________________
> erlang-questions mailing list
> erlang-***@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
Continue reading on narkive:
Loading...