Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)

[peter-h]

One could have written the same about Ruby on Rails. Totally superior to everything. Today, a dead language, unless you want to pay COBOL66 daily rates I know, since I "run" a server done in Ruby, 15-20 years ago. Thankfully, it needs no maintenance but if it did I would have to abandon it

Or quite a few other languages.

There is a lot of understanding of PHP, acquired over past 20-25 years, which means finding somebody who can get into it is a lot easier, hence I continue to specify it. It was all the rage 20-25 years ago, but got a bad name due to so many hackers using it badly. A bit like C really

The experts I know think that Ruby is more secure than PHP (there is no dispute there btw) simply because the "IQ barrier" to entry is so much higher, so only really smart people know Ruby. A bit like C really

Often an overriding factor is the availability of ready-written modules. I think for embedded nearly everything is in C. Let's say you need ETH USB TCP TLS. Zero chance of writing it yourself. Even if you are brilliant, it would take 10 years of your life.

That is also true server-side. But fashions move. A few years ago, Laravel was all the rage. Now it is fading. Well, it could have been predicted, with the BS on their website: The PHP Framework
for Web Artisans

[coppice]

One could have written the same about Ruby on Rails.

The rise and fall of Ruby off the Rails was quite spectacular. If you vacationed at the right moment it might have been hot when you started and obscure when you got home.

[tggzzz]

One could have written the same about Ruby on Rails.

The rise and fall of Ruby off the Rails was quite spectacular. If you vacationed at the right moment it might have been hot when you started and obscure when you got home.

When Ruby appeared, I pegged it as the triumphant reinvention of Smalltalk (which I like), but as single-thread executable it was far less interesting than Java. I ignored it, as I do all "me too" languages.

[peter-h]

Ruby is still significant in the corporate sphere, but the daily rates for coders are ~ 1.5k GBP / day.

If you talk about long term mod-ability, in reality one rarely needs a large mod done. With PHP, anybody who knows PHP can dive in and do it. With a language which is off the beaten track, like Ruby, the people who can make any sense of it are very rare. I have a rather sad example: I wanted someone to add a graphical captcha for user signups on the ruby written application (server is Centos+NGINX). I found a guy who had done some Ruby. By the time he got it going, he died of a brain tumour. You just had to be a real expert.

So I think any off the beaten track language will just bite you in the bum.

Obviously (cynicism++) if you are a contractor then you don't need to care.

I think there is potential for Python for embedded but struggle to convince myself, versus the cost of implementation on the target.

[tggzzz]

So I think any off the beaten track language will just bite you in the bum.

The trick is to spot the new language that will become widely used, and ignore those that won't.

[coppice]

So I think any off the beaten track language will just bite you in the bum.

Obviously (cynicism++) if you are a contractor then you don't need to care.

You mean contractors benefit from a contracting market? How strange?

[ejeffrey]

The context here is "embedded" and there you usually have a huge problem when compared to other uses: no user interface capable of reporting errors.

Only if you don't build an error reporting mechanism.  Sometimes that isn't desirable to do, but many many embedded systems do have ways to report or log errors -- whether a display, a network connection, a serial port, or just logging crash data to extra flash. 

[quiote]
So all the stuff which Language X might have to prevent say buffer overflow is of no use, because the product will just crash, or maybe reboot, perhaps with a watchdog reset.
[/quote]

This is completely wrong.  Detecting memory errors while avoiding memory corruption caused by buffer overflow is fantastically useful in any situation.  Even if all you do is trigger the hard fault handler.  It is much more likely to isolate the bug to the time when it occurs, avoids corrupting the stack trace so that you can actually analyze the bug when you have a debug environment.  It makes runtime error recovery at least possible in some situations.  One particular advantage to an embedded system is that it avoids spreading memory errors to more critical (and better tested) parts of a program.  With array bounds checking a buffer overflow in a UI event loop is much less likely to corrupt the the data structures used by a PWM motor driver causing it to do something bad.  This is not something you should rely on for safety, but it could avoid equipment putting itself in an undamaged state.

Nobody is arguing that using automated checking tools will fix all bugs.  That is a strawman argument and pointless to consider.  But good tools can make us likely to make certain classes of mistakes, limit the scope of damage when they occur, and make them easier to find and fix.

AFAICT the only benefit some other language might have is better static analysis.

Of course static analysis is even more effective when it works. Which is what rust does: static memory usage analysis of both stack and heap variables.  I haven't used it enough to know how well it works, but the that is definitely part of the goal.

[peter-h]

Detecting memory errors while avoiding memory corruption caused by buffer overflow is fantastically useful in any situation.

Yes, if you have the box in front of you. Not after you have shipped 10k of them But with a PC or similar you can get away with it.

In most embedded applications you either have no way for telemetry, or the customer would not authorise it.

both stack and heap variables

Heap in embedded is a disaster, usually.

You mean contractors benefit from a contracting market? How strange?

Yes; in the short term. The incentives are just different.

[NorthGuy]

But good tools can make us likely to make certain classes of mistakes, limit the scope of damage when they occur, and make them easier to find and fix.

Do you suggest always using range checks?

How about algorithms where range check cannot be performed? Do you suggest banning them completely?

[tggzzz]

But good tools can make us likely to make certain classes of mistakes, limit the scope of damage when they occur, and make them easier to find and fix.

Do you suggest always using range checks?

How about algorithms where range check cannot be performed? Do you suggest banning them completely?

Do you suggest deliberately writing code that doesn't detect errors and failsafe?

Strawman arguments are annoying, and generate heat rather than light. Hint: don't introduce false dichotomies into a discussion.

[coppice]

You mean contractors benefit from a contracting market? How strange?

Yes; in the short term. The incentives are just different.

Not necessarily so short. It saw many a COBOL programmer through to comfortable retirement.

[peter-h]

We don't disagree

[NorthGuy]

But good tools can make us likely to make certain classes of mistakes, limit the scope of damage when they occur, and make them easier to find and fix.

Do you suggest always using range checks?

How about algorithms where range check cannot be performed? Do you suggest banning them completely?

Do you suggest deliberately writing code that doesn't detect errors and failsafe?

Strawman arguments are annoying, and generate heat rather than light. Hint: don't introduce false dichotomies into a discussion.

These are not arguments, but questions. Addressed to @ejeffrey.

[profdc9]

I am an electrical engineer and almost 50 years old and I have been writing code since 1982, so my entire adult life and most of my childhood on 80s micros.

Here's what I've had to learn: C, C++, Pascal, COBOL, Fortran 77, dBase III/IV/FoxPro, 6502 assembly, 8086 assembly, 80386 assembly, Matlab, Python 1/2/3, Perl, Lua, Forth, Java, various flavors of SQL, and probably tons of stuff I am forgetting.  It got so bad that I could write an entire page of code before I realized I was writing it in the wrong language.

I started to dislike programming during the 90s with the battle between Microsoft and Sun.  It was clear that the whole Java vs. .NET was not about making life better for the programmer, but forcing the programmer to commit to learning an extensive system of idiosyncratic libraries to be able to do their work, thus taking time away from learning a competitor's idiosyncratic language and libraries.    Things have not improved much since then, except for perhaps the presence of open source being an alternative that motivates the commercial software vendors not to engage in excessively deleterious behavior.

Generally the more fanatical the support of a language is, the less practical the language.  While I can see some value to the design choices made in Rust, in particular the aspect of forcing the programmer to "prove" to the compiler that certain aspects of their program likely work as intended, it seems that there is an idea that Rust code makes code which is inherently bug-free and self-documenting, and that this is the revolutionary part of Rust.  Rust forces certain design patterns on the programmer that can be proved by the compiler to work in a particular way (but not necessarily the way that is desired), and any deviation from these patterns requires unsafe code for which the proofs are not required.  This could be helpful to ensure certain guarantees about code quality, for example, the prevention of memory or resource leaks.  Perhaps in some cases that may be a reason to adopt Rust vs. another computer language that has much wider adoption and support.  Other aspects, for example, ensuring that worst case dynamic memory allocation and fragmentation doesn't result in unavailable memory, or that worst-case latencies are not excessive, seem harder to prove. 

I think the only real proof will be to see the astounding productivity that embedded Rust programmers have, with millions of dollars saved from not having to roll out emergency bug fixes or firmware updates.  But creating a language that makes programming harder is going to be a non-starter for most people, because of the effort paid up front for only prospective future gains.  One of the craziest things I find about most Rust documentation is that it tends to spend more time explaining what one should not do, rather than how to do something.  This already takes a language that is manifestly unfriendly and makes it downright unapproachable.

[peter-h]

with millions of dollars saved from not having to roll out emergency bug fixes or firmware updates

It won't achieve that, because the marketplace usually moves too fast to fix bugs before version++ happens

[tggzzz]

I am an electrical engineer and almost 50 years old and I have been writing code since 1982, so my entire adult life and most of my childhood on 80s micros.

Here's what I've had to learn: C, C++, Pascal, COBOL, Fortran 77, dBase III/IV/FoxPro, 6502 assembly, 8086 assembly, 80386 assembly, Matlab, Python 1/2/3, Perl, Lua, Forth, Java, various flavors of SQL, and probably tons of stuff I am forgetting.  It got so bad that I could write an entire page of code before I realized I was writing it in the wrong language.

I started to dislike programming during the 90s with the battle between Microsoft and Sun.  It was clear that the whole Java vs. .NET was not about making life better for the programmer, but forcing the programmer to commit to learning an extensive system of idiosyncratic libraries to be able to do their work, thus taking time away from learning a competitor's idiosyncratic language and libraries.    Things have not improved much since then, except for perhaps the presence of open source being an alternative that motivates the commercial software vendors not to engage in excessively deleterious behavior.

Java was fine; even on first release it enabled programmers to easily do basic simple things that C++ had failed to manage in a decade. The pleasure of not having to re-invent yet again a dictionary or set or growable array or String was delightful - it enabled me to concentrate on my task not on a deficient tool. That's the benefits of standard libraries.

OTOH, C# was deliberately pitched as a me-too Java killer - Anders Hejlsberg said as much when he gave a talk at my workplace (HPLabs) a few months before C# was launched. At least 50 people attended; I never saw anyone bothering to use the language.

OTOH learning the framework of the month (cf the standard library) is something you only do when necessary.

Generally the more fanatical the support of a language is, the less practical the language.  While I can see some value to the design choices made in Rust, in particular the aspect of forcing the programmer to "prove" to the compiler that certain aspects of their program likely work as intended, it seems that there is an idea that Rust code makes code which is inherently bug-free and self-documenting, and that this is the revolutionary part of Rust.  Rust forces certain design patterns on the programmer that can be proved by the compiler to work in a particular way (but not necessarily the way that is desired), and any deviation from these patterns requires unsafe code for which the proofs are not required.  This could be helpful to ensure certain guarantees about code quality, for example, the prevention of memory or resource leaks.  Perhaps in some cases that may be a reason to adopt Rust vs. another computer language that has much wider adoption and support.  Other aspects, for example, ensuring that worst case dynamic memory allocation and fragmentation doesn't result in unavailable memory, or that worst-case latencies are not excessive, seem harder to prove. 

Ah. Those old chestnuts. They were trotted out against using "structured programming" and avoiding goto.

I think the only real proof will be to see the astounding productivity that embedded Rust programmers have, with millions of dollars saved from not having to roll out emergency bug fixes or firmware updates.  But creating a language that makes programming harder is going to be a non-starter for most people, because of the effort paid up front for only prospective future gains.  One of the craziest things I find about most Rust documentation is that it tends to spend more time explaining what one should not do, rather than how to do something.  This already takes a language that is manifestly unfriendly and makes it downright unapproachable.

Creating something correct is always going to be more difficult than creating something almost, sort-of, when-the-wind-is-blowing-in-the-right-direction correct. Deal with it.

If I'm allowed to create something that is incorrect, I can very quickly create something that is very fast and uses very few resources. Is that really the objective?

[nctnico]

Detecting memory errors while avoiding memory corruption caused by buffer overflow is fantastically useful in any situation.

Yes, if you have the box in front of you. Not after you have shipped 10k of them But with a PC or similar you can get away with it.

In most embedded applications you either have no way for telemetry, or the customer would not authorise it.

I think there is a slight disconnect here. If you can detect problems in runtime, you can let the device fail in a controlled manner which is better compared to letting it go on with bad values and do something random. If a device fails in a controlled manner, it is likely that you get sensible feedback from the customer as well because there may be a clear cause & effect (I do this, and that happens) so fixing the bug will be easier. So yes, even without telemetry, debug output or whatever, having a device fail in a controlled manner is way better compared to letting it run and crash 'randomly'.

And ofcourse having runtime detection of problems helps during the test phase of the product to find lingering problems.

[gmb42]

With PHP, anybody who knows PHP can dive in and do it.

And this, in my elitist opinion, is why most PHP "applications" are piles of steaming shit.

[NorthGuy]

If you can detect problems in runtime, you can let the device fail in a controlled manner which is better compared to letting it go on with bad values and do something random. If a device fails in a controlled manner, it is likely that you get sensible feedback from the customer as well because there may be a clear cause & effect (I do this, and that happens) so fixing the bug will be easier. So yes, even without telemetry, debug output or whatever, having a device fail in a controlled manner is way better compared to letting it run and crash 'randomly'.

Consider a different scenario. There's a bug which doesn't have any effect on the functionality. But you detect it and fail in a controlled manner at the time when the customer needs your device the most. The cure may be worse than the disease.
.
Effects of bugs are unpredictable, therefore it is silly to make assumptions about the nature and magnitude of the effects, let alone try to mitigate these unknown effects.

A software engineer should try to minimize the number of bugs. The best way to do this is by simplifying the design, because nothing breads bugs more than unneeded complexity. Unfortunately too many people believe they can cure bugs by using "safe" languages (or whatnot), as savages believe that their amulets protect them from nastiness of the outside world.

[tggzzz]

If you can detect problems in runtime, you can let the device fail in a controlled manner which is better compared to letting it go on with bad values and do something random. If a device fails in a controlled manner, it is likely that you get sensible feedback from the customer as well because there may be a clear cause & effect (I do this, and that happens) so fixing the bug will be easier. So yes, even without telemetry, debug output or whatever, having a device fail in a controlled manner is way better compared to letting it run and crash 'randomly'.

Consider a different scenario. There's a bug which doesn't have any effect on the functionality. But you detect it and fail in a controlled manner at the time when the customer needs your device the most. The cure may be worse than the disease.

That's why battleships short out the fuses just before going into action.

Fuses are still a good idea in most circumstances.

Effects of bugs are unpredictable, therefore it is silly to make assumptions about the nature and magnitude of the effects, let alone try to mitigate these unknown effects.

A software engineer should try to minimize the number of bugs.

And one excellent way to do that is to use a language that prevents whole classes of bugs being created, not spotted, and deployed.

You go on to mention one other way...

The best way to do this is by simplifying the design, because nothing breads bugs more than unneeded complexity. Unfortunately too many people believe they can cure bugs by using "safe" languages (or whatnot), as savages believe that their amulets protect them from nastiness of the outside world.

The counterpoint is also true: using an "unsafe" language doesn't protect you.

There are no panaceas.

We should use all tools at our disposal to reduce defects in deployed systems.

[NorthGuy]

The counterpoint is also true: using an "unsafe" language doesn't protect you.

Absolutely! You finally got my point. The language doesn't matter.

[tggzzz]

The counterpoint is also true: using an "unsafe" language doesn't protect you.

Absolutely! You finally got my point. The language doesn't matter.

You deliberately missed the important point to concentrate on a minor point. Why?

The important point that you chose to snip is "There are no panaceas. We should use all tools at our disposal to reduce defects in deployed systems."

"Safe" languages are an important tool in reducing defects.

[NorthGuy]

We should use all tools at our disposal to reduce defects in deployed systems.

That's true too. You need to evaluate different solutions and make decisions based on your evaluation. Which, BTW,  you cannot do until you know what is that you're supposed to build.

Believing that using a certain language would solve problems is like believing that choosing a certain hammer would let you build a better house. There are other things to consider first - blueprints, materials, construction methods ...

[Siwastaja]

"Safe" languages are an important tool in reducing defects.

While that is true, it's a qualitative statement, not quantitative. Observing my own recent history, 95% of bugs have been something not avoidable by a different language; sad, because it would be nice to have such a silver bullet language.

Software has always been buggy, and still is, despite the fact gazillions of new languages and tools are being introduced all the time. If some of them truly helped to significantly reduce the number of bugs, why wouldn't such a language get embraced by developers?

The answer is dire: people expect the new languages to be immensely helpful so they try, but the end result is the same each time; a few upsides, maybe a few avoided bugs, but then again, most of the bugs sneak in just like they always did, and there are always some unexpected downsides to any new language which isn't instantly obvious.

Before nctnico starts building another strawman, I mention explicitly: this is not to say adding safety in languages and tooling is a bad idea, or totally useless. Just trying to put things in perspective, for the big picture.

Finally, I can see a semantic trick lurking here. In certain fields, especially regulated ones, say aviation, there is stricter separation between design (not in the final programming language) and implementation. If you don't count design errors as "bugs" at all, then surely your number of bugs goes down significantly, and from what remains, larger part are those that could be prevented by using a more "safe" programming language.

[tggzzz]

"Safe" languages are an important tool in reducing defects.

While that is true, it's a qualitative statement, not quantitative. Observing my own recent history, 95% of bugs have been something not avoidable by a different language; sad, because it would be nice to have such a silver bullet language.

There are no silver bullet languages, and never will be.

Reducing 5% (to use your figure) can be very important; it depends on when the latent bug would have been found and the consequences. No surprises there.

Software has always been buggy, and still is, despite the fact gazillions of new languages and tools are being introduced all the time. If some of them truly helped to significantly reduce the number of bugs, why wouldn't such a language get embraced by developers?

The answer is dire: people expect the new languages to be immensely helpful so they try, but the end result is the same each time; a few upsides, maybe a few avoided bugs, but then again, most of the bugs sneak in just like they always did, and there are always some unexpected downsides to any new language which isn't instantly obvious.

There are many reasons, some good some bad, why better mousetraps aren't embraced. People are complex.

Finally, I can see a semantic trick lurking here. In certain fields, especially regulated ones, say aviation, there is stricter separation between design (not in the final programming language) and implementation. If you don't count design errors as "bugs" at all, then surely your number of bugs goes down significantly, and from what remains, larger part are those that could be prevented by using a more "safe" programming language.

It is worth embracing a new tool that aids avoiding avoidable defects.

While aviation (etc) enforces separation between validation (do the right thing) and verification (do the thing right), I've used modelling and/or design verification in almost all my activities before implementing and verifying in the final language.