Google says replacing C/C++ in firmware with Rust is easy
theregister.com
theregister.com
Not so. The actual study compared the cost of writing something in C++ to the cost of porting it to Rust.
Personally, running some shell script on a website is not the preferred installation method of a trusted compiler. Also, porting something that must make low-level memory unsafe operations anyway... into another bodged build ecosystem is pointlessly ridiculous, and outright dangerous in some settings.
At this point, the Rust AstroTurf campaign has gone full Troll. lol =3
All software is terrible, but some of it is useful... We have seen several languages go on the same trajectory Rust is taking.
https://en.wikipedia.org/wiki/Garbage_in,_garbage_out
(you should probably assume the Von Neumann architecture will end soon too... half joking... )
Have a nice day, =3
Mind naming any? Mind naming any that aren't just toy languages?
In general, I'm a Julia Fan, and Xcode escapee (supports: Swift, C++, Objective-C, Objective-C++, Java, AppleScript, Python, Ruby, C, Pascal, Ada, C#, Go, Perl, and D.)
However, I'd trust only C in a non-llvm compiled role for real-time firmware. The answer as to "why?" takes about a decade to fully understand... Sometimes a bit longer for some... Sometimes never for others... =3
Probably not cool enough to clear a project on Rust yet... and note repeating myself about why differing use-cases matter usually requires a paid invoice. =3
That still sounds like you might be failing to understand that a compiler based on llvm can (and usually does) produce native machine code that is fully compiled and not running in any kind of JIT or virtual machine environment. And compilers like clang let you turn of optimizations just like gcc does.
Perhaps there is some subtlety lost in my words, but I assure you it will be unproductive to guess what my thoughts are... given they primarily revolve around cheese Goldfish Crackers.
We could talk about the endangered Breviceps macrops instead... those creatures are hilarious. =3
"Well specified" where exactly? You keep alluding to the existence of some significant, fundamental differences with llvm-based tools that disqualify them from their intended use cases, without providing any hint of what you think those differences are.
> Perhaps there is some subtlety lost in my words, but I assure you it will be unproductive to guess what my thoughts are
It's so hard to understand what exactly it is you're trying to communicate that I cannot tell if you are being deliberately bad at communicating, and whether linking to a video of a frog is intended as an insult. Please put some effort into clearly stating fully-formed thoughts.
If all you care about is perceived latency under human perception, than the cooked performance of llvm can improve 12% to 23% over traditional gcc for multitasking/Application use-cases in my observation ( https://llvm.org/docs/CompileCudaWithLLVM.html .)
The non-optimized gcc C builds are sometimes desirable for fixed latency real-time use-cases like 2/3rds of ARMs chip lines intended markets ( https://developer.arm.com/downloads/search?programme=Free+to... )
Are you confusing Real-Time and guaranteed-latency-schedulers as being the same thing? This is a commonly conflated concept from marketers, and the naive.
I kind of like the newer RP204x chips designs (still would never use them commercially yet), as it tried to handle GPIO domain RT and Application coding paradigms on the same silicon in a way people could better comprehend ( https://en.wikipedia.org/wiki/Clock_domain_crossing .)
Don't worry about it, at some point it will make sense... or not... cheese Goldfish crackers nom nom nom =3
Your second paragraph does not appear to make any sense on its own or in the context of the rest of your comment. "the cooked performance of llvm" looks like a translation error. Nothing you're talking about has any relevance to a link about CUDA.
Repeating the assertion that using gcc with optimizations disabled is sometimes desirable does not help explain why it is desirable, nor why equivalent results cannot be achieved using llvm. If you actually understand what you're talking about, it sounds like there might be an opportunity for an interesting and enlightening discussion about the specifics of compiler internals. But instead you again veer toward the vague insults and totally off-topic. Please don't do that.
A toy example:
1. set flag foo=1
2. check flag bar=1
3. set flag foo=0
4. check flag bar=0
These events happen in a sub-optimal repeatable order on non-optimized gcc C, and with precise predictable/verifiable op timing. We will assume interrupts are disabled in critical sections, and register states are repeatable prior to execution.
Yet, the same "bar" may have undefined behavior in llvm given the flag states look unrelated to the compiler, order/operations may not be preserved when abstracted, and linear-timing is now a compile-time packed op specific random ordered implementation. Thus, event times may happen before the parallel state has actually occurred.
Perhaps I am not the right person to explain this subject, but would recommend looking at the zynq FPGA Linux kernel example DMA module structure for more details. It should demonstrate how to coordinate parallel things better using 1 or more of the known metastability issue workarounds, and the constraints of state propagation across complex logic fabric.
In some use-cases repeatability is more important than performance/assumptions-of-safety. There is a clear difference between Application space and RT space.
This is as far as I can guide folks on the subject, and if one has never encountered these issues... than don't worry about it... Best of luck, =3
Don't worry about it... if your primary use-case is in Application space, than it won't matter most of the time. =3
Well, it's a good thing my comment had more words past that one. "volatile" is only part of the solution, and when more than one MMIO location is in play (as in your example), "volatile" on its own is insufficient but proper use of "volatile" plus explicit memory barriers will enforce correct ordering of loads and stores.
And to do that, a lot of the logic has to be re-thought to fit into Rust memory safe runtimes, which is not a straightforward thing.
Basically, at this point, AI checking C code and making it memory safe is going to come way sooner than Rust adoption.
The ultimate problem is that most of the muscle memory you’ve built using C over the years becomes useless when writing Rust due to so many of the semantic differences. If you were an expert and highly productive C programmer, your productivity will go out the window for what feels like a long time until you feel even just comfortable writing Rust. That makes Rust a very hard sell for C programmers who simply want to get things done. This is an area, by the way, that I think Zig does extremely well at—it provides safer semantics (despite its lack of guaranteed memory safety à la Rust) in a rather simple language and without rendering so much of your experience useless.
Already at this point I'm hoping that I never need to write C++ again, as the complexity of the language is maddening and only increasing.
(I've only spent a few days on Zig and it was also a very fresh breeze).
If the curve is small moving from A to B can make a lot of sense. Rust is an obvious possible successor.
But as the curve gets bigger maybe looking at less obvious choices makes more sense. Maybe even a language with a runtime or VM like Java if you’re not doing low level programming like Google is in this post.
Swift is a strawman here. I know it’s probably not there for large non-Apple adoption today, but pretend it was
If you want to develop a library, you might have to dig into more complicated features in order to provide a convenient interface for users.
If you want to build an API, using a web framework is simple and doesn’t require understanding the more complicated parts of the language.
I know that writing your first 10 lines of Rust code will give you 15 novel compile errors, and that feels like it's impossible to get anything done in Rust, but once you get over the hump, you get to use a very productive modern language that can be as low-level as C, and almost as high-level as Python, at the same time.
You will not regret leaving behind the muscle memory for all the preprocessor tricks, workarounds for gratuitous platform differences and 40-year-old footguns, all the trivia for old compilers, the never ending tweaking of snowflake build scripts, and the skill of writing yet another half-assed hash table with your eyes closed. You'll wonder how you ever got anything done in a language that kept you busy calculating malloc sizes by hand.
Rust hasn't replaced all the C I write, why should it? It's replaced lots of C I wrote around the periphery of the hairiest stuff, and frankly done it better than the C I might otherwise have written there.
I’m genuinely glad that was your experience!
I actually would love for more C programmers to have that same experience (or better), but my own experience with Rust and the experiences of many of my colleagues is that going from C as someone who’s productive with it to Rust entails at least a couple months just to get comfortable with the language and its semantics.
One could argue that spending that time is worth it for the memory safety benefits and I’d probably agree, but I’m just pointing out that it’s a pretty hard sell for many C programmers.
What C programmer hears, “you can heap allocate without a GC and the compiler will place frees for you” and thinks, gosh… this sounds irritating?
Or what C programmer hears, “we make using multiple mutable references to the same data at the same time something only unsafe rust can do” and thinks, gosh… I do that all the time, and I have no issues?
I think the bigger issue is convincing people it’s worth the energy and risk to port existing, working, and tested C code.
People who still use C rather than C++, which has this exact feature?
https://open.substack.com/pub/ryanfleury/p/untangling-lifeti...
"This, of course, does not eliminate all possible bugs (misuse is still possible, and often not checkable in a language like C++)—so, this idea is often paired in newer languages with heavier (and more complex) compile-time checking features, which attempt to both automate this code generation, and prohibit misuse."
I’ve been through my Rust hype phase, and I’ve been through thoughtfully applying it for web services and a greenfield messaging broker, albeit nothing systems level. With a decade or so C++ behind the belt, I don’t feel an app team is necessarily more productive over the lifecycle of the project if they pick Rust over C++, much less so if they pick it over Java.
I’ve been doing mostly low-latency JVM projects. I can extract better performance from a JVM and a given infrastructure than from Rust. Ease of development and the option to delegate the lifetimes to the GC, or just get a huge heap, is often the escape hatch you need to make through the tight deadline.
In Rust, you need just one “smart” colleague to make the project unmaintainable - wasting everyone’s time on optimizing the type signatures making it thereby impenetrable to anyone outside the team, or easy to forget the derivation a few months later on.
There was a nice suggestion on HN somewhere to distinguish between an area beneficial particularly to Rust (slow pace, settled architecture, more low-level) as opposed to the area with fewer fruits to reap for Rust where other semantics prevails.
I think it's great that you can build solid projects efficiently in C++ or Java! People should be free to choose whatever works best for them; as someone who does love Rust I'm of course happy to see it gaining traction, but if the flavor of the month were to suddenly change I don't think I'd feel the need to go out of my way trying to tear the new thing down.
In fact, there are lots of arena/bump allocator crates! It's not a negative point for Rust, but it solves a problem this author doesn't have.
>
> Or what C programmer hears, “we make using multiple mutable references to the same data at the same time something only unsafe rust can do” and thinks, gosh… I do that all the time, and I have no issues?
Those are some nice strawmans, but ignoring the fact that this type of response very clearly goes against HN’s guidelines, I think it’d be great if you addressed the point I actually made instead of your own.
Also, I’d like to make it clear that you’re perfectly entitled to believe this problem I highlighted doesn’t exist and is somehow a figment of my imagination. I’m just sharing my perspective and experience. You’re free to take it or leave it.
My point is, most of them already know a lot of the semantics. It’s the semantics they keep in their head while trying to be safe in C!
As for the HN guidelines. Sorry if you felt like I crossed a line. Never my intention.
>
> My point is, most of them already know a lot of the semantics. It’s the semantics they keep in their head while trying to be safe in C!
The most fascinating aspect of interactions like these is that I’m literally sharing the real life experience shared by myself and my colleagues, and you’re just like, “Nope, that’s not the case!”
Well, thanks…I guess I have nothing else to add to this discussion then.
I didn’t feel like you crossed a line—according to the HN guidelines [0], you very clearly crossed a line.
You responded with snarky strawmans instead of responding, in good faith, to the actual point I made.
To quote the guidelines:
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
I think if you’re a good C programmer you’ll naturally be a good Rust programmer, and come up to speed faster than you expect.
There’s nothing forcing you to write everything with traits, generics, etc. You can write simple, fast, safe Rust without them.
Edit: read some of your other comments and realize this doesn’t quite address your point, but I do still think that writing small sections of logic in simple, straightforward Rust and then calling that from C is a nice way to get started. Doing so for places where ownership is complicated and the compiler can help enforce invariants can provide I think a meaningful ergonomic gain in a C codebase.
Rust generally has a lot of what C has, you just might need unsafe to get it.
One notable omission is `volatile` but that sorta beside the point.
If the concern is just relearning a new STD lib and getting used to error handling with an enum instead of ints, then I suspect you could get up to speed pretty quickly.
Past that, sure the rust crate ecosystem might make use of a lot more complex bits of rust, just like C++ libraries can do wild things with templating.
If you are just comparing C, just avoid the complex stuff and write your Rust function like you write your C functions. It’ll work.
What do you mean here?
Can you point me to where I said or suggested any of that?
The horror. Lest someone make an argument that to earn a salary, you have to put in hard work.
To quote the HN guidelines [0]:
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
The problem isn't just personal preference or inertia. It's that all mainstream OSes, libraries, and system software are written in C/C++. You can't exactly ignore this and not learn the language if you want to work in this space.
Of course, there are many developers who don't work with system-level stuff, and they may be perfectly fine just knowing Java or JavaScript, but Rust is not positioning itself as a direct competitor to that.
There’s just too much pre-existing code.
Respectfully, this is wishful thinking.
C programmers aren’t going anywhere any time soon. There are millions upon millions upon millions lines of C code everywhere running critical software, firmware, infrastructure, etc. that won’t be rewritten in Rust any time soon.
However a lot of new infrastructure is being developed in rust. Infact it can be argued that the very reason it should be in rust is because it is critical. I think there would be great value if a person can efficiently thread between both rust and c rather than competing.
But you’re dead right. At this point Android apps may be the bigger set of code. Or at least put up a good fight.
I fully agree with that.
- Compile times. This, above all else.
- As an embedded dev: no_std is still rough around the edges, which the original Google blog post captured pretty well. They didn’t talk about PACs - the PAC paradigm also feels needlessly complicated - whoever wrote it really loves their zero-sized types and made it verbose to the point where the solution feels worse than the problem (at least to me) for things like using GPIO lines.
- Rust has a history of shipping serious bugs (see, floating point recently), and you basically have to constantly update your rust version. Not ideal for commercial products, which want stability.
- All of the RTOS options are also young. None of the major existing ones (e.x. FreeRTOS) support Rust natively. You’re not just asking people to learn the language, but start over on libraries and platform as well.
- The community is weird. If you don’t drink the koolaid you will be attacked.
Rust is constantly getting better, and the pain points of C impact real peoples lives in very real ways (security bugs that have led to people truly getting hurt), so Rust feels inevitable, but it’s still early days and pain.
For those of us who may be out of the loop, could you elaborate on these points?
This one was fun too: https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html
Basically, anything that gets a .1 or .2 type release.
Also, shout out to the Rust community for maintaining and fixing issues quickly; not trying to pick on them, just trying to show some examples to show Rust is still young and very much a moving target.
> This one was fun too: https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html
To be fair, that affected a bunch of other languages as well so Rust is in (questionably) good company there.
I feel the need to keep your Rust install up to date might arguably be more ecosystem-dependent than anything to do with Rust itself. If stuff you're using requires a newer rustc then you don't have much choice but to upgrade, but if you're fine using something older and/or your dependencies keep support for older versions of rustc then you can probably get away with a lot fewer updates.
No one is forcing you to learn Rust. You don't have to bring yourself spend time learning it. You can keep writing those other languages.
Those languages have been around for a while and they'll continue to be around for a while more. Rust is just getting some time on that stage as well now.
I really think there's room for a language more focussed on (sacrificing a bit for) usability/readability/DX - rust has great features like doc tests, in-module tests, structural pattern matching, macros, traits, .. but<some<of<the<container<crap, 'that>, ends<up, necessary>>>>> really ruins it for me. And on the one hand yes it is trivial, it is just syntax. But I do think it matters?
(It's late, I'm tired, not a very well formed thought, but coincidentally I was daydreaming about designing a language earlier today, so here we are.)
Non-Apple development keeps getting better. It’s a very easy to read language with lots of safety, strong types,good standard library, await, and tons of users (thanks to Apple). Integrates easily with C/C++/Obj-C/Obj-C++, or anything else that can do C interop. Just gained neat macros and tests.
It’s probably my current “if I could pick anything” language.
On top of all the rest, it looks more like JS/Python than the pile of symbols C++ or Rust or even Obj-C can turn into.
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
"Project Oberon"
"The Midori Operating System Overview"
Apple and Google show on their mobile OSes how to make developers dance to the music of modern systems languages.
I mean, maybe at a surface level. But under the covers with stuff like existential containers, opaque types, boxed types, ARC, etc it's a lot more complicated
Maybe the syntax "looks" modern like python but writing in it feels like smart pointer C++ with more safety features built in
Personally I'd rather just use C++ with a strict style guide, fewer new semantics to relearn
It's also funny that apple presents it as a "beginner friendly" language. Maybe it's possible for people to write in it without getting too far in the weeds, but like C++ it feels like a kitchen sink
Maybe all languages are like this to some degree, where there's a big gap between being proficient enough to write something and knowing it well enough to write something properly. It feels like Swift has a low barrier of entry but doing things properly has a much higher learning curve
(my rule of thumb)
Common Lisp, Scheme, Julia, OCaml, F#, C#, Scala, Kotlin, TypeScript, Clojure
Phantom type looks alien if you haven't used it, but for what it does, it's actually a pretty simple. It's there to explain in Rust's terms what an opaque type or a foreign C/C++ type does. You just need to give Rust an example of an equivalent type, and you get a correct as-if behavior, and you don't need to even know that you've just configured type's variance and destruction order checking.
But then what would you advice to do ? There are nightmare patterns in rust and c++. Looks to me as pick your poison just that one is new and other has been around for fair bit.
Also, the world still mostly speaks C99 when iterative improvements are constantly being made up to C23.
I think C23 is going in the right direction, but it needs to go further.
As college student I have invested time into rust because I see value in the language but there are absolutely zero entry level jobs or internships. To get my foot in, my only real options are C/C++.
That said the biggest obstacle I've seen has come from C++ programmers traumatized by heavily templated codebases or dependencies equating Rust generics to templates. To which I say:
C++ templates are a bastard product of preprocessors and macro systems more than proper generic programming. The errors you get from Rust generics are much higher up the chain than template errors and while both impact compile times, with Rust it's less pronounced.
Maybe this is some way to avoid Australian salary regulation and pay $10 an hour?
I admit we (non-native devs) still need to edit C++ code sometimes, but we aren’t the primary or even really secondary developers on such code.
Type signature bikeshedding is extremely rare in PRs.
Refactors can be large, but the fact that they are possible to do safely across the entire codebase with confidence in the result is a major improvement over most other languages.
I wouldn’t go back to writing most other languages if I could avoid it, especially for anything large or performance-sensitive.
Instead of quick and dirty, it allows to embed the logic in the type system such that the compiler can help you. Getting off the ground is much harder but staying there is easier.
.
Surely there is some middle ground in design space between rust and ada on one side (fully in the compiler) and c (with sel4-style checking - proof checking on a post compilation artifact) on the other.
Note that the c in sel4 and ada have stronger safety and correctness guarantees than rust
Rust can be written as simply as you want it to be written. Or, you can go crazy with generics or metaprogramming.
In theory you can do that, in practice you can't. Becoming a good $language programmer necessarily involves reading other people's code, for example when diagnosing issues in misbehaving libraries. You have to be familiar with every common language feature that other developers use, otherwise you won't be able to do your job properly.
The specification and proofs are open-source [0], but I suspect that they are tailored for seL4-related uses and probably aren't well-suited for "general-purpose" C code. I think using their proofs would also necessitate writing a specification for your own code which is probably going to be an ordeal in and of itself.
They do have a style guide [1] as well, but that's just a small part of the full verification process (described in [2]).
[0]: https://github.com/seL4/l4v
[1]: https://docs.sel4.systems/processes/style-guide.html#verific...
[2]: https://trustworthy.systems/publications/nicta_full_text/737...
Then theres the double entndre with rust and the potsntial yo reduce maintenance and how what really matters is some kund of metric like loc per dev hours for maintenance. So like, if two language are comparable and one requires 2 prgrammers to maintian and the other 2.5, the second one would potentially have more jobs based entirely on how maintainable it is.
So claiming "these have more jobs" really is a fecestious statement
Not sure who would do that or what the implications might be for replacing all the say Python code with cpp.
[edit] hum. couple of people didn't appreciate that clearly, but if you review the comments on the linked HN post, a large number of them are the discussion of the page being completely blank in firefox. If you review the firefox bug, it is apparently about a recursion overflow in the regex, where they note that chrome does some disturbing things to make it complete...
You would think distributing firmware and flashing would be routine; several vendors have shown me it isn't