About Rust in embedded

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