Rust isn't viable for embedded platforms, at least not yet. It's not as easy to compile it to the most obscure ISAs as C, and the little support it has for stuff like STM32 is restricted to just that group of microcontrollers and doesn't support the entire ARM range. Maybe in the future? I'm looking forward to that day!
Go is probably never going to run on microcontrollers due to its very big overhead.
C perfectly matches on top of the hardware of a processor. Every single design decision about C was made with the computer in mind. Memory, pointers, stack, call stack, returns, arguments, just everything is so excellently designed.
If I were to make one change to C, it would be to completely rip out the #include system and bring a proper modules system. Apart from that, it's pretty much perfect.
Rust can't target the same platforms C can. Rust is also (generally) more memory intensive than C for similar programs. This makes its use in embedded situations a non-starter (at least for now).
I hope Rust takes off for embedded programming. I've been working with ESP32 and C is really the only choice if you are doing anything remotely fancy or resource constrained
It seems highly unlikely to me that Rust would take over true embedded systems (i.e. EEPROM, no OS, etc.), simply because nobody is going to write a Rust compiler for their custom architecture.
The resource constraints are what make C essentially the optimal solution for those applications
Should be noted that Rust didn't have a 30 year head start unlike C, so it's obvious that it won't have support for every single embedded platform under the sun, at least not yet. It could in principle.
And because C is more popular in embedded, new vendors are more likely to pick it for new platforms instead of Rust, which doesn't help.
Portability doesn't matter anymore. I don't know why C people press this issue so much. The world runs on x86 and ARM, with a smattering of PowerPC. Rust is already being used in embedded applications quite a bit in many companies as well.
The fact that C works on IBM System 360 doesn't help anyone.
I did a bit of embedded development (MSP430, Cortex M3, PIC18) some time ago, and I can say that having a language like Rust at my disposal would have drastically improved my productivity.
Pretty much this. I like C aesthetically, but once you had to debug memory corruption on an embedded MCU, writing Rust is a productivity upgrade. It certainly is a downgrade from Java or Golang, but thats because you're in the wrong domain - use the right tool for the right job.
Unfortunately, there's little chance for Rust to make inroads into the embedded market, tho I wish it were otherwise.
C++ has had many benefits over C for embedded s/w for many years and has similarly failed. Note that contrary to popular belief, C++ does not result in larger, more inefficient s/w than C (for the correct C++ subset).
The momentum behind the C ecosystem is so overwhelming that Rust simply will not get a foothold anytime soon.
Same, I have a number of devices here on my desk that will never get a Rust compiler targeting them. With C, it's simple, the "only" thing you have to worry about is what bugs or quirks the C compiler will have on that specific platform, not if there's a compiler at all.
Now I've left embedded development behind me for a while now, things are mostly Linux on relatively modern ARM in the field where I used to do stuff, so Rust would probably be an option there, but I still have a hard time considering them to be "embedded".
Rust is not a C replacement, it is a C++ replacement.
Many of the people writing code in C do not want to use C++.
And many of the embedded use cases for C already involve very careful memory usage. If you've banned malloc and don't have threads, you've removed a huge swath of common bug sources right off the bat.
For someone writing code to setup registers on a DMA controller, Rust has nearly 0 benefit.
(That said, no one should be writing new command line utilities in C, parsing arbitrary data in C is dangerous!)
I love C. As far as I can tell, there isn't anyone on the face of the planet trying to build anything like C in order to replace it. Rust isn't it. Rust is decidedly a "C++ replacement," if anything. Go is the closest in terms of philosophy, but Go isn't it either, because its standard implementation is garbage collected, among a number of other concerns.
There is almost certainly SOMEONE out there, a random nobody on GitHub or elsewhere actually trying to write something that is as close to C in terms of philosophy and execution but utilizes some modern niceties, but I don't know who they are.
If you want to replace C, though, you actually have to get in C's skin, and undulate and move like C does.
But here's the kicker: absolutely no major language seems to want to do this, so they're all dead on arrival.
No other language has the same ability to interop with other languages. No other language gets nearly as close to writing something that you can have an idea of what the underlying assembly looks like when you write it. No other language seems to care about the surrounding ecosystems C operates in or think about topics like ELF/Portable Executable/Mach-O.
Why? Because all of them operate in their own little bubble. No other language wants to expose those details to you. They want you to operate in the world of MyWorldLang. What's "name mangling?" What are "shared libraries?"
But you can't displace C if you don't care at all about POSIX or FFIs or assembly output or the host OS, and none of them do.
If you operate in the world of VegetableLang, they want you to work with "CarrotLib" and "Tomato constructs," and "VegThreads." And all of this other nonsense that has nothing to do with hardware. And then we end up with all of this garbage software and fewer and fewer opportunities for people to learn how to utilize their hardware, because guess what, there is no abstraction layer that will automagically help you get your records into cache lines. You HAVE to count those bytes yourself somewhere, sometime.
C is so powerful and long lasting because people who want to displace C and related languages aren't even in the same ballpark. They're on another planet. In another universe. Apparently working with a CPU or RAM to them is like asking how relevant it is for someone to be able to throw a golf ball into a basketball hoop from the three-pointer line in the fourth quarter of a football game.
Actually I’ve been pleasantly surprised by Rust on the Arduino! Things are certainly much easier with the large community behind it, I probably would’ve chosen C if there wasn’t an existing community.
I don’t think Rust should be used everywhere, but I’m firm that it could be used anywhere that C can (short of an unsupported architecture).
I have replaced my use of C (and C++) in embedded with Rust for the last couple of years. Sure, some parts are still missing or immature, but overall also very promising.
And I do enjoy it so much more than the MCU manufacturer's please-insert-your-c-code-between-these-comments-and-pray kind of development.
I love Rust, but being the most favorite language and being an essential language to know in some sense (read, write, understand) are two different things.
C is primitive and painful to program in for the most part. However, it's at the core of plenty of important things, so having enough knowledge to get around it is crucial.
C is essentially a portable assembler and it's great for a number of tasks. Rust is a general-purpose programming language and it has a vastly different domain of application. Surely, they overlap, in some domains Rust is overtaking C (where C was used more out of necessity/lack of alternatives rather than consciousness). The point is, though, is that there is a domain (not necessarily very big, but very important) where C will very likely stay for a very very long time. At the same time, Rust is great, but not much critical software is written in Rust (yet). It's likely that there will be such software in the future, but I think the consensus is that nobody knows for sure.
Go is probably never going to run on microcontrollers due to its very big overhead.
C perfectly matches on top of the hardware of a processor. Every single design decision about C was made with the computer in mind. Memory, pointers, stack, call stack, returns, arguments, just everything is so excellently designed.
Even Linus Torvalds says so! https://www.youtube.com/watch?v=CYvJPra7Ebk
If I were to make one change to C, it would be to completely rip out the #include system and bring a proper modules system. Apart from that, it's pretty much perfect.
reply