About Rust in embedded

[uliano]

Curious, I periodically make some effort to get a little more into this topic and then I usually get lost somewhere (mostly due to out of date introductory material and lack of documentation  ).

I just stumbled upon this fresh new YouTube channel and I think he's really off on the right foot, if only for the lack of "uhmmm..."ing. The quality of both content and editing is really outstanding. Let's hope he can keep up with this.

(disclaimer, I have nothing to do with that guy)

Edit: for whatever reason the link was missing 

https://www.youtube.com/@therustybits/videos

[josfemova]

imho the problem with embedded Rust adoption is the lack of good quality, easy-to-follow training material as you point out. In part this is due to the majority of development following a "perf supremacy" mentality, which fair enough is a valid tradeoff and SDKs in other languages make it, but the issue is that there is no "Arduino" or "CircuitPython" for Rust.

And like, is not like the current crates in the ecosystem are "bad", but a simple observation to make is that it became way easier to introduce people to embedded C when Arduino came out. In Rust it feels like you don't get anything under the difficulty level of learning to work with CMSIS-based SDKs which of course.

The current situation is that Rust is great to use If you already know some stuff about fw dev, but not so great to onboard someone into fw dev

[nctnico]

And realistically performance is not very critical for a large part of embedded software as a significant part of embedded software is dealing with interfacing to the outside world. Security is way more important. I foresee languages like Lua and (more likely) Python taking over in embedded programming.

[Siwastaja]

imho the problem with embedded Rust adoption is the lack of good quality, easy-to-follow training material as you point out.

To be fair, try to find good-quality, easy-to-follow embedded training material which uses C - or any other language, for that matter. So even for a mature language which everyone uses, the good tutorials / documentation simply never comes, therefore it is unrealistic to expect Rust would do better here.

[uer166]

imho the problem with embedded Rust adoption is the lack of good quality, easy-to-follow training material as you point out.

To be fair, try to find good-quality, easy-to-follow embedded training material which uses C - or any other language, for that matter. So even for a mature language which everyone uses, the good tutorials / documentation simply never comes, therefore it is unrealistic to expect Rust would do better here.

I'd argue lack of decent cross platform tools (from vendors ideally) is a bigger barrier.

[RoGeorge]

I think he's really off on the right foot

Good video editing, but damaging approach in my opinion.  The channel has 2 videos so far.  First, is a marketing pitch for the channel, it says nothing significant.

Second video installs the toolchain.  Very diluted useful info, if any.  Also, it doesn't make any sense unless you already know the subject, but then why watching a video about what you already know?  Then, he reads from the monitor a lot, numbers and such.  Certainly not my stile.

Then, he does the mistake of trying to be funny on an engineering teaching topic.  That's a bad idea.  Why everybody's trying to be a standup comedian?    The audience is not watching any 101 video for a laugh or for entertainment.

Another thing, don't use in a 101 class figurative words, interjections, emphasizing words and alike bloatware.  It almost looks like the text was AI generated or something (it was probably not).  And don't "sing" the words, don't put emotional content in voice, don't make faces to the camera, don't add background music.  In general, don't go for emotional engaging while teaching tech content, because emotions are distracting.  Can't have focus while distracted. 

While the effort of making teaching videos is laudable, and the editing shows a lot of care, that's not the kind of videos I would watch.

Though, for a first 2 videos, it looks like a promising channel. 

[Siwastaja]

I'd argue lack of decent cross platform tools (from vendors ideally) is a bigger barrier.

I disagree. Ridiculous amounts of work has gone into developing better and better embedded cross platform frameworks. Yet there is never success, they are either difficult and hard to use, or simple but too compromised. And there are too many, and they are short-lived, so now you have to learn an extra skill and still get nowhere. Generic hardware abstraction with the usual MCU requirements simply is an unsolvable problem. We would be better off by stopping this timesink. If the same amount of time would have been spent on documentation and tutorials, and just writing code to get more used to writing code, we would be far better off.

Edit: misunderstood, I fully agree when explained by JPortici.

[JPortici]

I'd argue lack of decent cross platform tools (from vendors ideally) is a bigger barrier.

I disagree. Ridiculous amounts of work has gone into developing better and better embedded cross platform frameworks. Yet there is never success, they are either difficult and hard to use, or simple but too compromised. And there are too many, and they are short-lived, so now you have to learn an extra skill and still get nowhere. Generic hardware abstraction with the usual MCU requirements simply is an unsolvable problem. We would be better off by stopping this timesink. If the same amount of time would have been spent on documentation and tutorials, and just writing code to get more used to writing code, we would be far better off.

i think he meant a compiler/crate/whatever sponsored by the manufacturers instead of having part support added by random people that may remove it in the future if they don't bother keeping on with language/toolchain changes
in which case i agree completely: I'm not going to consider rust for my embedded projects if my target MCU are not supported, and i'm very unlikely to use experimental toolchains in commercial products

[uer166]

I'd argue lack of decent cross platform tools (from vendors ideally) is a bigger barrier.

I disagree. Ridiculous amounts of work has gone into developing better and better embedded cross platform frameworks. Yet there is never success, they are either difficult and hard to use, or simple but too compromised. And there are too many, and they are short-lived, so now you have to learn an extra skill and still get nowhere. Generic hardware abstraction with the usual MCU requirements simply is an unsolvable problem. We would be better off by stopping this timesink. If the same amount of time would have been spent on documentation and tutorials, and just writing code to get more used to writing code, we would be far better off.

i think he meant a compiler/crate/whatever sponsored by the manufacturers instead of having part support added by random people that may remove it in the future if they don't bother keeping on with language/toolchain changes
in which case i agree completely: I'm not going to consider rust for my embedded projects if my target MCU are not supported, and i'm very unlikely to use experimental toolchains in commercial products

Yeah, gimme the Rust in CubeIDE or whatever with good support and I'll learn it! By cross-platform, I mean I can run it on Windows/Linux/Mac, all 3 of which I use.

[wek]

Maybe relevant? Rust for Embedded Systems: Current State, Challenges and Open Problems

JW

PS. Those videos... are IMO boring in an interesting way.

[dobsonr741]

Allow me to take Rust as the critique of the C based embedded frameworks. If I would move away/start again, my choice is Swift:

https://madmachineio.github.io/SwiftIO/documentation/swiftio/

Hardware is either their own or RP2040:
https://madmachine.io/collections/frontpage

A good example of documentation/learning guide: https://docs.madmachine.io/learn/peripherals/speaker

[RoGeorge]

Side note, Rust got some traction recently, might be used in the future for the Linux kernel, too. 

AFAIK, the Linux kernel was using only C, it was a total surprise to hear about Rust in the Linux kernel.  Not sure if that was only an attempt idea, or if it was put in practice already.

[tggzzz]

AFAIK, the Linux kernel was using only C,

Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/

it was a total surprise to hear about Rust in the Linux kernel.  Not sure if that was only an attempt idea, or if it was put in practice already.

Nothing will be rewritten. There are advanced hooks in place to allow new Rust code to interact with existing kernel code, e.g. new device drivers could be written in Rust. There are still a few wrinkles, but they can be overcome in time.

Summary: there will be Rust modules loaded into the kernel.

[nctnico]

AFAIK, the Linux kernel was using only C,

Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/

But tell me how Rust is any better as Rust also supports unsafe programming. And if you look at examples you'll see that you can't really use Rust without unsafe programming. So how is Rust going to stop programmers from cutting corners? It is no better than C or C++ in that respect.

Next thing we'll see is a whole lot of stuff in the Linux kernel using unsafe Rust because A) they can't make it work with safe Rust and B) the programmers think they are like Evil Knievel and keep doing the same coding stunts like you can find in the current Linux kernels. Meanwhile the Linux kernel would have gotten so much better both in code quality and performance when they would have rewritten it in C++.

So far Rust looks like a solution looking for a problem to me. It doesn't bring a new solution to an existing problem. Ada (which is highly regarded as a safe language) has been around for a long time and never gained mainstream traction because it needs a rather elaborate runtime (just like Rust if you read carefully enough).

[tggzzz]

AFAIK, the Linux kernel was using only C,

Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/

But tell me how Rust is any better as Rust also supports unsafe programming. And if you look at examples you'll see that you can't really use Rust without unsafe programming. So how is Rust going to stop programmers from cutting corners? It is no better than C or C++ in that respect.

Next thing we'll see is a whole lot of stuff in the Linux kernel using unsafe Rust because A) they can't make it work with safe Rust and B) the programmers think they are like Evil Knievel and keep doing the same coding stunts like you can find in the current Linux kernels. Meanwhile the Linux kernel would have gotten so much better both in code quality and performance when they would have rewritten it in C++.

So far Rust looks like a solution looking for a problem to me. It doesn't bring a new solution to an existing problem. Ada (which is highly regarded as a safe language) has been around for a long time and never gained mainstream traction because it needs a rather elaborate runtime (just like Rust if you read carefully enough).

Half a loaf is better than no bread.

Just because we can't stop bad drivers, it doesn't mean we shouldn't require seatbelts.

And time will tell; it is early days.

[josfemova]

AFAIK, the Linux kernel was using only C,

Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/

But tell me how Rust is any better as Rust also supports unsafe programming. And if you look at examples you'll see that you can't really use Rust without unsafe programming. So how is Rust going to stop programmers from cutting corners? It is no better than C or C++ in that respect.

Next thing we'll see is a whole lot of stuff in the Linux kernel using unsafe Rust because A) they can't make it work with safe Rust and B) the programmers think they are like Evil Knievel and keep doing the same coding stunts like you can find in the current Linux kernels. Meanwhile the Linux kernel would have gotten so much better both in code quality and performance when they would have rewritten it in C++.

So far Rust looks like a solution looking for a problem to me. It doesn't bring a new solution to an existing problem. Ada (which is highly regarded as a safe language) has been around for a long time and never gained mainstream traction because it needs a rather elaborate runtime (just like Rust if you read carefully enough).

This feels like the same argument in cyclist circles some years ago when disc brakes were still a debate. Some people insisted that you break the same, that discs weight more, etc etc etc. But nothing really beats how consistent, reliable and powerful they are regardless of weather conditions.
I can ride most routes on a disc brake and a v-brake bike, but a big descent on a rainy day with v-brakes? that would scare the shit out of me. 

Rust is like the disc brakes. You get done the same work you do in C in unsafe, but more complex, intricate stuff that would have you second guessing yourself in C for days it's a breeze in Rust. The value in Rust is not in doing the stuff that will always be unsafe like directly writing to peripheral registers, the power of Rust is in making it easier to implement the complex stuff with confidence.

[nctnico]

AFAIK, the Linux kernel was using only C,

Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/

But tell me how Rust is any better as Rust also supports unsafe programming. And if you look at examples you'll see that you can't really use Rust without unsafe programming. So how is Rust going to stop programmers from cutting corners? It is no better than C or C++ in that respect.

Next thing we'll see is a whole lot of stuff in the Linux kernel using unsafe Rust because A) they can't make it work with safe Rust and B) the programmers think they are like Evil Knievel and keep doing the same coding stunts like you can find in the current Linux kernels. Meanwhile the Linux kernel would have gotten so much better both in code quality and performance when they would have rewritten it in C++.

So far Rust looks like a solution looking for a problem to me. It doesn't bring a new solution to an existing problem. Ada (which is highly regarded as a safe language) has been around for a long time and never gained mainstream traction because it needs a rather elaborate runtime (just like Rust if you read carefully enough).

This feels like the same argument in cyclist circles some years ago when disc brakes were still a debate. Some people insisted that you break the same, that discs weight more, etc etc etc. But nothing really beats how consistent, reliable and powerful they are regardless of weather conditions.
I can ride most routes on a disc brake and a v-brake bike, but a big descent on a rainy day with v-brakes? that would scare the shit out of me. 

Rust is like the disc brakes. You get done the same work you do in C in unsafe, but more complex, intricate stuff that would have you second guessing yourself in C for days it's a breeze in Rust. The value in Rust is not in doing the stuff that will always be unsafe like directly writing to peripheral registers, the power of Rust is in making it easier to implement the complex stuff with confidence.

The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?

[josfemova]

The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?

I mean, Lua and micropython are not even in the same perf neighborhood. Rust is a explicitly designed for Systems Programming, essentially equal perf neighborhood as C and C++

I can see Rust being used to implement the libraries used to data crunching in higher level languages(polars for example), but not as the data cruncher language itself. Test automation eventually, websites and desktop applications is kind of a tricky situation - It's already being used for web servers and it's essentially the dominant language that compiles to wasm, but the front end will keep being dominated by the ECMAScript overlords

[nctnico]

The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?

I mean, Lua and micropython are not even in the same perf neighborhood. Rust is a explicitly designed for Systems Programming, essentially equal perf neighborhood as C and C++

You might be unpleasantly surprised. What Lua and Python are doing is binding building blocks, written in lower level languages, together in a way that the programmer doesn't really need to bother with pointers and memory allocation (and hence resulting in more robust code). Often the building blocks are highly optimised but still easy to unit-test for flaws. So the end result can be faster compared to writing code yourself in Ada, C, C++ or Rust.

[josfemova]

to add some info to the thread, some links to projects/vendors already giving some Rust support apart from Linux

Espressif: https://mabez.dev/blog/posts/esp-rust-24-01-2024/  (Scott Mabin is a direct employee)

WindRiver: https://harmonicss.co.uk/vxworks/using-rust-with-vxworks-7/

Infineon: https://www.infineon.com/cms/en/product/promopages/rust/

Including the language in Zephyr seems to be under discussion.

[Siwastaja]

Rust is like the disc brakes.

Or at least you think it is...

You get done the same work you do in C in unsafe, but more complex, intricate stuff that would have you second guessing yourself in C for days it's a breeze in Rust.

Simplicity and ease of development are quite fresh arguments indeed - what we are used to hear are claims of roughly same complexity code resulting in some extra safety, and it is quite easy to understand why Rust could, at least theoretically, fulfill this claim.

But traditionally complex problems becoming a breeze? This sounds like a marketing speech for AI or something; now such extraordinary claim would most definitely require extraordinary evidence, like a demonstration of a problem which takes days to solve in C, maybe hundreds (thousands?) of lines of code, and which Rust solves in no time. Any example in mind?

[josfemova]

You might be unpleasantly surprised. What Lua and Python are doing is binding building blocks, written in lower level languages, together in a way that the programmer doesn't really need to bother with pointers and memory allocation (and hence resulting in more robust code). Often the building blocks are highly optimized but still easy to unit-test for flaws. So the end result can be faster compared to writing code yourself in Ada, C, C++ or Rust.

I highly doubt that interpreted code running on an embedded virtual machine is going to be faster than say some compiled Rust glue code. Like I can give the benefit of the doubt, perhaps you have some receipts for that claim that I can take a look at? Legit interested.

The one thing that for sure is not better is required space to run the same code. In some platforms space might be irrelevant, but some of us still work with less than a MB of space for code and RAM. Being able to do complex stuff without breaking easy without breaking the memory budget is a nice advantage

[josfemova]

But traditionally complex problems becoming a breeze? This sounds like a marketing speech for AI or something; now such extraordinary claim would most definitely require extraordinary evidence, like a demonstration of a problem which takes days to solve in C, maybe hundreds (thousands?) of lines of code, and which Rust solves in no time. Any example in mind?

Fair criticism. I don't have another receipt apart from personal experience, I used the term "breeze" because that's how it felt being able to do significant changes in a project with confidence when I was using Rust. At a professional level I work with C and usually the roadblocks I find or the stuff that causes the most time wasting is usually something preventable by Rust, all warnings turned on and all.  Could be a nice experiment to benchmark oneself trying to implement some complex project in one language an another with all top level design work done from the start

[abeyer]

Ferrous Systems does some good training workshops on rust in general and embedded specifically. The paid workshops can be a little pricey, but they also post most of the training materials on their GitHub: https://github.com/ferrous-systems

[tggzzz]

The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?

I mean, Lua and micropython are not even in the same perf neighborhood. Rust is a explicitly designed for Systems Programming, essentially equal perf neighborhood as C and C++

You might be unpleasantly surprised. What Lua and Python are doing is binding building blocks, written in lower level languages, together in a way that the programmer doesn't really need to bother with pointers and memory allocation (and hence resulting in more robust code). Often the building blocks are highly optimised but still easy to unit-test for flaws. So the end result can be faster compared to writing code yourself in Ada, C, C++ or Rust.

Your arguing that C is a special case does not stand up to scrutiny.

A much more reasonable position was given thus:

...
Rust is like the disc brakes. You get done the same work you do in C in unsafe, but more complex, intricate stuff that would have you second guessing yourself in C for days it's a breeze in Rust. The value in Rust is not in doing the stuff that will always be unsafe like directly writing to peripheral registers, the power of Rust is in making it easier to implement the complex stuff with confidence.

That's why we have circuit theory to hide EM fields.
That's why we have analogue circuits to hide circuit theory.
That's why we have digital logic gates to hide analogue circuits.
That's why we have RTLs to hide digital logic gates.
That's why we have microcode to hide RTLs.
That's why we have assembler code to hide microcode.
That's why we have C and other languages to hide assembler code.
That's why we have higher level languages to hide ....

C is just one language and abstraction in a continuum.
C is not a particularly good abstraction, since too many lower levels leak through, e.g. aliases, volatile, memory models, parallel processes, interrupts.
We need better.
Better languages and abstractions are already here, but they are not evenly distributed.

[tggzzz]

But traditionally complex problems becoming a breeze? This sounds like a marketing speech for AI or something; now such extraordinary claim would most definitely require extraordinary evidence, like a demonstration of a problem which takes days to solve in C, maybe hundreds (thousands?) of lines of code, and which Rust solves in no time. Any example in mind?

Fair criticism. I don't have another receipt apart from personal experience, I used the term "breeze" because that's how it felt being able to do significant changes in a project with confidence when I was using Rust. At a professional level I work with C and usually the roadblocks I find or the stuff that causes the most time wasting is usually something preventable by Rust, all warnings turned on and all.  Could be a nice experiment to benchmark oneself trying to implement some complex project in one language an another with all top level design work done from the start

The reason I dislike modern C on modern computers is that I prefer to concentrate my attention on my problem, the one I want to solve.

C (worse C++) forces me to concentrate on C; the tool becomes a major part of the problem. That's highly undesirable. Anything that reduces that is to be welcomed with open arms.

[SiliconWizard]

But traditionally complex problems becoming a breeze? This sounds like a marketing speech for AI or something; now such extraordinary claim would most definitely require extraordinary evidence, like a demonstration of a problem which takes days to solve in C, maybe hundreds (thousands?) of lines of code, and which Rust solves in no time. Any example in mind?

Most commonly given "evidence" of that is writing a relatively complex tool using just a few lines of Rust... by using tens (or even hundreds) of 'crates' and just calling a few functions from all that, and calling it a "few-functions program" that does wonders. That is completely disingenuous. All it shows is that Rust has grown a relatively large "ecosystem", which isn't bad per se, but doesn't mean anything more than "it has gotten traction".

And, this excessive reliance on third-party code, which Rust promotes more than almost any other language I've seen (the number of crates a given program is dependent on, from all Rust code tools I've seen so far, is by far the highest I've seen with any other language), may look like a huge benefit, but is also one of the biggest issues in software development there are today, leading to bloat, relying on third-party code nobody has cared to even check, etc.

As soon as one fails to look at the bigger picture, everything looks rosy in the present and sour in hindsight.

[nctnico]

The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?

I mean, Lua and micropython are not even in the same perf neighborhood. Rust is a explicitly designed for Systems Programming, essentially equal perf neighborhood as C and C++

You might be unpleasantly surprised. What Lua and Python are doing is binding building blocks, written in lower level languages, together in a way that the programmer doesn't really need to bother with pointers and memory allocation (and hence resulting in more robust code). Often the building blocks are highly optimised but still easy to unit-test for flaws. So the end result can be faster compared to writing code yourself in Ada, C, C++ or Rust.

Your arguing that C is a special case does not stand up to scrutiny.

I don't follow how I try to argue C is a special case in anything I wrote.  I also don't see why C would be a special case (other than that it still is a dominant language for embedded software development).

[josfemova]

Most commonly given "evidence" of that is writing a relatively complex tool using just a few lines of Rust... by using tens (or even hundreds) of 'crates' and just calling a few functions from all that, and calling it a "few-functions program" that does wonders. That is completely disingenuous. All it shows is that Rust has grown a relatively large "ecosystem", which isn't bad per se, but doesn't mean anything more than "it has gotten traction".

And, this excessive reliance on third-party code, which Rust promotes more than almost any other language I've seen (the number of crates a given program is dependent on, from all Rust code tools I've seen so far, is by far the highest I've seen with any other language), may look like a huge benefit, but is also one of the biggest issues in software development there are today, leading to bloat, relying on third-party code nobody has cared to even check, etc.

As soon as one fails to look at the bigger picture, everything looks rosy in the present and sour in hindsight.

Not really the breeze feeling I was referring to, but you know what,

Being able to manage dependencies so easily that integrating third party code becomes common practice is good actually.

Does not mean people shouldn't audit what they include as dependency, as always, the moment you include a dependency in any language that dependency becomes your responsibility.

I wouldn't consider it as an advantage of C/C++  that dependency management and build systems are so broken that third party code usage is discouraged

[tggzzz]

But traditionally complex problems becoming a breeze? This sounds like a marketing speech for AI or something; now such extraordinary claim would most definitely require extraordinary evidence, like a demonstration of a problem which takes days to solve in C, maybe hundreds (thousands?) of lines of code, and which Rust solves in no time. Any example in mind?

Most commonly given "evidence" of that is writing a relatively complex tool using just a few lines of Rust... by using tens (or even hundreds) of 'crates' and just calling a few functions from all that, and calling it a "few-functions program" that does wonders. That is completely disingenuous. All it shows is that Rust has grown a relatively large "ecosystem", which isn't bad per se, but doesn't mean anything more than "it has gotten traction".

And, this excessive reliance on third-party code, which Rust promotes more than almost any other language I've seen (the number of crates a given program is dependent on, from all Rust code tools I've seen so far, is by far the highest I've seen with any other language), may look like a huge benefit, but is also one of the biggest issues in software development there are today, leading to bloat, relying on third-party code nobody has cared to even check, etc.

As soon as one fails to look at the bigger picture, everything looks rosy in the present and sour in hindsight.

The ability to rapidly easily and predictably merge code from another source with your own is a key way to increase productivity. That enables you to concentrate on the new problem you are being paid to solve. Being able to do so is a very good indicator that a language has a future.

It is also a potential problem, since you have to be assured that the quality of imported code is sound and not malicious.

[uer166]

The ability to rapidly easily and predictably merge code from another source with your own

I wouldn't mind using standard and reliable/consistent code as long as it's easy and well documented. Example: stdlib.h, math.h, etc. I absolutely despise the 99% of github "library" trash out there written as part of "open source". Making it easy to contribute to such code may end up like the Python/pip libraries dumpster fire. Contribution to those libraries has to be very difficult, and usage easy, for it to be a good thing long term.

[JPortici]

Most commonly given "evidence" of that is writing a relatively complex tool using just a few lines of Rust... by using tens (or even hundreds) of 'crates' and just calling a few functions from all that, and calling it a "few-functions program" that does wonders. That is completely disingenuous. All it shows is that Rust has grown a relatively large "ecosystem", which isn't bad per se, but doesn't mean anything more than "it has gotten traction".

And, this excessive reliance on third-party code, which Rust promotes more than almost any other language I've seen (the number of crates a given program is dependent on, from all Rust code tools I've seen so far, is by far the highest I've seen with any other language), may look like a huge benefit, but is also one of the biggest issues in software development there are today, leading to bloat, relying on third-party code nobody has cared to even check, etc.

As soon as one fails to look at the bigger picture, everything looks rosy in the present and sour in hindsight.

Not really the breeze feeling I was referring to, but you know what,

Being able to manage dependencies so easily that integrating third party code becomes common practice is good actually.

Does not mean people shouldn't audit what they include as dependency, as always, the moment you include a dependency in any language that dependency becomes your responsibility.

I wouldn't consider it as an advantage of C/C++  that dependency management and build systems are so broken that third party code usage is discouraged

then you have what? some firmware or application that you can't build because it depends on a specific version of a specific crate (maybe because some other crate require this crate) as in later versions some apis were changed, or it doesn't work anymore because some functionality was changed.. like on linux in which you sometimes have to have several versions of libsomething installed because application A require one, application B require another, application C require yet another



what i really want is C (syntax). With classes of course. With possibly little pain in dealing with pointers, or in alternative a compiler smart enough to optimize away all the sugar coating and intermediate "safe" types when i need to pass references because i need to treat type X as bytes for whatever reason (encryption, checksums, serialization). Lambdas too.
And of course with a compiler that support my architectures of choice, because otherwise what's the point of everything?
C++ does it, but i don't have the compiler for my targets (you CAN write easy to understand C++, you are not mandated to use all the obscure expressions that were added later)
Is Rust going to do it?

[Siwastaja]

Fair criticism. I don't have another receipt apart from personal experience, I used the term "breeze" because that's how it felt being able to do significant changes in a project with confidence when I was using Rust. At a professional level I work with C and usually the roadblocks I find or the stuff that causes the most time wasting is usually something preventable by Rust, all warnings turned on and all.  Could be a nice experiment to benchmark oneself trying to implement some complex project in one language an another with all top level design work done from the start

Could you elaborate a bit, because I have really no idea what you are talking about. Which kind of roadblocks and how they would be avoided?

[Siwastaja]

Most commonly given "evidence" of that is writing a relatively complex tool using just a few lines of Rust... by using tens (or even hundreds) of 'crates' and just calling a few functions from all that, and calling it a "few-functions program" that does wonders. That is completely disingenuous. All it shows is that Rust has grown a relatively large "ecosystem", which isn't bad per se, but doesn't mean anything more than "it has gotten traction".

And, this excessive reliance on third-party code, which Rust promotes more than almost any other language I've seen (the number of crates a given program is dependent on, from all Rust code tools I've seen so far, is by far the highest I've seen with any other language), may look like a huge benefit, but is also one of the biggest issues in software development there are today, leading to bloat, relying on third-party code nobody has cared to even check, etc.

As soon as one fails to look at the bigger picture, everything looks rosy in the present and sour in hindsight.

I was thinking maybe josfemova meant the absolute classic "X is easy to do by calling an external implementation which does X, therefore language which calls X is simple to use". Which of course works with any language which can call external implementations, including C or even assembly.

But I wanted to give josfemova benefit of doubt, maybe they mean some feature of the language itself. But apparently no. What a joke.

Anyway thanks for the explanation, so this makes Rust a total and utter joke, it's a no-go. You might be able to use it if you went against the flow and avoid the "ease" of importing work by others, but if it encourages bringing in "easy" libraries then that scares the shit out of me. As the xz security disaster demonstrated, we already have too much dependence on library code. Even the sshd folks had no resources to follow the dependency chains sshd->libsystemd->libxz to find the backdoor.

This "easy" library bloat programming might be all fine for userland applications on general purpose computers, e.g. desktop applications and games, as it widens the pool of available programmers and reduces time-to-market, but no-go on embedded, OS kernel and security critical core tools even if on userland.

So Rust is clearly new Python, "oh look how easily I can do this and this and that" (by calling an existing implementation which does it all for me, written in C). Or Arduino, "look how easy it is to buy ready-made hardware and software and press a button".

But someone has to do those implementations, and this is called embedded engineering. Clearly Rust has no and will have no place in it.

Working in a field where we have firmware part, backend part and UI part, pretty much everything else is a moving target except the firmware. Everything else requires maintenance when third party code changes. The firmware is the only one which just keeps working. Amount of external code is minimized and that is brought in as source code and compiled in, so that it can be modified and bugs fixed. The last thing I want to bring the same uncertainty into firmware.

Rust is bait&switch. The claims are about memory safety and better handling of low-level hardware stuff in general, or "embedded C replacement". The lure part is, seemingly, ease of development for young players by using existing code. The result is opposite of safe low level language; just another new general-purpose easy-to-use new language, like Java or Python, which beginners will tout all over the Internets.

[JPortici]

Most commonly given "evidence" of that is writing a relatively complex tool using just a few lines of Rust... by using tens (or even hundreds) of 'crates' and just calling a few functions from all that, and calling it a "few-functions program" that does wonders. That is completely disingenuous. All it shows is that Rust has grown a relatively large "ecosystem", which isn't bad per se, but doesn't mean anything more than "it has gotten traction".

And, this excessive reliance on third-party code, which Rust promotes more than almost any other language I've seen (the number of crates a given program is dependent on, from all Rust code tools I've seen so far, is by far the highest I've seen with any other language), may look like a huge benefit, but is also one of the biggest issues in software development there are today, leading to bloat, relying on third-party code nobody has cared to even check, etc.

As soon as one fails to look at the bigger picture, everything looks rosy in the present and sour in hindsight.

I was thinking maybe josfemova meant the absolute classic "X is easy to do by calling an external implementation which does X, therefore language which calls X is simple to use". Which of course works with any language which can call external implementations, including C or even assembly.

But I wanted to give josfemova benefit of doubt, maybe they mean some feature of the language itself. But apparently no. What a joke.

Anyway thanks for the explanation, so this makes Rust a total and utter joke, it's a no-go. You might be able to use it if you went against the flow and avoid the "ease" of importing work by others, but if it encourages bringing in "easy" libraries then that scares the shit out of me. As the xz security disaster demonstrated, we already have too much dependence on library code. Even the sshd folks had no resources to follow the dependency chains sshd->libsystemd->libxz to find the backdoor.

This "easy" library bloat programming might be all fine for userland applications on general purpose computers, e.g. desktop applications and games, as it widens the pool of available programmers and reduces time-to-market, but no-go on embedded, OS kernel and security critical core tools even if on userland.

So Rust is clearly new Python, "oh look how easily I can do this and this and that" (by calling an existing implementation which does it all for me, written in C). Or Arduino, "look how easy it is to buy ready-made hardware and software and press a button".

But someone has to do those implementations, and this is called embedded engineering. Clearly Rust has no and will have no place in it.

Working in a field where we have firmware part, backend part and UI part, pretty much everything else is a moving target except the firmware. Everything else requires maintenance when third party code changes. The firmware is the only one which just keeps working. Amount of external code is minimized and that is brought in as source code and compiled in, so that it can be modified and bugs fixed. The last thing I want to bring the same uncertainty into firmware.

Rust is bait&switch. The claims are about memory safety and better handling of low-level hardware stuff in general, or "embedded C replacement". The lure part is, seemingly, ease of development for young players by using existing code. The result is opposite of safe low level language; just another new general-purpose easy-to-use new language, like Java or Python, which beginners will tout all over the Internets.

I agree with every single statement above (because my work experience is the same as the bolded sentence. Heck i just had to update an App that works 100% of the time because the last update was too long ago - six months - and google was threatening to close the developer account due to inactivity. No, it's just working fine you damn fools.)
But as i also mentioned above i am open to a new(er) language that offers improvements on the syntax (mainly classes, public/private, and lambdas) and that doesn't need to be C++

[tggzzz]

The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?

I mean, Lua and micropython are not even in the same perf neighborhood. Rust is a explicitly designed for Systems Programming, essentially equal perf neighborhood as C and C++

You might be unpleasantly surprised. What Lua and Python are doing is binding building blocks, written in lower level languages, together in a way that the programmer doesn't really need to bother with pointers and memory allocation (and hence resulting in more robust code). Often the building blocks are highly optimised but still easy to unit-test for flaws. So the end result can be faster compared to writing code yourself in Ada, C, C++ or Rust.

Your arguing that C is a special case does not stand up to scrutiny.

I don't follow how I try to argue C is a special case in anything I wrote.  I also don't see why C would be a special case (other than that it still is a dominant language for embedded software development).

On re-reading it, I have to agree with you. My apologies.

[nctnico]

But as i also mentioned above i am open to a new(er) language that offers improvements on the syntax (mainly classes, public/private, and lambdas) and that doesn't need to be C++

Same here but I think that C++ is a good choice for low-level embedded work as it doesn't require a whole lot of learning and allows to program without pointers.

OTOH it is also good to make a seperation between low-level code which needs to do time critical things / watch over resource usage versus code which does I/O, high level functions and user interaction. The last decade I have been using a mix of C/C++ code and Lua or Python. This mix works really well if you have the space as Lua and Python make it easy to implement the code which drives the high level functions and deals with data.

For a project where the hardware was already choosen it is a big chore to deal with JSON formatted data as C doesn't really have ways to deal with key/value pairs like Python does. So doing all the JSON related data handling in a constrained space is a major PITA. Hundreds of lines of C code would only take a few lines of Python code (to pack / unpack a variable to / from JSON).

[tggzzz]

But as i also mentioned above i am open to a new(er) language that offers improvements on the syntax (mainly classes, public/private, and lambdas) and that doesn't need to be C++

Same here but I think that C++ is a good choice for low-level embedded work as it doesn't require a whole lot of learning and allows to program without pointers.

Pointers, per se, aren't a big problem. Using them in a way which allows uncontrolled aliasing can be problematic.

If you think C++ doesn't require a lot of learning, have you read and understood all of the FQA? https://yosefk.com/c++fqa/index.html You are permitted to take some time off for laughing and/or shaking your head in disbelief, and/or vomiting.

Don't forget that the C++ language designers (who damn well ought to be more proficient than thee and me!) refused to believe the consequences of their creation until their noses were rubbed in it by a simple demonstration. In particular, the C++ language designers refused to believe that compilation of some correct and valid C++ programs must never terminate.

Given that, i'm dubious that anybody can understand C++.

OTOH it is also good to make a seperation between low-level code which needs to do time critical things / watch over resource usage versus code which does I/O, high level functions and user interaction. The last decade I have been using a mix of C/C++ code and Lua or Python. This mix works really well if you have the space as Lua and Python make it easy to implement the code which drives the high level functions and deals with data.

For a project where the hardware was already choosen it is a big chore to deal with JSON formatted data as C doesn't really have ways to deal with key/value pairs like Python does. So doing all the JSON related data handling in a constrained space is a major PITA. Hundreds of lines of C code would only take a few lines of Python code (to pack / unpack a variable to / from JSON).

Yup, although I would probably make slightly different choices.

Using a tool (language) that is appropriate for the problem (application domain concepts) is a central part of engineering a solution. Anybody (and there are some!) who thinks one language is appropriate for all purposes is a twat.

[josfemova]

But I wanted to give josfemova benefit of doubt, maybe they mean some feature of the language itself. But apparently no. What a joke.

Haha, don't be dishonest, you had a multi-paragraph rant already at the tip of your tongue and wanted an excuse so much that you ignored the part in which I explicitly point out that is not the ease of integrating third party code what makes Rust enjoyable for me. I do think it's nice the build system is nor utter shit, if you want to spin that as a negative you are free to do I guess. A curious thing to point out is that most equipment hacks listed in the forum work because of some broken completely in-house fw implementation. Not using third party code has security-related disadvantages too, DEF CON attendees particularly enjoy this fact.

Everyone else is free to press the comically large "doubt" button, quite frankly I think you should just try the language, probably an embassy application with an esp32 and get done with it, decide if the language is your thing or not

Some food for thought:
- Why the first compiler version to go trough certification (Ferrocene 23.06) got the ASIL D qualification?
- Why did Linux accept it and not other languages that came before it?
- Why are some embedded sw industry players starting to get more involved in it?
- Why did TU delft decide to use Rust for the masters programme? (https://cese.pages.ewi.tudelft.nl/)
- Why have big industry players decided to rewrite in rust security critical services? (AWS services, MS Azure and Windows Kernel parts to give some examples)

Lack of adoption in embedded is a quirk of the same industry where using C89 is not a fringe position. Interest drives vendor support, and interest moves slowly in Embedded. If you are like 2 decades away from retirement and not in a management position for big corp you can probably ignore Rust and stay comfy.

Also, I'm not telling the C wizards that they cannot be as proficient in C as they would be in Rust, that's like telling a LatAm granny that she should use an axe to take down trees when she is clearly more proficient with a machete. Practice makes perfect and it's reasonable to think that for some people and uses cases there are diminishing returns when switching Rust

[Siwastaja]

- Why did TU delft decide to use Rust for the masters programme? (https://cese.pages.ewi.tudelft.nl/)

This I find hilarious. The university I attended coined their own language, called C--, for their master's programme, a few years after I finished the courses (which taught C++). Yet, I'm not using that as an argument for using C--. It was total crap. Universities notoriously use any random language for teaching, and C-- probably was one of the worst.

MS Azure is a good anti-reference to me, too.

It's also interesting to get a "certification" before even having a standard.

I totally agree with you with the shitty state of the usual build systems. The fact we have cmake, and gazillion of lines of random build scripts that allow people to build backdoors that inject malicious binary stuff into sources during compile time without anybody noticing is very alarming.

In embedded MCU projects, I don't have that problem. I use plain old makefiles and refuse to use crap like cmake. Or MS Azure.

[bson]

Well, Rust does provide in the experimental nightly builds the most essential component of system programming: custom allocators.  But much of std still doesn't permit use of arbitrary allocators.  The reason this is essential is of course that a huge number of system software designs start with the question of how to manage buffers and data to minimize the number of copies or other passes over it.  Whether it's freelisting/pooling, thread-specific allocation zones, stack-only allocation (maybe for just some contextual data) - or just a plain global heap with a global lock (which is often fine for many uses).  Add secondary considerations like cache coloring, data migration between threads (and hence likely caches), suitability for DMA, etc, and it's clear that data allocation strategies is often the first design consideration for things like drivers for mass storage, networking, USB, Wifi.  Even file systems. Often the drivers are layered (for example protocols and media for Wifi) and it's important not to introduce extra copies in layer transitions.  This means while a driver author has to consider allocation strategies, for many buffer types and flows this is already mandated on a system level.  Performance may not be everything, but if excess data copies drop performance of a 10gbe interface to 1gbe or less, you'll get laughed out of town.  (And I've seen exactly this happen in naive implementations.)  So Rust libraries generally delegating allocation is a good start, but they also need to be efficiently implementable in Rust unless half your code is going to be in C, to provide a runtime foundation.

[SiliconWizard]

Anyway thanks for the explanation, so this makes Rust a total and utter joke, it's a no-go. You might be able to use it if you went against the flow and avoid the "ease" of importing work by others, but if it encourages bringing in "easy" libraries then that scares the shit out of me. As the xz security disaster demonstrated, we already have too much dependence on library code. Even the sshd folks had no resources to follow the dependency chains sshd->libsystemd->libxz to find the backdoor.

Illustration from just a couple days ago: https://www.cve.org/CVERecord?id=CVE-2024-24576

[Marco]

Java or Python, which beginners will tout all over the Internets.

It's more the Haskell of current year, the kind of hobbyists/students these languages attract are not really well described by beginners and they don't spend much time evangelising either.

The evangelism comes from companies and people who like to troll a little and who see blood in the water and very baitable victims (also slightly deserving).

[uer166]

Anyway thanks for the explanation, so this makes Rust a total and utter joke, it's a no-go. You might be able to use it if you went against the flow and avoid the "ease" of importing work by others, but if it encourages bringing in "easy" libraries then that scares the shit out of me. As the xz security disaster demonstrated, we already have too much dependence on library code. Even the sshd folks had no resources to follow the dependency chains sshd->libsystemd->libxz to find the backdoor.

Illustration from just a couple days ago: https://www.cve.org/CVERecord?id=CVE-2024-24576

To be fair here the 10/10 rating is a total joke. This isn't really a "vulnerability", and while I am skeptical of Rust, this CVE is overhyped. This same "vulnerability" exists in C and C++.

[ejeffrey]

The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?

Of course Rust isn't going to replace high level languages.  It's a low level language.  It does not even attempt to compete with any version of Python or lua, any more than C and C++ are.  The goal is to be a low level language with similar domain to C++ with safety features, safer defaults, and a simpler language.  Whether it can succeed in replacing those to a significant extent I don't know, but comparing it to Python makes no sense.

[hans]

But traditionally complex problems becoming a breeze? This sounds like a marketing speech for AI or something; now such extraordinary claim would most definitely require extraordinary evidence, like a demonstration of a problem which takes days to solve in C, maybe hundreds (thousands?) of lines of code, and which Rust solves in no time. Any example in mind?

Most commonly given "evidence" of that is writing a relatively complex tool using just a few lines of Rust... by using tens (or even hundreds) of 'crates' and just calling a few functions from all that, and calling it a "few-functions program" that does wonders. That is completely disingenuous. All it shows is that Rust has grown a relatively large "ecosystem", which isn't bad per se, but doesn't mean anything more than "it has gotten traction".

And, this excessive reliance on third-party code, which Rust promotes more than almost any other language I've seen (the number of crates a given program is dependent on, from all Rust code tools I've seen so far, is by far the highest I've seen with any other language), may look like a huge benefit, but is also one of the biggest issues in software development there are today, leading to bloat, relying on third-party code nobody has cared to even check, etc.

As soon as one fails to look at the bigger picture, everything looks rosy in the present and sour in hindsight.

I kind of agree. This is why I dislike environments like NodeJS, because there a billion packages for even the most basic things like: https://www.npmjs.com/package/is-even
163k downloads per week. Just imagine what a bad actor can do.. if the author decides to push malware (which has happened before), then it has reached 100 end-users in about 6 minutes, and probably a few thousand before it finally gets removed. Now, malware is probably not even the biggest concern for an embedded system..

Libraries that (suddenly) do wacky things to create binary bloat, memory issues, timing issues or straight up hardfaults. Those won't be removed within hours and suddenly you'll have to cope with it.  I rather not prefer that if I need to create a reliable & traceable build system with dependency pulls. Especially as many firmware images will have a relatively strict feature-freeze.

However, this has nothing to do with Rust and all with cargo (similar NodeJs vs any ECMAscript flavour). How many bare metal programmers do we have here to skip every HAL library and tailor middleware (RTOS and protocol stacks) to their own minimum needs? Probably quite a few. There is nothing stopping you from doing the same with Rust. This can be similar to using libraries like Boost etc. in C++: yes you could, but on an embedded device, I only want source code going into my end images if possible. And here I think benefits from modern languages far outweigh the awful C language standard.

[woofy]

C has variables, Rust has variables.
In C I can vary my variables, that's why they are called variables.
In Rust I can't. Variables are fixed when you declare them. Making variables variable is clearly a bit of a dog because you have to put "mut" if front of the name.
Oh, and a kickback to 1970's BASIC, you have to put "let" in front of that.
So Rust variables are more like constants, except they aren't. Rust has constants too and they are not the same as variables, mutable or not.
Lovely stuff. :-)

[SiliconWizard]

If you want some rationale about all this, you can read that: https://langdev.stackexchange.com/questions/3187/why-do-some-languages-have-both-immutable-variables-and-constants
Be aware that you may end up feeling more confused (either that, or histerically laughing, depends on your mood), after reading it than before. So use this at your own risk.

You can also read this short description for the Cairo language, another one: https://book.cairo-lang.org/ch02-01-variables-and-mutability.html
It oddly looks suspiciously similar to the official Rust page: https://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html - but they say Cairo is "Rust-inspired", so, yeah. It is.

Here's also some notes about the differences between "const" and "immutable" in JavaScript: https://stackoverflow.com/questions/42833540/keyword-const-does-not-make-the-value-immutable-what-does-it-mean
This blog article tries to figure it out: https://www.joshwcomeau.com/javascript/the-const-deception/

This page on immutable constants in Elm is also nice: https://elmprogramming.com/immutability.html

Finally, for some (more?) fun, here is a parody. A good laugh is good for your health, at least I think so: https://github.com/TodePond/DreamBerd
(I think I already posted it a while ago, but it's kinda fun.)

[Perkele]

To be fair here the 10/10 rating is a total joke. This isn't really a "vulnerability", and while I am skeptical of Rust, this CVE is overhyped. This same "vulnerability" exists in C and C++.

It's a simple parsing error. It's a common bug that will never be eradicated by any programming language.
The reason is code based on assumptions, and a lack of proper testing.
Rust is still a young language, and operating systems are weird.
Expect more of these kinds of bugs.

[woofy]

Finally, for some (more?) fun, here is a parody. A good laugh is good for your health, at least I think so: https://github.com/TodePond/DreamBerd
(I think I already posted it a while ago, but it's kinda fun.)

Wonderful stuff,  I hadn't seen that before. 

[Marco]

It's a simple parsing error. It's a common bug that will never be eradicated by any programming language.

The fundamental problem is using a text API with foreign input, it's a huge security anti-pattern. Text APIs should only be for interactive/static use, everything else should be "compiled" and only accept string parameters with length, not null or white space terminated. SQL, shell, HTML, XML, format strings (printf). All never ending sources of exploits.

If you have to concat and escape, you will screw up in an easily exploited way. It's inevitable and frequent.

[nctnico]

It's a simple parsing error. It's a common bug that will never be eradicated by any programming language.

The fundamental problem is using a text API with foreign input, it's a huge security anti-pattern. Text APIs should only be for interactive/static use, everything else should be "compiled" and only accept string parameters with length, not null or white space terminated. SQL, shell, HTML, XML, format strings (printf). All never ending sources of exploits.

The problem is in sloppy programming. But it isn't limited to text. With binary data you can also have a variable length. In my software every function which works on variable length data, also receives the size of the buffer/array which receives the data AND checks whether the amount written into a buffer/array isn't exceeding the length. This has been hugely benificial to keep any problems localised, programs fail in a predictable way and thus make a bug easy to locate.

[janoc]

I wonder how many of you have actually tried to use Rust for embedded? I did, for ARM (STM32F1 & F4 series) because I liked the idea of built-in coroutines/async.

TL;DR - it is not mature enough.

But probably not because of what you think. The language itself is fine even though the extremely noisy syntax is an acquired taste and the constant battle with and having to bend over backwards at design stage to make the borrow checker happy feels wrong. When the tool dictates architecture or you will never get it to compile it is a problem. But I digress.  The documentation is also mostly OK and I am not missing vendor tooling - that one is almost universally crap. Give me vendor-independent compilers and tools any day.

The real problem embedded Rust is the ecosystem. Even for "desktop" Rust this is a problem, for embedded it is a complete showstopper. For languages like C, C++ or Python you are going to find millions of tools, libraries, etc. For Rust? Maybe one or two libraries solving the problem you need solved. For embedded it is even worse because Rust is a niche language - and embedded Rust is an even smaller niche within the niche.

The catch? They are mostly one-man projects, often last updated several years ago and not touched since because the author has lost interest and/or moved on to something else. So they don't work with the current compiler or require obsolete dependencies or (in the case of embedded Rust) don't work without the standard library or don't support the MCU you need to use it with ... In the best case, they are half-finished - and you discover that only after spending  hours trying to make some unimplemented feature work.

So unless you have nothing better to do with your time or are writing everything from scratch, including USB stacks and RTOSes as a matter of course, this is really not the tool you are looking for.

I am sure Rust fanboys will jump at me now with "But you can just use X!!!!", "But look at Y!!!", "But safety!" - but that's completely irrelevant. If the tool isn't solving my use case it is not the tool for the job. I need to get work done, I am not messing with it for fun or because I like this language over that one.

BTW, re code safety in Rust - that you have a borrow checker doesn't mean you won't crash your MCU or destroy your data. It merely prevents one class of bugs that other languages, even C, can avoid too, even though the developer needs to do more work and be more diligent in order to not shoot themselves in the foot. This Rust feature is likely one of the most overblown and misunderstood language features in history.

I am keeping an eye on Rust and periodically check on projects like https://embassy.dev/ hoping that things get better supported but I am still writing most of my code in C, C++ and Python instead.

[Marco]

also receives the size of the buffer which receives the data.

Yet that is precisely what is not possible with text based interfaces. They will always rely on in band special characters and people will always keep screwing that up in easily exploited ways.

[tggzzz]

The language itself is fine even though the extremely noisy syntax is an acquired taste and the constant battle with and having to bend over backwards at design stage to make the borrow checker happy feels wrong. When the tool dictates architecture or you will never get it to compile it is a problem.

Isn't that the wrong way round?

The consequences of aliasing plus modern multicore/processors plus cache/NUMA architectures makes the "ownership" of a piece of data a key design choice. That choice is enforced by the language.

There is an equivalent constraint with xC, and it solves it by forbidding aliasing.

[nctnico]

also receives the size of the buffer which receives the data.

Yet that is precisely what is not possible with text based interfaces. They will always rely on in band special characters and people will always keep screwing that up in easily exploited ways.

The same is true for any kind of variable length data. You'll need some kind of delimiter one way or another and verification whether the length matches the delimiter. So either way you need to do sanity checks. But these are relatively easy to implement for as long as you use the length of the local buffer as a safeguard against processing 'bad' data.

[josfemova]

I am sure Rust fanboys will jump at me now with "But you can just use X!!!!", "But look at Y!!!", "But safety!" - but that's completely irrelevant. If the tool isn't solving my use case it is not the tool for the job. I need to get work done, I am not messing with it for fun or because I like this language over that one.

As the proverbial fanboy on this thread I'm sorry, I have to jump at you now, I'm don't have a choice, they have my family at gun point.
Being a little bit more serious, your criticism is actually one of the few that's actually fair. The ecosystem is not mature enough and as you point out there are use cases in which there are diminishing returns or limited benefits once you compare what you get vs what you loose. At the moment, for serious, complex projects that need to run on the metal you are better served by something like Zephyr and for botching Arduino/Python is all you need. Then again, some serious projects do use Rust but as you pointed out, they are owners of almost all components in their codebase (I'm talking about Oxide Computer here)

BTW, re code safety in Rust - that you have a borrow checker doesn't mean you won't crash your MCU or destroy your data. It merely prevents one class of bugs that other languages, even C, can avoid too, even though the developer needs to do more work and be more diligent in order to not shoot themselves in the foot. This Rust feature is likely one of the most overblown and misunderstood language features in history.

Agree. I think I like the Borrow Checker during the design/PoC phase because it forces some questions that might get you bit in the ass if you either ignore them or try to botch them, but the borrow checker is not a silver bullet and you can still have undesirable behavior in a Rust program that is not considered unsafe (e.g. deadlocking is safe) more info https://doc.rust-lang.org/reference/behavior-not-considered-unsafe.html

I am keeping an eye on Rust and periodically check on projects like https://embassy.dev/ hoping that things get better supported but I am still writing most of my code in C, C++ and Python instead.

I'm currently revisiting this and the ecosystem in general. It's getting better and the embedded-hal/embedded-io changes make writing stuff less cumbersome. I have some STMs at hand but ESP32s seem the way to go as they are the only ones with official vendor support, luckily I also have a bunch of them. Easy async programming in embedded it's very attractive for many use cases, especially for IoT devices that must be responsive. Still not as easy as opening circuitpython for a botch tho'

[Marco]

The same is true for any kind of variable length data.

Only when out of band communication is impossible. Mostly compression formats and wire protocols by necessity and text interfaces by convenience (strictly speaking it's still possible to include lengths, but then it's not really human editable any more). Also null ended strings by stupidity. The moment OoB communication is possible you can just include the length.

For humans it's provably not easy to get escaping right ... injection is right up there with memory related bugs as a cause for exploits.

[SiliconWizard]

It's a simple parsing error. It's a common bug that will never be eradicated by any programming language.

The fundamental problem is using a text API with foreign input, it's a huge security anti-pattern. Text APIs should only be for interactive/static use, everything else should be "compiled" and only accept string parameters with length, not null or white space terminated. SQL, shell, HTML, XML, format strings (printf). All never ending sources of exploits.

The problem is in sloppy programming. But it isn't limited to text. With binary data you can also have a variable length. In my software every function which works on variable length data, also receives the size of the buffer/array which receives the data AND checks whether the amount written into a buffer/array isn't exceeding the length. This has been hugely benificial to keep any problems localised, programs fail in a predictable way and thus make a bug easy to locate.

This is down to input validation more generally speaking (lack thereof), and the number 1 issue in software IMO. *This*, to me, should be absolute priority to make things more robust and more secure, and apart from Ada / Spark and very, very few languages that have integrated the concept of "contracts", I don't see anything much done to help with that, and so it's going to come and bite us, over, over and over again, be it with Rust or Dreamberd.

[Marco]

This is down to input validation more generally speaking (lack thereof), and the number 1 issue in software IMO. *This*, to me, should be absolute priority to make things more robust and more secure, and apart from Ada / Spark and very, very few languages that have integrated the concept of "contracts", I don't see anything much done to help with that, and so it's going to come and bite us, over, over and over again, be it with Rust or Dreamberd.

Escaping/de-escaping across multiple text formats and program stages is not as trivial as people pretend ... it won't even be immediately obvious what and how to validate/sanitize at any given point in the program.

The way we use text makes the program too hard to reason about ... so don't use text like that. SQL is wrong. HTML is wrong. XML is wrong. Printf is wrong ... and in this case cmd is wrong. Parameters should be passed in as an array of strings with length, no character in those strings should be able to cause an injection exploit by spreading to a different command than intended.

Almost all code should take strings+length from top to bottom.

PS. practically that means that editors should add length automagically to colour coded parameter strings for a safe version of HTML/XML (no more need for base64, that alone would easily be worth it looking like garbage in Vi, human readability of the lowest level representation in plain text is ridiculously overvalued). SQL/cmd, where you can with relative ease call them as a function, can in theory suffice to just have the interpreter only take strings+length as external parameters and leave making sure they can't leak to the interpreter.

You will have to beat web programmers around the head a lot for them to stop just concatenating SQL themselves, three decades of SQL injection hasn't managed.