3 ms·

Embedded dev here too. I worked mostly on bigger (processing power-wise) systems. Actually as big embedded as you can find (PC-level performance), I toy with sm

by dpc_pw 10y ago

Embedded dev here too. I worked mostly on bigger (processing power-wise) systems. Actually as big embedded as you can find (PC-level performance), I toy with smaller ones as a hobby. :) 1. That is kind of true but only in tiny systems. Having some lists (with proven bounded size etc.) is still often necessary, where pointer invalidation is a problem. But even tiny embedded systems will grow in processing power, get SMP etc. - it's just a matter of time. And there is way more that Rust has to offer. 2. Rust is not functional programming language. Rust allows to write parts of the code in functional fashion and the resulting code is very efficient (because it's functional and can be optimized well), so you can employ it when needed. The thing is: C does not support functional programming well, so you write code imperative way. But imperative ways are neither inherently faster, nor easier. In many cases functional style code is both easier to understand and generates better code. Sometimes because it's easier to understand the code, you can spent more time optimizing the performance, instead of fixing bugs. 3. Actually after couple of years writing Rust code, I can predict the asm generated by `rustc` almost as well as C compilers. Abstractions provided by rust map very directly to CPU instructions. Also, there have been numerous times when working on C code, I had to give up on optimal runtime performance because lack of C expressiveness, safety and sanity concerns. Rust static dispatch through generic traits, combined with optimizer and LTO does wonders, really. People just need to overcome the bias that abstractions are costly. 4. GC in Rust is going to be optional and "manual". Just like `Vec` does dynamic allocations, and you can just not use it. The "functionality working after twenty years" is IMO a wishful thinking. Real C code is ridden with bugs, especially undefined behaviors dependencies, that after 20 years compilers tend to expose rather easily as they got better at (ab)using them. UB is actually my biggest problem with C and C++. I have been working with very smart people, following all the standards, using static analysis, carefully testing and reviewing and we still were hit quite often with C-quirkiness and UB. It's common in embedded to pin the version of the toolchain for the precisely that reason: changing a toolchain version can expose new bugs in your code (not to mention bugs in the compiler, but that's another story). Also, the building system: good luck running `make` (or something like it) on a project from 20-years ago. > Remember, this kind of code is keeping all the infrastructure we all rely on working. A lot of human suffering had to been thrown at the problem to make C code do the job there, and countless list of bugs in critical widely-deployed software tells much about how well it worked. It is sooo relieving, when you don't have to debug weird bugs due to UB, data races, pointer invalidation, memory allocations bugs, and you can actually express your code in a way that is both fast and impossible to mis-use. However I agree that Rust is, from serious embedded work perspective, completely immature. 5. Agreed. Not to mention that in some application the compiler (and all toolchain elements), as well as the compiled software needs to be certified. Good luck building a certified Rust compiler. :) 6. That is true. Rust is way more complex, and many people does their job well using tools they know, goes home and have better things to do then learn new programming languages. IMO. Rust won't overtake neither C, nor C++ places any time soon (let's say 20 years), but for some applications and some people is going to be very valuable proposition. There are some things that C just completely sucks at: it's ridden with UB instanity, lack of expressiveness, worse performance (yes, I really believe C performance is going to be worse than Rust one due to aliasing and static dispatch), lack of integrated building system (yay cargo!) which to this day makes it really hard to reuse code. As micro-controllers become more and more powerful (SMP!) and bigger-embedded systems more popular, Rust might be gaining some traction.

seren 10y ago
I am also an embedded dev, and I agree heartily with your post. Something that Rust is bringing is sane and safe default. That does not look like a big deal, because you can write C and C++ "the right way". But in the real world, it does not always work like that. My team has inherited a 1M LoC real time application that is been moved around and developed by different team of subcontractors in the last ten years. It has devolved in a bug ridden mess (hence the need to bring it back in house). Rust would not have been a silver bullet but there is a whole class of error that would not have happened, and would have been forbidden in the first place. The subcontractors were supposed to use a static analyzer but we got the code back we had to fix 5000 defects of the worst kind (buffer overflows, dereferencing null pointer, memory leaks and so on) For me, the value proposition of Rust is that it is roughly equivalent to C + a good static analyzer, but it is for free, and you are sure the checks are in place and have been executed. In my mind it is pretty clear that in the next 20 years, C is going to be replace by something safer in the embedded world. It might be Rust, it might be something else.
S_I 10y ago
Also a reply to serene (one post below). Before i reply, i would like to make two point clear. First, i'm not going to argue about performance, because i've used Rust for personal projects, i can say that it is really (like REALLY) efficient. Performance is great, no discussion. And two, as said, i've used it and like it. But honestly, the best thing about it (IMO) are the error messages. So... 1.Agreed. I'm just skeptical if i will see the day that those new processors will be as energy efficient as a 8051. Power consumption will always be an issue. 2.Well yes and no, at least that is my (maybe false) impression.As you say, if you want to be really efficient with Rust, you really should program functional as much as you possibly can. So is it functional or not? My impression is that it most of the time does not know what it wants to be. 3.Agreed and motivational to hear that it just takes some time (i'm still not that good with predicting the outcome). 4."Just like `Vec` does dynamic allocations, and you can just not use it." This, right there. The "and you can just not use it". This is what the C++ camp is saying, so the Rust community could end like the C++ community, where everyone is using another dialect.But that's just my personal grief.Anyhow, yes UB is maybe THE biggest problem. I've mentioned CompCert above, so if you are interested see http://compcert.inria.fr/man/manual004.html http://compcert.inria.fr/man/manual004.html. Regarding "A lot of human suffering had to been thrown at the problem to make C code do the job there", yes i agree. But now it (mostly) works, and nobody wants to risk anything and touch that code base, let alone rewrite. 5.Agreed. 6.My experience is not even that my peers have better things to do or do not want to try. I think it's matter of taste. People are different and prefer different things. To seren: "Rust would not have been a silver bullet but there is a whole class of error that would not have happened, and would have been forbidden in the first place. The subcontractors were supposed to use a static analyzer but we got the code back we had to fix 5000 defects of the worst kinds (buffer overflows, dereferencing null pointer, memory leaks and so on) For me, the value proposition of Rust is that it is roughly equivalent to C + a good static analyzer, but it is for free, and you are sure the checks are in place and have been executed." What makes you think that those people wouldn't have used "unsafe" everywhere, just because it makes their job easier?You would have ended up with the same mess.

by dpc_pw 10y ago

seren 10y ago

I am also an embedded dev, and I agree heartily with your post. Something that Rust is bringing is sane and safe default. That does not look like a big deal, because you can write C and C++ "the right way". But in the real world, it does not always work like that. My team has inherited a 1M LoC real time application that is been moved around and developed by different team of subcontractors in the last ten years. It has devolved in a bug ridden mess (hence the need to bring it back in house). Rust would not have been a silver bullet but there is a whole class of error that would not have happened, and would have been forbidden in the first place. The subcontractors were supposed to use a static analyzer but we got the code back we had to fix 5000 defects of the worst kind (buffer overflows, dereferencing null pointer, memory leaks and so on) For me, the value proposition of Rust is that it is roughly equivalent to C + a good static analyzer, but it is for free, and you are sure the checks are in place and have been executed. In my mind it is pretty clear that in the next 20 years, C is going to be replace by something safer in the embedded world. It might be Rust, it might be something else.

S_I 10y ago

Also a reply to serene (one post below). Before i reply, i would like to make two point clear. First, i'm not going to argue about performance, because i've used Rust for personal projects, i can say that it is really (like REALLY) efficient. Performance is great, no discussion. And two, as said, i've used it and like it. But honestly, the best thing about it (IMO) are the error messages. So... 1.Agreed. I'm just skeptical if i will see the day that those new processors will be as energy efficient as a 8051. Power consumption will always be an issue. 2.Well yes and no, at least that is my (maybe false) impression.As you say, if you want to be really efficient with Rust, you really should program functional as much as you possibly can. So is it functional or not? My impression is that it most of the time does not know what it wants to be. 3.Agreed and motivational to hear that it just takes some time (i'm still not that good with predicting the outcome). 4."Just like `Vec` does dynamic allocations, and you can just not use it." This, right there. The "and you can just not use it". This is what the C++ camp is saying, so the Rust community could end like the C++ community, where everyone is using another dialect.But that's just my personal grief.Anyhow, yes UB is maybe THE biggest problem. I've mentioned CompCert above, so if you are interested see http://compcert.inria.fr/man/manual004.html http://compcert.inria.fr/man/manual004.html. Regarding "A lot of human suffering had to been thrown at the problem to make C code do the job there", yes i agree. But now it (mostly) works, and nobody wants to risk anything and touch that code base, let alone rewrite. 5.Agreed. 6.My experience is not even that my peers have better things to do or do not want to try. I think it's matter of taste. People are different and prefer different things. To seren: "Rust would not have been a silver bullet but there is a whole class of error that would not have happened, and would have been forbidden in the first place. The subcontractors were supposed to use a static analyzer but we got the code back we had to fix 5000 defects of the worst kinds (buffer overflows, dereferencing null pointer, memory leaks and so on) For me, the value proposition of Rust is that it is roughly equivalent to C + a good static analyzer, but it is for free, and you are sure the checks are in place and have been executed." What makes you think that those people wouldn't have used "unsafe" everywhere, just because it makes their job easier?You would have ended up with the same mess.