[erlang-questions] Erlang VM in Rust

[austin aigbe]

Hello,

Any consideration for implementing the Erlang VM in Rust?

Regards,

Austin

[Dmytro Lytovchenko]

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 :)

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Loïc Hoguin]

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,

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu

[zxq9]

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]

On Wed, Sep 13, 2017 at 10:42 AM zxq9 <zx...@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/). 

[Joshua Barney]

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

[scott ribe]

> On Sep 12, 2017, at 4:48 PM, Joshua Barney <joshm...@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
scott...@elevated-dev.com
(303) 722-0567

[Tristan Sloughter]

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
t...@crashfast.com

[David Goehrig]

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

[Richard A. O'Keefe]

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?

[zxq9]

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

[Thom Cherryhomes]

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

[zxq9]

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

[Joshua Barney]

Rust supports inline assembly https://doc.rust-lang.org/1.8.0/book/inline-assembly.html

Sent from my iPhone

[Jesper Louis Andersen]

On Tue, Sep 12, 2017 at 10:10 PM austin aigbe <eshi...@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]

> 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?

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

--

With best regards,

     Roman Galeev,

     +420 702 817 968

[Jesper Louis Andersen]

On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <jam...@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.

[Dmytro Lytovchenko]

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.

[zxq9]

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]

Absolutely serious.

It is all listed in that article I linked, I wrote it.

[Anthony Ramine]

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/

[Roman Galeev]

 > 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.

[Heinz N. Gies]

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.

[Daniel Goertzen]

- 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.

[Richard A. O'Keefe]

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.

[Richard A. O'Keefe]

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.

[Anthony Ramine]

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 <he...@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.

_______________________________________________

[Tristan Sloughter]

Alternatively, work on Alpaca (https://github.com/alpaca-lang/alpaca) and improvements to BEAM :)

--

  Tristan Sloughter

  "I am not a crackpot" - Abe Simpson

  t...@crashfast.com

[Zachary Kessin]

It seems to me an Idea that is interesting in theory but would involve a *LOT* of work for an unclear benefit.

Zach

ᐧ

--

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

[Raimo Niskanen]

On Wed, Sep 13, 2017 at 01:47:08AM +0000, Thom Cherryhomes wrote:
:

> the ass to do any intricate hardware driver work... I'm guessing that Rust
> is designed by 20-somethings who have never done a line of assembler in
> their lives?

That was a bit offensive...

>
> sigh.
> -Thom


--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

[Max Lapshin]

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.

[Anthony Ramine]

> Le 13 sept. 2017 à 03:47, Thom Cherryhomes <thom.che...@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.

[Heinz N. Gies]

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.

[Benoit Chesneau]

While we are on it , does rust run on solaris?

- benoit

[Sergej Jurečko]

> On 14 Sep 2017, at 13:10, Max Lapshin <max.l...@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

[Heinz N. Gies]

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 ...

[Sergej Jurečko]

> On 15 Sep 2017, at 19:47, Heinz N. Gies <he...@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]

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.

[Joe Armstrong]

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

[Anthony Ramine]

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 <erl...@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 8:18 GMT-03:00 Anthony Ramine <n.o...@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 <erl...@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.

[Jesper Louis Andersen]

On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <o...@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]

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

[Richard Carlsson]

2017-09-19 15:57 GMT+02:00 Karl Nilsson <kjni...@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]

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.

[Zachary Kessin]

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 <daniel....@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 <kjni...@gmail.com> wrote:

On Tue, 19 Sep 2017 at 12:41 Jesper Louis Andersen <jesper.louis.andersen@gmail.com> wrote:

On Wed, Sep 13, 2017 at 11:38 PM Richard A. O'Keefe <o...@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-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Jeremy Pierre]

Begging the list's indulgence with tangential and possibly off-topic content.

On Tue, Sep 19, 2017 at 7:57 AM Daniel Goertzen <daniel....@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

[James Churchman]

My opinion is that a full re-write of all VM's in Rust, especially the Erlang VM should be a very very high priority in the world of computing .. the benefit of memory safety in all languages, including low level, can not be underestimated in all of security, reliability and developer productivity. Over time, code that is not written in memory safe languages will be viewed in the same way as coding full of goto's or writing full apps in assembler.

The cost of the rewrite in rust would be quite large, including:

1) A time consuming, complex process for a full rewrite

2) New bugs in the new implementation that will take a while to trace down 

( tho the prevalence of large code bases written in Erlang with randomised property tests would help find these a lot faster tho ) 

3) Incompatibilities that are likely inevitable

4) Wide performance differences : tho its lightly the rewrite could be gigantically faster ( judging by the performance of Hype alone ) there would be large scale Erlang systems that are tuned for the current VM .. some of these may expect very specific behaviour in scheduling, the GC, networking & more and would lightly need some heavy profiling and re-tuning to perform well. Also as the new VM would become popular the opposite would happen: some library's would run very fast on the new VM and slower on the old one

5) New users asking "which VM should I chose for my deployment" and the lightly very complex answers that come back causing some confusion.

6) Breaking NIF & C driver compatibility ( tho, it may be possible to provide a compatibility layer in some circumstances )

7) Some tooling ( e.g. the debugger if its used by anyone etc.. ) no longer working 

8) Platform portability being slightly different vs the current vm

9) A pause in curent VM development while the new one is built if its a full rebuild, tho an incremental rebuild or the development of a small mini proof of concept / embeddable vm would not have this issue

The advantages going forward would be huge :

1) An ahead-of-time (AOT) optimising compiler targeting a high level machine code ( say LLVR IR ) could give a 10x performance boost, if not more. This would be far easer to write in rust 

2) Hugely higher level of innovation ( once written & complete ) and future progress in the VM. Rust is so much more productive than C its crazy .. the borrow checker, tighter type system, no memory allocation errors, pattern matching, better macros, cleaner higher level syntax, inbuilt & safe mutex's, better inbuilt data structures and standard library, type classes, a package manager etc.. 

3) Encouraging more open source contributions to the VM

4) Fantastic parallelism in the language + libraries too ( e.g. Rayon https://github.com/nikomatsakis/rayon )

5) Far higher security in the VM .. this is not to say the current VM has any issues with security, but this is ensured by very high quality of coding and putting trust in that. Rust will eliminate the most common security issues found in code today. This extends into both future developments ( you can't guarantee secure code to day is secure after code changes ) and security of all included libaries. Tho Erlang was not effected by openSSL issues ( due to what parts it did / did not use ) it still included a code base with a gigantic security issue .. importing ( mostly ) native rust libraries and their updates would improve this greatly 

6) Reducing the need for nifs : most NIF's ( tho not all ) are written for performance, with a much faster VM these may not be needed

7) Writing more of the VM / BIF's in Erlang, due to the higher performance

8) Secure, crash resistant NIFS written in Rust 

9) Far smaller more modern implementation 

10) Far more portable & embeddable implementation. It would be fantastic to be able to compile the VM and run it in the browser using WebAssembly, be able to embed Erlang into a desktop app, maybe simply to use its networking functionality, embed it into other libraries for other languages etc.. ( like Lua embedded for example )

11) Making use of the Cargo packages and package manager for Rust. A huge benefit to rust is how good the package manager is and the amazing number of amazing packages. There are for example a huge range of lock free concurrent data structures right there in Cargo. These could be very useful in building the erlang VM

12) Far more modular implementation. Modern Rust applications are a collection of modest sized packages, built using Cargo rather than one gigantic code base. This allows far better code sharing between unrelated projects + often far better testing of each model & often more stable / better API designs per module.

13) A formally verified vm?

14) Setting a future direction where all low level code is written in secure, modern, memory safe languages 

Anyhow my 2 pence !

On 20 September 2017 at 16:31, Jeremy Pierre <j.1...@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 <daniel....@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 <kjni...@gmail.com> wrote:

[zxq9]

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]

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.

[Loïc Hoguin]

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]

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

[Felix Gallo]

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.

[James Churchman]

On 21 September 2017 at 19:26, Felix Gallo <felix...@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 <frank.mu...@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]

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

[James Churchman]

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?

[Joe Armstrong]

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

[Attila Rajmund Nohl]

2017-09-21 19:12 GMT+02:00 Frank Muller <frank.mu...@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]

> 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
scott...@elevated-dev.com
(303) 722-0567

[Anthony Ramine]

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 <erl...@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]

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]

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

[Peer Stritzinger]

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

[Max Lapshin]

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]

> 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]

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]

It is if you don't have the deep pockets to actually get licenses or the checkers, and developers experimented enough to comprehend them.

[Anthony Ramine]

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 <Oliver....@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]

Hey, Anthony.

 

I think you are making an argument for argument's sake, but I don't see it as black and white. ;-)

 

DNA is probably the most complex input string you can imagine, so I'm not surprised they managed to do that. Naturally occurring viruses break complex systems coded in DNA for eons now... We're a bit late to the party.

 

Now, sensor input might or might not be able to break a system. Can't see how numeric data will do that easily, though. I guess it's possible, but it's a lot easier to protect against, too.

 

I will not deny there's risk, but in this case the risk is small. BTW, I do not wish to make the case that a small system should be written in C. I think there's good reasons for it to be done in Rust or other languages.

 

I don't think it's a panacea, either. For existing systems, risk inherent in the existing system has to be weighed against the effort and bugs introduced by rewriting a system. And that is an entirely different business case, one which keeps countless Fortran and Cobol libraries alive because a known bug is often preferrable to a rewrite, for example when considering engineering applications where a minor error in computing outcomes can lead to catastropic outcomes in the real world.

 

The bigger an existing is, the worse the business case for a rewrite is. Not saying it should not be done, but it should be evaluated impartially first. This includes honestly evaluating whether enough volunteers can be found to even make it feasible. It might probably fail on that last count even if a clear gain in stability can be expected ... in the long run.

 

Best regards,

Oliver

 

Gesendet: Samstag, 23. September 2017 um 10:29 Uhr
Von: "Anthony Ramine" <n.o...@gmail.com>
An: "Oliver Korpilla" <Oliver....@gmx.de>
Cc: o...@cs.otago.ac.nz, "erlang-questions Questions" <erlang-q...@erlang.org>
Betreff: Re: [erlang-questions] Erlang VM in Rust

[Attila Rajmund Nohl]

2017-09-23 9:28 GMT+02:00 Oliver Korpilla <Oliver....@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]

On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:
> 2017-09-23 9:28 GMT+02:00 Oliver Korpilla <Oliver....@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]

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) 

[Oliver Korpilla]

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" <kuna....@gmail.com>
An: "Erlang-Questions Questions" <erlang-q...@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 <o...@cs.otago.ac.nz[mailto:o...@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 <Oliver....@gmx.de[mailto:Oliver....@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-q...@erlang.org[mailto:erlang-q...@erlang.org]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list erlang-q...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]

[Karlo Kuna]

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

 

erlang-q...@erlang.org[mailto:erlang-questions@erlang.org]

[Grzegorz Junka]

Is it only me who thinks that implementing an actor-oriented functional language in an object-oriented C++ is kind of weird?

GrzegorzJ

http://erlang.org/mailman/listinfo/erlang-questions

[Karlo Kuna]

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

[zxq9]

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]

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.

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org

http://erlang.org/mailman/listinfo/erlang-questions

[Technion]

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-quest...@erlang.org <erlang-quest...@erlang.org> on behalf of Max Lapshin <max.l...@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