Erlang VM in Rust

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

Re: Erlang VM in Rust

zxq9-2
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
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Joe Armstrong-2
In reply to this post by Anthony Ramine-4
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 <[hidden email]> 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 <[hidden email]> a écrit :
>>
>> I'd like to make an extremely small extremely slow Ertang targeted to
>> IOT devices - low power devices with small memory and slow clocks.
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Peer Stritzinger-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> a écrit :
>>>
>>> I'd like to make an extremely small extremely slow Ertang targeted to
>>> IOT devices - low power devices with small memory and slow clocks.
>>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

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

Re: Erlang VM in Rust

Max Lapshin-2
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.

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

Re: Erlang VM in Rust

Richard A. O'Keefe-2
In reply to this post by Anthony Ramine-4
> 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.



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

Re: Erlang VM in Rust

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

Re: Erlang VM in Rust

Anthony Ramine-4
In reply to this post by Richard A. O'Keefe-2
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, [hidden email] 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.

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

Re: Erlang VM in Rust

Anthony Ramine-4
In reply to this post by Oliver Korpilla
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 <[hidden email]> 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

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

Re: Erlang VM in Rust

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" <[hidden email]>
An: "Oliver Korpilla" <[hidden email]>
Cc: [hidden email], "erlang-questions Questions" <[hidden email]>
Betreff: Re: [erlang-questions] Erlang VM in Rust
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 <[hidden email]> 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
 

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

Re: Erlang VM in Rust

Attila Rajmund Nohl
In reply to this post by Oliver Korpilla
2017-09-23 9:28 GMT+02:00 Oliver Korpilla <[hidden email]>:
[...]
> 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.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Richard A. O'Keefe-2


On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:
> 2017-09-23 9:28 GMT+02:00 Oliver Korpilla <[hidden email]>:
> [...]
>> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

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) 


On Mon, Sep 25, 2017 at 11:15 PM, Richard A. O'Keefe <[hidden email]> wrote:


On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:
2017-09-23 9:28 GMT+02:00 Oliver Korpilla <[hidden email]>:
[...]
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


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

Re: Erlang VM in Rust

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" <[hidden email]>
An: "Erlang-Questions Questions" <[hidden email]>
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 <[hidden email][mailto:[hidden email]]> wrote:

On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:2017-09-23 9:28 GMT+02:00 Oliver Korpilla <[hidden email][mailto:[hidden email]]>:
[...]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
[hidden email][mailto:[hidden email]]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

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

 

On Mon, Sep 25, 2017 at 11:53 PM, Oliver Korpilla <[hidden email]> 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" <[hidden email]>
An: "Erlang-Questions Questions" <[hidden email]>
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 <[hidden email][mailto:[hidden email]]> wrote:

On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:2017-09-23 9:28 GMT+02:00 Oliver Korpilla <[hidden email][mailto:[hidden email]]>:
[...]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
[hidden email][mailto:[hidden email]]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] <a href="http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]


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

Re: Erlang VM in Rust

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


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 <[hidden email]> 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" <[hidden email]>
An: "Erlang-Questions Questions" <[hidden email]>
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 <[hidden email][mailto:[hidden email]]> wrote:

On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:2017-09-23 9:28 GMT+02:00 Oliver Korpilla <[hidden email][mailto:[hidden email]]>:
[...]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
[hidden email][mailto:[hidden email]]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] <a href="http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]" rel="noreferrer" target="_blank" moz-do-not-send="true">http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]



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


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

Re: Erlang VM in Rust

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

On Tue, Sep 26, 2017 at 12:27 AM, Grzegorz Junka <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
An: "Erlang-Questions Questions" <[hidden email]>
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 <[hidden email][mailto:[hidden email]]> wrote:

On 25/09/17 10:41 PM, Attila Rajmund Nohl wrote:2017-09-23 9:28 GMT+02:00 Oliver Korpilla <[hidden email][mailto:[hidden email]]>:
[...]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
[hidden email][mailto:[hidden email]]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]



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


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



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

Re: Erlang VM in Rust

zxq9-2
In reply to this post by Grzegorz Junka
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
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Richard A. O'Keefe-2
In reply to this post by Karlo Kuna
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang VM in Rust

Technion
In reply to this post by Max Lapshin-2

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: [hidden email] <[hidden email]> on behalf of Max Lapshin <[hidden email]>
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.

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