To quote Grissom from CSI: I've learned that sometimes you can go faster by going slow ;-)
Also many processor manufacturers have hundreds of different models with similar but different port mappings. They often supply C-header files which helps making your software compatible with numerous different processor types. So even while Rust has a macro system, it would need to be adapted by those manufacturers or C will likely stay the more convenient choice for the time being.
https://www.misra.org.uk/Activities/MISRAC/tabid/171/Default...
https://www.autosar.org/fileadmin/user_upload/standards/adap...
https://en.cppreference.com/w/cpp/freestanding
Certifications that Rust has yet to achieve.
Most of the embedded platforms of old will be 16 bit, and as soon as somebody upgrades them to 32 bit (or more), the problem will most likely vanish. Then the next problem arises. Most embedded platforms are governed by strict regulations (mobile phones, medical, automotive, etc) and requires thorough testing. Even if you upgrade your hardware (and if the current, cheap, 16 bit hardware works, why bother ?), you do not want the challenge of rewriting 20-30 years of code in a new language.
In many cases you're looking at 30+ years of development by 50-100 developers, and while the code itself probably hasn't grown by a factor 30, chances are that the system evolved from a small system where core business was understood by "everybody" into a behemoth where only a few developers/architects actually understand everything , and everybody else just understands what their little corner does.
Many people mistakenly think embedded means small, which is often far from the truth. I used to make sortation devices, and the total codebase for a single sortation device would often reach 1GB of C source code. Around 750MB was "common code", but the last 250MB would be customer customization.
A GSM handset in the late 90's had about 350MB C source code, with the majority of it being protocols (GSM, Edge, Bluetooh, SMS/EMS/MMS, WAP). The lower level ones of those have mostly been replaced by hardware these days, only to have the UI take up much more code.
It's essentially the same problem that keeps COBOL in this world. Newer and (probably) better languages exist, but COBOL has a massive codebase, and while "edge" systems are easy to replace, at some point you're left with "core business" which has been running as a patchwork of COBOL programs for 50 years. There's no easy way to do it, and you need to rewrite everything.
So I perfectly know what is doable when one actually cares on how to do stuff properly.
And then there are those Jason demos on how to target C64 with C++.
This sounds completely bonkers, aren't you including a bunch of static assets like images or whatever else?
> I think this profession is hard enough as it is.
Exactly, I think so too. Don't think I need another source of annoyance like spending days on digging at obscure segfaults and data races caused by logical mutability mistakes.
Another dimension to it is that the borrows checker rules also apply in most other languages if you want to write valid code. They are just not enforced and you have to rely on your own discipline instead (which humans are bad at).
The problem with unsafe programming in the traditional C style (with its heavy reliance on shared, mutable, possibly aliased pointers) is that it's inherently non-compositional: proving safety or correctness of such a piece of code is a 'global' problem that cannot be meaningfully decomposed or modularized. That's why Rust's choice of explicitly restricting these features to "unsafe" blocks feels intuitively right - the "safe" part of Rust is essentially the part that can be worked with in a highly modular way, where safety is checked 'locally' via a type system. Future versions of Rust may well make some currently-unsafe features slightly easier to use, perhaps even more idiomatic in a way that might appeal to C developers, but some inherent constraints will remain.
Yes, ARM processors are used more and more, but there are really A LOT of embedded systems out there, which are still, for example, 8 bit. As an embedded dev, who is using pretty much everything from 8 to 64 bit, the kind of memory safety errors you talk about I have yet to see with on anything based on (say) a 8051 or PIC. On a system without OS and without dynamic memory allocation, the borrow checker does not buy you much. It's a different story with an ARM processor and an OS (real-time or not does not matter).
Of course Rust has a more powerful type system, but my experience is, that the preferences for a C type type system dominate the embedded world. Not because it is better or simpler, but because most embedded devs actually like low level. They are simply not interested in type driven development (yes it's just their personal taste) and its benefits.
Or let me say it like this. I see two kinds of embedded devs:
- Those who abstract way the problem ("It's all just a big char array.", "It's all just ints.", "It's all just data structures").
- Those who abstract away the machine ("It's all just objects.", "It's all just types.").
Right now, my observations tell me that the first group is still dominating. Time will tell if this is going to change.
As an embedded dev one of the things I love about Rust is the ability to use the type system to enforce the machine's invariants. Some register has a bunch of bit fields? Break it up using a struct, and unlike C's struct bitfield notation you don't have to shift the values around every time.
Rust forces you to check all enum variants, not just in switch statements like C (and that only with the -Wswitch-enum or equivalent warning) and disallows any unlisted value (there's no "default" for an enum).
Those things alone probably aren't enough to switch, but as a machine-focused embedded dev they're certainly nice to have.
But over the time this argument loose fairness in some direction. Today, in 2020, I would feel awful if in my meetings I argued that creating unit tests is meaningless, as this will point bugs in my code that I need to fight with. Or that QA is a bunch of mean people that do not understand how to use my library and only want to point to "bugs" that is more work to me to "fix".
IMHO the borrow checker _is_ this test that I do not want to write, or this QA engineer that exercise the code to find a corner case when I am causing a memory corruption in my not-perfect work.
My approach of learning any language with "difficult syntax" is to treat those as language features rather than a burden.
It is the language bridging the coder to the complexity under the hood (the computer). This comes from Rust's nature of being a low-level PL, and it is really awesome to be able to abstract those minute details so that one can write Rust and "look, it's not that different from JavaScript"
Another analogy would be `gerund` in English. English has the `gerund` feature for its speakers to nounify a verb. Other languages don't have that, some even use the same symbols for both the verb and the noun form.
Both Rust's "difficult syntax" and English's gerund needs only one-time learning session. Once you're fluent on it the sentences come out on their own.
I dress slowly because I’m in a rush.
"Time is money".
;-).
Edit: Corrected typo.