11 ms·
> IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust
by shandor 10y ago
> IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust.
It would, and definitely should, move into the direction of safer languages than C.
The biggest problem I see is tooling and legacy. Tooling, because there's a ginormous amount of testing and design software that "works with C" (whatever that means in the context of the tool). Legacy, because everyone already has their 20 year old codebases and it's just not convenient to start focusing on two languages and switching the old code to Rust is just plain impossible economically.
Third problem is compiler. LLVM (rustc is a frontend to it, no?) is really good choice, but gcc has enormous advantage in supporting so many small platforms and it's very significant in this area of SW dev.
On the plus side, I've really gotten the impression that the Rust folks are truly trying to make adoption as smooth as possible. If that works, and Rust proves to be much better than C for these kinds of systems, I'd guess adopting Rust rather than not would start looking economically viable to companies. I mean, in the end that's what matters to them the most, and it's not easy to replace all you C ninjas with competent Rust writer.
- qwertyuiop924 10y agoI wouldn't hold your breath for C to die though. C sucks at many things, but it's pretty good in embedded, if you're not writing ASM.
- gcp 10y agoActually, the only real advantage that C has over rust there is the availability of trimmed libcs.
- qwertyuiop924 10y agoWhy would you use libc embedded? Most of libc kind of expects an OS to be there.
- gcp 10y agoUh? There are definitely trimmed libc's (not GNU libc!) that run on bare metal. Such as the one used by avr-gcc for example...
- qwertyuiop924 10y agoYeah, but why? I've never used a libc on embedded, and I'm kind of confused as to why you'd want to. Am I just Doing It Wrong™?
- saaadhu 10y agoAtleast for avr-gcc, (part of) startup code and vector table layout come from avr-libc. I'm kinda surprised you got by without libc - no strxxx, memxxx ,xxxprintf/no math.h functions ever?
- qwertyuiop924 10y agoNo. But my embedded projects weren't particularly impressive. I can at least see the need now.
- eggy 10y agoC seems to be going through yet another renaissance. C is a smaller language to learn. There is tons of legacy code even for embedded systems.
- gcp 10y agoC is a smaller language to learn. There are engineers with 20 years of C programming experience that will still make security errors while handling basic strings. "Small" does not mean "good" and "learning" a language doesn't mean you'll write good code with it.
- qwertyuiop924 10y agoNo, small is good. But C isn't small. It's actually massive, and not terribly orthogonal. It's peppered with special cases, and things people think but aren't actually true (how would you check for an integer overflow in C?). It's like comparing x86 to, say, m68k (or most things, really). One was designed. The other is an ungainly mess of hacks on top of hacks, which has a good, elegant design in there somewhere, desparately trying to get out. Guess which one is x86. Now guess which one is C. Worse really is better. Or at least, good enough. C isn't a complete mess, and you can write good code in it if you're very careful, but it's not great.
- dbaupp 10y agoRust has libcore, which is, in many ways, more featureful than libc despite also having zero dependencies. From my perspective, the main advantage of C is the way in which chip manufacturers only provide (poorly supported/bug-ridden) C compilers, but this is likely to become less important as ARM takes over more and more of the world: it is only getting easier and cheaper to throw a full ARM chip into a device, due to economies of scale.
- collyw 10y agoA load more developers as well?
- duneroadrunner 10y agoIf you're considering switching to Rust for code/memory safety reasons, SaferCPlusPlus[1] may be an easier/cheaper/low risk option. It allows you to add memory safety to your existing code base in a completely incremental way, with no dependency risk. (At the moment, standard library support is required though.) [1] https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
- pcwalton 10y ago"Safer C++", like all C++ template libraries, is not memory safe.
- duneroadrunner 10y agoAre you confusing SaferCPlusPlus with a different library? SaferCPlusPlus is a new library that makes it practical to stick to a memory safe subset of C++ (i.e. no native pointers, no native arrays, no std::array<>, no std::vector<>, etc.). Using the SaferCPlusPlus library to replace all uses of C++'s unsafe elements does result in code that is as memory safe as Rust, or any other modern language. The main shortcoming at the moment is that it doesn't yet provide memory safe replacements for all of the standard library's unsafe elements, just the most commonly used ones.
- leshow 10y agoCorrect me if I'm wrong, but it looks like this just provides some 'safe' alternatives to unsafe C++ things. It's still up to the diligence of the programmer to not use those things and nothing is getting statically verified. By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.
- braveo 10y agoSometimes I think Rust people lose the forest for the trees. The end goal isn't for the compiler to verify the safety, the end goal is for the software itself to be safe in a way that's cheaper. It doesn't really matter if they both end up at the same place, which is safe software.
- kibwen 10y agoRather than a ground-up rewrite, I expect people will begin using Rust in the same way that Firefox has: identify individual components that would most benefit from Rust, segment those components off behind well-defined C interfaces, then write a compatible Rust lib using Rust's ability to expose C interfaces.
- erikpukinskis 10y ago> because everyone already has their 20 year old [C] codebases It's comments like these that remind me how exclusionary the software world is. Your definition of "everybody" is such a tiny number of people. But that's who you have in mind when you are constructing the world around you each day.
- shandor 10y agoWell, one might notice "everybody" has to be a rhetoric exaggeration, since there's absolutely no way even remotely close to "everybody" would have any codebase at all whatsoever, not to talk about 20 year old legacy. Right? Second, I was responding to a comment talking about "existing, critical, real time applications". Of which a huge number of cases do have existing, very old legacy codebases. Third, I fail to see what you tried to bring to the conversation. If your only problem was with my rhetoric, see above.
- deleted 10y ago[deleted]