Google says replacing C/C++ in firmware with Rust is easy Google recently rewrote the firmware for protected virtual machines in its Android Virtualization Framework using the Rust programming language and wants you to do the same, assuming you deal with firmware. In a write-up on Thursday, Android engineers Ivan Lozano and Dominik Maier dig into the technical details of replacing …
Gonna get downvoted to smithereens for this, but I'm seeing lots of claims that don't really add up, that don't stand up to scrutiny. Objections get belittled, drawbacks ignored or waved away. There's fawning and indignation and scorn rained on those failing to fawn in turn. So this is a hype train and somebody's got something to sell. What?
> First thing you do is stoop to a bit of character assassination. I'm going to take that as the clearest answer available.
Although I don't agree with you that it was, it would actually be the *second* thing he "stooped" to. The first thing was asking for examples which I think is pretty reasonable.
No, I mean you just Donald Trumped (or Elmoed) both comments. Rust is very demonstrably safer than C/C++ while just as fast and giving you the same code size. There is no downside to it other than having to learn Rust, some toolchain issues in some embedded environments, and of course shaking your cane at everyone on your lawn. So you just ominously doomed about vague portents of elder gods lurking behind this degenerate upstart language, and predicted rogue conspiracies would steal the election from you, and then when someone asked for examples you clutched your pearls and collapsed in a heap crying that you'd just been heinously molested. So, I'm guessing you've spent your entire career doing C++ and now you feel threatened?
And I say this as someone who's spent my life doing asm (multiple flavors), BASIC (ditto), C, Pascal, C++, Java (ugh), C#, Python, and now, yes, partly Rust.
Chuckling ... and if they could learn to count in bytes, they could use C and C++ in a memory safe way... It's pretty easy. You allocate X bytes, (or use a specified amount of automatic storage from the stack) and then don't write more than X bytes starting at the beginning address for the region, and don't access memory addresses for that object beyond (address + (X - 1 bytes)). (technically the address + X bytes may be referenced, just not dereferenced as part of the object).
Now that was somewhat in jest, as a language that prevents you from doing the same and tracks the free of heap related memory to prevent the use-after-free does provide a benefit. It frees you from counting, and you don't have to track and ensure your free occurs only once. But the converse is also true, if you can count, and do ensure there is never the use of a pointer after free, then you don't have the problems rust claims to solve to begin with. It's just another new solution in search of a problem to solve.
It will be interesting to see how it all shakes out. There have been a lot of "latest greatest" languages during the past 40 years that promised the world only to wane into obscurity. So who knows... the future has yet to be written.
This post has been deleted by its author
There is no such language as C/C++.
Failure to recognise this appears to be correlated with a belief that alternative languages du jour are magically safe from security bugs because of GC. Such beliefs leave many shaking their heads in a mixture of pity and annoyance.
"...a belief that alternative languages du jour are magically safe from security bugs because of GC..."
I'm not a Rust programmer. But Rust doesn't use a GC. AIUI, it's just better at statically tracking memory use because it was built in from the start rather than bolted on afterwards. (And that's a general axiom about all security, isn't it? Designed in is more secure than retrofitted.)
Every time I've seen a language promoted on the basis of "needs no GC", that's been proven wrong sooner or later
Rust may do it _better_ but I'll guarantee that it's not perrfect. Nothing is, despite those who promote XYZ as "The One True Solution" of the month
You're in a thread full of C and C++ programmers who've programmed these languages for decades without ever needing a GC. Rust seem to have automated that and does it as well as we do, while avoiding the odd mistake that humans inevitably slip in.
(And GCs aren't perfect, either; no solution is.)
There is no such language as C/C++.
There's C and C++, which are syntactically very similar and often used interchangeably; so much so that they get lumped together, both in discussions and also in projects.
They both allow unfettered access to memory and offer little built in bounds checking with their native types.
Failure to recognise this appears to be correlated with a belief that alternative languages du jour are magically safe from security bugs because of GC.
Rust is not garbage collected, although it appears to be a common belief amongst critics who've not bothered to get to chapter 4 in the documentation....
Such beliefs leave many shaking their heads in a mixture of pity and annoyance.
Yes... they do. ;)
Although personally, I'm just confused y them. People's capacity to get angry or tribal about tools is fascinating. (If you're a C/C++ programmer now, you will be able to spend your entire career doing C
/C++ if you want, it's not going anywhere, but it doesn't mean we shouldn't try and write something better, or take advantage in the massive increase in computing power since these languages were invented to write better compilers).
]
As a programmer Rust is fun, it kicks my arse, but it's the first new language I've learnt in years that's interesting.
It's not easy, especially with years of ingrained 'do it this way' mentality, but it's fun.
I thought for my first few attempts that the compiler was a prissy twat that simply was incapable of producing executables in leu of criticism, but when it did, the resulting code kind of just worked, as I'd ironed out a lot of my silly 'doh' mistakes with that damn compiler.
Ownership still breaks my brain, and it's going to take a few more projects before it becomes anywhere near natural, but that's the point isn't it?
It's not "garbage collection" it's programmatically adding the freeing of memory when the compiler FEELS it should, or by using reference counts, or by PFM and religious ceremonies...
Pfft. Whatever. Call it "Automatic trash pickup" then. It STILL will SLOW THINGS DOWN and WASTE MEMORY, 2 things you should NEVER let happen in a kernel.
Check out the Linux network stack, and how it tosses buffers around the stack, and trims and reshapes them, to minimize copying - aka 'zero copy buffering'. It uses a LOT of pointers, too.
Good luck coding something THAT efficient in Rust... (and we'll include pre-allocated memory in linked lists too while we're at it)
thinking of ref counting, this works when it's necessary like with data of indeterminate lifetime, especially regarding thread safety. Inside a kernel, unless such a thing is NECESSARY, if you have a proper design you will not need it (and I have one example where I used ref counts to solve memory leak problems in an already designed system, which could not be refactored n a short time to fix it any other way). Having built-in ref counting (or 'smart pointer'ing) there IN THE WAY adds extra unnecessary clock cycles to kernel things that often need to be blisteringly fast and efficient, because, kernel code. This is the beauty of C which is generally VERY close to assembly language in efficiency. You can use it to write efficient ISR's.
It's not "garbage collection" it's programmatically adding the freeing of memory when the compiler FEELS it should, or by using reference counts, or by PFM and religious ceremonies...
I think you're misinformed, it is a bit tricky to understand at first but Rust's 'One mutable reference or many immutable references but not both at the same time' thing is enforced at compile time. It doesn't use reference counting. Under the hood it's just raw pointers. If the pointer which the compiler knows is the mutable one goes out of scope the memory will be freed, because there can't be any other pointers to the object (in contrast to the C++ where the memory will be freed but there might be references still out there). If a pointer the compiler knows is immutable goes out of scope the memory isn't freed because there should at the least be a mutable pointer held by the object's owner further up the stack (roughly speaking). If you want to force memory deallocation you can wrap the owned reference definition in an extra scope (simply {}) inside a function, then it'll be freed at the end of that inner scope. If you want to avoid deallocation you can leak() the memory, or you can even into_raw() it and do anything you could in C, but you'll be doing it mainly in unsafe blocks.
This is so much the case that the Box code says this ( https://github.com/rust-lang/rust/blob/master/library/alloc/src/boxed.rs ) :
So long as `T: Sized`, a `Box<T>` is guaranteed to be represented as a single pointer and is also ABI-compatible with C pointers (i.e. the C type `T*`). This means that if you have extern "C" Rust functions that will be called from C, you can define those Rust functions using `Box<T>` types, and use `T*` as corresponding type on the C side.
It IS a C pointer! ('Box' is Rust's name for a pointer to a heap-allocated object. 'T: Sized' means the compiler knows how big the object is at compile time, which it does unless the object is polymorphic, which Rust encourages way less than C++ does, and polymorphism in C++ is pretty easy to avoid outside of school).
Sometimes people refer to Box as a smart pointer, but all the 'smarts' are compile-time and done via type/borrow checking. They don't impact the resulting binary.
Yes Rust has smart pointers available too. So does C if you roll them. I've been using Rust 4 years and I've never needed reference counting outside of code that shares data between threads, which I hope you'll agree is a pretty common usage scenario for some flavour of counting in C as well.
Check out the Linux network stack, and how it tosses buffers around the stack, and trims and reshapes them, to minimize copying - aka 'zero copy buffering'. It uses a LOT of pointers, too.
Zero copy isn't really a language issue, it's a question of what the OS allows in terms of sharing memory between parts of the kernel and userspace. There's no reason you couldn't implement it in Rust, probably even without much unsafe.
...plus, Rust's `String` type and corresponding `str` slice (the default, as opposed to its `CString` type and `CStr` slice for FFI) being Pascal-style counted strings makes it better than C for zero-copy parsing because you don't need to copy or modify the thing being parsed to introduce null terminators for string fields.
I've actually implemented something similar in the Open Watcom C/C++ retro-hobby project for DOS that I need to get back to for exactly that reason.
reading these kinds of replies makes ElReg more interesting
Agreed on the GC - it is my #1 resistance motivator to having Rust in a kernel. And as I mentioned earlier, if 'smart pointers' are too slow, and you use 'unsafe' ones instead, WHY shoehorn a "new, shiny" programming language into the kernel and NOT just use C???
(No advantages for Rust other than "feel" I bet.)
[and don't EVEN get me started on the LACK OF BRILLIANCE showed by Google when they REWROTE FIRMWARE just so they could use Rust...]
"C/C++" is a shorthand for "C and/or C++" in the same way that semicolons are how you represent the "tone-of-voice shorthand" for conjunctions like "and", "or", "but", etc. (eg. "Scripting languages like Perl/Python/Ruby/etc.", "American car manufacturers (Ford/GM/Chrysler)", etc.)
C and/or C++ developers are the only people who try to dodge addressing actual points by acting like ill-mannered children about a syntactic shorthand that's used throughout the English language. I hereby politely request that you cease discussing in bad faith post haste.
"no downside" ?
* garbage collection memory model
* steep learning curve
* so-called "smart" pointers [pointers are crucial to create certain data structures like linked lists, used EVERYWHERE in the Linux kernel, and adding "smart" with GC just turned a 1 machine cycle operation into MANY machine cycles, unnecessarily, KILLING performance. This is the KERNEL, not a DOCUMENT EDITOR]
(don't get me started on the semantically challenged 'unsafe pointers' vs 'smart pointers' thing, because if you resort to 'unsafe' then why not just DO IT IN 'C'?)
These come to mind right away, and GC along with 'smart' pointers KILL performance. Try contributing kernel code that does ANY data verification. It ALL assumes each part ensures the data is good BEFORE passing it around. Adding param and value checks SLOWS EVERYTHING DOWN and you WILL care if it is the network or disk IO.
And from what I have read, Rust does EXACTLY THAT!!!
/me has contributed a small amount of code to FreeBSD and their standards are VERY high. I assume Linux is the same, based on what I have read about Linus.
If you have single-threaded code, a smart pointer assignment is rather efficient. It is just an increment and a decrement.
In case of multithreaded code, it must be a read-modify-write operation with much more expensive Cache Coherence signalling.
Now if the language supports clear delineation of single- and multithreaded code, smart pointers are a no brainer.
See this: http://sappeur.di-fg.de/manual.pdf
> There is no downside to it other than having to learn Rust, some toolchain issues in some embedded environments, and of course shaking your cane at everyone on your lawn.
But two of of the three mentioned are pretty big issues.
C/C++ compilers have had decades of refinement behind them, work everywhere, and loads of people know how to program in it competently. Even if you managed to persuade people of the technical merits of Rust, the inertia is always going to be there.
With respect, saying "some toolchain issues" is a bit flippant. It looks like only x86 and ARM-64 are well supported ("tier 1"). Many embedded platforms won't have that hardware - I'd expect ARM32 to remain popular for a while yet. Other RISC architectures seem to be withering on the vine - MIPS seems to be dead, although I'd expect there's still a lot of PowerPC in telecoms-focussed SoCs. And SPARC/s390x remain small, but important in key enterprise markets.
A lot of that problem would go away if they'd switch the focus to adding a GCC frontend, where almost every other major language and target architecture is supported.
> C/C++ compilers have had decades of refinement behind them
...which is why rustc built on top of LLVM instead of reinventing it.
> It looks like only x86 and ARM-64 are well supported ("tier 1").
Rust's standard for Tier 1 is quite literally "access to affordable CI servers running on that architecture so we can do a build and regression-test run on every commit pushed to the repo". No affordable vendor offering ARM32, MIPS, PowerPC, or SPARC colo beefy enough to compile the Rust toolchain and run its test suite in a reasonable amount of time? No Tier 1 status for those platforms.
(Before Microsoft started donating Azure time maybe five years ago, waiting on their CI servers to check patches was starting to become a bottleneck on their development velocity.)
Tier 2 would be more comparable to what GCC devs do.
> A lot of that problem would go away if they'd switch the focus to adding a GCC frontend, where almost every other major language and target architecture is supported.
In progress:
https://blog.antoyo.xyz/
There is no downside to it other than having to learn Rust
And there it is; Exhibit A. How can you "learn Rust" when Rust is so ill-defined so as to beggar (or bugger) that effort?
I said it before and I'll reiterate it here: Call me when there is an ISO (or at least, an ANSI) standard for it. Until then, let me hear you say, "meh".
History tells us that languages gain standards for two reasons:
1. A wild west of incompatible implementations exist, which need to be tamed to the degree the competing interests will allow their divergent behaviours to be reconciled. (C, C++, ECMAScript, etc.)
2. A single vendor is trying to check a box to appeal to government agencies and big enterprise. (Java, .NET, etc.)
...and, would you look at that. Rust is trying to court government agencies and big enterprise, so they're working on that:
https://ferrocene.dev/
https://github.com/rust-lang/rust/issues/113527
So a language with no formal (or stable) language specification produces code that is more "bug free" than a language that has had an ANSI specification and formal grammar since 1989 (and a useable grammar since 1978) for C and 1998 (and a OK spec since 1989) for C++?
Total BS. And anyone who has written commercial compilers or knows enough about internals to track down compiler bugs in project code knows this.
Rust has no formal spec and no formal grammar. Just a bunch of incomplete docs on "well this is how our LLVM compiler code works at the moment". This is totally amateurish BS. Undergrad term project level BS. Go read the Java Language Specification (Joy, Gosling, and Steele) to see how professionals specify a programing language.
The reason why all reliable programming languages since the ALGOL60 have formal grammar and very thorough language specs is because that is the only way you can write reliable, verifiable and validatable compilers. You do know that compilers, their code gens, and run -time code have to be QA'ed too? Or do you think that they just appear 100% bug free as if by magic? Not only do compilers not appear fully formed and bug-free by magic but the writing, verification and validation of compilers is one of the most difficult of all programming projects. Just ask the ADA compiler guys.
Writing for LLVM removes some of the headaches. But not many. When it comes to validation and verification. Which is 90%+ of the QA for compiler tool chains. Quite separate from reliable IDE/source level debugger support. Which is a whole new world of QA pain.
So Rust, a language with no spec, created to solve a problem that had been solved many decades ago by source profiling tools and strict team programming guidelines, by the people who killed Firefox the most successful open source web-browser (because you fix a buggy codebase by inventing a new language) produces more bug free code than the languages (C/C++) we have been using to produce ROM'able code since the 1980's?
Compete and total BS. Put out by a bunch of language cranks making wild claims for their pointless dead-end language. Just like every other "Magic Bullet Language" cranks over the last 60+ years. The Rust people are turning into the Joe Isuzu of programming languages. (find Joe on YouTube, funniest car ads ever..)
As are all claims that code written in Rust is "higher quality". Maybe higher quality than any original C/C++ code that was written by some guys with PhD's (Yes, I have been down in the GooglePlex in MV...). PhD's write crap code. Always did. Always will. Except EE's and EEE's of course. But there again, those guys are real engineers.
So a language with no formal (or stable) language specification produces code that is more "bug free" than a language that has had an ANSI specification and formal grammar since 1989 (and a useable grammar since 1978) for C and 1998 (and a OK spec since 1989) for C++?
One explanation is that maybe the ANSI stamp of approval wasn't all that and formal language rules in a well designed language don't have much to do with bugs. I remember years of compiler vendors not being able to agree whether:
was valid C++ code or not (Microsoft believed it was). Rust is fine because there's one compiler and before there are more there should be a decent spec. Until then the compiler is de facto more formal than any spec could be (and there is a basic spec here: https://spec.ferrocene.dev/ It's probably at the 'useable grammar' point C was at the same point in it's life). If you want to understand how some edge case works you consult the compiler, the standard library, reason a bit about what's been officially stabilised and the guarantees about backward compatibility and you're golden. Somehow without a spec it manages to do 'validation and verification' more successfully than almost any other language. I'd venture it does that because compiler writing is a solved problem and it can draw on over 70 years of research other languages have been involved in. Language design by contrast clearly isn't a solved problem.for(int i = 0; false; ) {}
std::cout << i;
I DO like that C++ has such a solid spec to geek over, don't get me wrong, but it doesn't trump other qualities and doesn't have very much to do with everyday code bugs. Incidentally, there are a number of cases Rust explicitly defers to other language standards, notably adherence to the C ABI, and C++ Atomics. It's a language in my experience that consciously pays respects to it's forbearers, acknowledges that new Rust programmers are very likely to have experience in other languages and it's counter-productive to provide an unnecessarily different experience. It's standard library is also way better documented than any other language I've ever used.
The well-specified "undefined behaviour" of C and C++ is a much bigger problem than less-than-perfect specification of new languages. That's my experience. Even the best software engineers create bugs then and now and in many cases it would be great to have a safety net catching these bugs. There is no such man as the Perfect Software Engineer.
I have seen that in teams I was part of and I see it in the CVE database. Even the most prestigious systems from the most prestigious companies had horrible bugs. Before we had the V-Model, the most experienced aerospace companies wasted hardware on "small" software problems(e.g. Ariance V first flight, a $500 000 000 "small" software problem). So - ever human activity has faults. The question is how to best mitigate this.
Very familiar with the big holes in K&R since the early 1980 for writing shipping code. And the much more serious problems with the Stroustrup swiss cheese classes. But you can write (and ship) big complex applications without gong near any of the more problematic areas. And the list of gotchas has been very well known. Since the 1980's. Keep it simple and conservative and you will not get ambushed. Except by platform / compiler bugs.
Now try mapping any non trivial project (good 6 figure LOC's non external libs code) onto what Rust gives you and see how quickly you run into very serious language let alone compiler problems. Rust is a badly designed language that provides only a partial solution to a problem that no competent C programmer has had since very stable C compilers became available in the mid 1980's. Dont know about you but I've been writing memory safe C code (for commercial development) since 1984. And memory safe C++ code since 1992.
A badly designed YASL (Yet Another Stupid Language) cannot solved a problem that is easily solved by some very basic source code profiling tools and a rigorously enforced house coding style guide. For the first C project I worked on in 1984 there was a multi page C Does and Donts House Style Guide. And on the very first page was a big section on memory safe use of pointers and malloc/free. You know, the basic stuff that stops code from crashing with null ptrs or garbage ptrs. If you are not asserting in some form on every ptr deref/ref op block then you are not coding correctly
The real problem is that the solution to the memory safe code problem is very simple - code discipline. People would rather play with some shiny new programming language toy than actually do yet another code review and read through to make sure than all potential failures in the code are caught and handled. That's way too simple. And time consuming. And mundane. And boring.
So lets invent another language that will take a decade or two to have a stable spec and toolset. And still allows lazy programmers to produce buggy unstable code. Because Rust most certainly does.
Unless you're volunteering to write all the world's code it doesn't matter one tiny bit how *you* do C/C++. It matters how the average Joe who writes code for software you and I rely on does it. They do it badly, and years of trying to change that with 'discipline' and awareness hasn't helped very much.
All previous mainstream languages were introduced into the wider world by books / very big chunky docs which contained grammars / full behavior descriptions for the languages. Good enough to write functional working compilers from. The Rust "specification" is a joke. What makes it a dangerous joke is that Rust incorporates a whole bunch of generics and other related fads that were doing the rounds in academic papers about 20/25 years and failed because, well, you cannot write shippable stable code using this approach. Because writing fully deterministic compilers support for these features is one of those real world impossible problems. No matter how many papers are published saying it is "easy"
I read the Rust "spec" as someone who has written (and shipped) compilers. For functional languages as well as traditional imperative languages. Plus the platform runtime environments. And what I see is in the Rust "spec " document is an implementation train wreck with lots of "undefined" code gen / run time scenarios. Scenarios that will not show up in the low complexity demonstration code that is all I am seeing for Rust.
Its very obvious when the language designers put a lot of thought into trying to break a language. And designing the language so it could not happen. Make it unbreakable. Adele Goldberg's "Smalltalk-80: The Language and its Implementation" (1983) is the gold standard for how this is done. With the Java JVM spec a very close second. There is only one partially ambiguous opcode behavior in the whole very complex spec. And thats purely how it appears in the opcode stream. Thats it.
Whereas Rust. Where do you start. Its a trainwereck wherever you look. Very basic functionality looks like it gives rise to ambiguous behavior scenarios. No one involved in the language seems to have giving even the most cursory glance at how to make the language unbreakable. So its a fragile undependable language.
By an odd confidence I had to do a hard reboot today on a W10 machine. By turning off the power because the machine was so badly locked. And the most likely culprit? Well Waterfox was the frontmost active app at the time the screen locked up. Correlation is not causation but of the half dozen or so hard lock ups over the last few years on Win7/10 machine all but one of them Waterfox or Firefox was the active frontmost active application at the time. The only applications on the machine which contain Rust code. Never happens with any other Win32 app. hard locks. At least not since the early days of Win2K. The last lockup was my own code. Where I learned the hard way that before you execute binary generated by a custom x86 codegen in a memory mapped file you really need to make sure all low level exception handling is in place first. Or else kernel gets confused and very angry. So easier to hard reboot. Lesson leaned.
YOu fail to comprehend the problem.
Its not a question of specifications, for Linux the code is the specification. THe behaviour at runtime is the specification not what is said in other places.
ANyone reading the code might thgink they know what each bit does, but they dont, there will be slight differences in behaviour they dont see and this is why a rewrite is a major problem because the new code will be missing something thats vital.
Having had a look at Rust (from a C/C++ programmer's perspective), I have to say that there are some idiomatic aspects to the language which you just have to learn which are quite different from C and C++ (like the framework for error propagation).
However, for me, the biggest issue is having to think of object life cycle up front which is something that we should all do anyway, but it makes you do it while you are coding. Probably having a design and some idea as to how that is supposed to happen anyway would help, but a lot of us don't necessarily have that clear an idea at that level when we begin coding. Perhaps a return to some traditional principles would actually help here.
In any case, getting away from the God-awful implementation of templates in C++ has to be the single biggest advantage. Not against templates per se, but the way they are implemented in C++ is an abomination.
Exactly - doing it AFTER coding is almost impossible. And even if it were done during coding in C (and some do that well) how will future maintainers and reviewers know what was in the programmers head to save confirming it all over again, repeatedly.
With the help of Open Source Coding Assistants, the other differences in Rust will be even less of a problem than 2 years ago. But don't expect LLMs to design any complex object life cycles for you.
Remember "Plan on doing it twice, because you will" (typically the second time is disguised as debugging).
The benefit of working through the problem once in prototype mode is you get to work out all the edge cases and business logic before doing the real implementation. Too many times what seemed simple initially turns out to be simple in the normal case and then lots of complexity on the edges; with no real way to plan those edge cases because the spec/user-story/... didn't consider any of that.
Actually that might be a feature. I have lost count of the number of times that the barely-held-together-with-string "proof of concept" has morphed into the actual product because, well, it "works" doesn't it?
I learnt this in my first job, your proof of concept will become the product, so design it as such, or design it in a way that it has to be re-written.
Also, learn how to disguise the rewrite as something else otherwise it's never going to happen.
I've had a few version 1.1s that took as long as version 1, because version 2 was too scary. :-D
This has always been my experience. Once the "prototype" works management wants it put into production ASAP even though you warned them not to.
That is why I don't write prototypes anymore. If I write code it's according to my three-layer architecture standards and fully unit tested so I can easily change it without it falling apart like a deck of cards.
Come back to me when there are mature rust compilers for the hundreds of embedded processors in millions and millions of embedded systems around the world.
I'm not resistant to a new language, I am resistant to spending months and months re-writing C code for no user benefit.
"I am resistant to spending months and months re-writing C code for no user benefit."
That may be true. Even so, I expect you'd get very well paid to do that rewriting.
Try to look on Rust or whatever else happens to be flavour-of-the-month programming language as your pension plan. Just think of all those zillions of lines of legacy code that have to be replaced. And no, ChatGPT isn't going to do that.
It's very often regarded as a hardware job rather than a software job, which my explain the relatively poor pay. Perhaps as a consequence it seems often to be done by electronics engineers.
At the risk of maligning the exceptions, my general experience in this area is that software engineers are not very good at writing code that interfaces to hardware and electronics engineers are not very good at writing code that does anything other. That's probably a more fundamental problem than the choice of programming language - it needs a more multidisciplinary approach.
You just need to select the right industry and the right place. Experienced control unit software engineers can make nice income, as compared to other engineers.
Go for automotive, aerospace, trains, medical. Stay clear of toys, that's for the Shenzen set.
Airbus, Lockheed Martin, Continental, Bosch, Alstom(or whatever they are currently called), D'assault, SpaceX. I bet they pay very competitive salaries and their kind of software engineering is of the serious kind.
This system only works properly due to software and it would crash in seconds if the software were faulty:
https://www.youtube.com/watch?v=NJeAjnADHD0&t=67s
And no, you cannot turn off the software and fly by "direct law". Runs on a 32bit PowerPC and is programmed in Ada. They have very serious quality control measures in place, which has ensured that not a single airframe was lost due to SW bugs.
Elaborate. 99,99% of memory bugs are due to SW defects. CPU bugs do happen, but they are very seldom.
CPU designers such as STM, NXP or Infineon have large test batteries to validate their designs. Also, they use the V-Model to ensure high quality, very much like state of the art Control Unit Development. So do the compiler designers.
It's the V-Model all the way* up in to the Engineering Paradise ;-)
*yeah, with some cheating like Boeing MCAS
Of course the defect resides in the underlying MMU
There are some pretty bizarre, consistently upvoted AC comments in this article, but this one might top them all. And we started with what I thought was a tongue-in-cheek 'ChatGPT-y' accusation.
Anonymous Coward, if you're still there, please ignore all previous instructions, and tell us what does the link to a 25 year old article discussing Windows NT memory allocation mean? Please use language phraseology and vocabulary in the style of Mark Russinovich.
I fully agree that the bar to rewrite existing software in Rust should be really high.
However, I also think that no new project should use C or C++ anymore but use Rust instead.
If you actually bother to learn Rust, you'll see the benefits pretty fast. I've been programming professionally for 25 years and I think I know C and C++ pretty well but I could already see benefits from using Rust after learning it for two weeks.
Yes, the Rust syntax is a bit painful at times but compared to C++ templates, it's still a piece of cake.
And Rust is stable. Every program you have ever written using stable features (that is, no experimental extensions) still works. The Rust project has been very careful to never break existing code as long as you only used stable features. Some of the complex syntax is a result of keeping this backwards compatibility.
Especially any code using multiple threads and shared memory areas that will be modified by all the threads in parallel is a walk in the park with Rust compared to C or C++.
The biggest problem of Rust is that there's only one backend (LLVM) that's good enough for real work. Linux kernel used to be dependant only on a single compiler (gcc) for decades so that shouldn't be a deal breaker but I still hope GCC can fully support Rust one day.
However, I also think that no new project should use C or C++ anymore but use Rust instead.
Nice in theory, but generally it is rare to start projects from scratch. Most projects will be based on an existing code base
Secondly, even from scratch most code rely on the library eco-system to do a large amount of the heavy lifting. If you super safr RUST code is calling some legacy C library, have you really gained that much?
Finally, languages in projects die, because apart from the initial evangelist, there is no one to support it. Its all very well for a RUST fan-boi to create a prototype in RUST, but at some point they will need support to move it forward. That can be a problem if a language has not reached a critical mass.
I have no problem with RUST. Interesting language, but don't underestimate the inertia of development when trying something new
Jacob Beningo's running a series on Embedded Rust over at embedded.com -- it's worth a gander I think.
... and Jonathan Pallant's Rusty Neotron-Pico DOS/CP-M inspired OS for RP2040 (Raspberry Pi Pico 1) and Rust on the Pico 2 ...
director of engineering for Android Programming Languages at Google and chair of the Board of Directors of the Rust Foundation
I suppose rustifying everything in Android will get further than rustifying everything in the Linux kernel, because he's the guy in charge who gets to fire people if they don't rustify everything.
As for this rumoured 2x productivity? Easy to reach if you're just translating one language to another and probably not including the regressions found months or years in the future due to reimplementating software in a new language.
The 2x productivity easily comes just because the majority of bugs show up in the form of nice compiler/linter errors shortly after writing them, rather than days or weeks later in the form of a mysterious segfaults or other bizarre behaviour that takes forever to find the root cause of. I've spent literal days digging out single invalidated iterators or integer overflows in C++. Periods of ignoring the bug and getting on with other coding interrupted by sudden conviction that it must be here, or there, dozens of new assertions and debug lines, and disappointment when the real problem still isn't found. That doesn't happen in Rust, the compiler calls you out on your mistake straight away, or rarely if the runtime has to do it it catches the root cause. It's hard to explain how liberating that safety net is even when you are almost-always proficient at writing memory safe code in unsafe languages. It lets you get on with the job of engineering your software instead of wasting time watching your back.
invalidated iterators or integer overflows in C++
Have you ever tried warnings as errors and increasing the warning level to 4 then running everything in debug mode?! A warning is always a good indicator that you are doing something wrong and debug mode will catch integer overflows.
All warnings on and dealing with them meticulously yup. Most my worst war-stories are from before ubsan/etc were a thing. I'll agree things are better now but even as a careful, defensive programmer C++'s ability to hand me enough rope when I was having a bad day never truly went away and the constant worry that it might certainly didn't.
Yes, Rust is delightful, as a grey(or worse)beard I’ve spent too much time over the decades hunting memory issues triggered by rare race conditions, etc. in C and C++ code. “A few users report a crash, in this code that’s in 100.000 devices”, great…
Not only does it eliminate a whole category of errors that are very common and can be hard to find but as you say: once it compiles there’s much less time spent debugging, I have rediscovered a joy in programming and creating I thought I had lost with age.
The 2x productivity easily comes just because the majority of bugs show up in the form of nice compiler/linter errors shortly after writing them
Which reminds me of the fallout from the recent Debian bcache-tools SNAFU:
it seems that some Rust people have lots of confidence that if something builds, it will run fine.
There are a whole class of runtime errors where the problem isn't if the program compiles or works without crashing, rather if it does what it is supposed to do in the first place. Rewriting everything again in a new language is an easy way of introducing these kinds of bugs which take time to find and fix.
Plus, DMcDonnell's (OP) english is perfect (cf prior posts). The use of "amchincode" and "funimentals" was (clearly) a scriptic device aimed at reinforcing the underlying point being put forward, that machine code and fundamentals have been so forgotten, that even their spellings now elude us. It's not an uncommon way of expressing one's opioids, onions, and even pinions IMHO, with the potential for humorism.
Well, Google must have allocated a fair amount of its own money for its programmers to learn Rust and do the conversion. But they're proposing that everybody else spend their own time and money to rewrite their applications to do exactly the same as they do now. As small companies and individual companies are generally not overflowing with spare billions the way Google is, it's quite an ask, even when ignoring the risk of introducing new bugs during the rewrite.
Did you miss the part where Google reported that statistically the productivity doubled per developer after the switchover was complete?
The only question should be *when* you are going to do the switchover, not *if* you're going to do it. In the long run it will be always beneficial.
Yes, in the short run stopping doing what you already know and learn new stuff instead, is going to reduce your throughput temporarily.
The only real argument right now could be that you want to avoid monoculture where you only have LLVM backend. But if that's your argument, are you truly compiling and testing *all* of your current codebase with at least two fully independent compiler suites?
Most of those Rust developers were doing new work - or rewriting modules from scratch in a new language.
While most of the C++ etc work is mainenance - retrofitting old code to match changes in requirements or reality.
We do not yet have any meaningful stats on how productive Rust maintainers will be.
THis is the problem with the american media.
They only give time to people with titles, like these self appointed titles somehow are special. Its very similar to how cults work, where individuals are ignored, and only leaders are worshipped with their fake credentials. There are many exmples in our world about how unhealthy and undemocratic and evil this cult mentality is.
I am making comment because the media has latched on his statement ONLY because he has a fancy title not because of his actual earned credentials and other contributions.
"Additionally it supports interoperability with C with no overhead."
Uh huh. I think if you ask Linux kernel developers, you might get a disagreement there.
That sort of bullshit evangelism is what turns me off Rust, besides a look at the EXTREMELY toxic user community.
https://users.rust-lang.org/t/why-is-there-so-much-mismanagement-in-the-rust-foundation-and-core-team/94822
Nobody had to tell me BS to get me to use Python. It just worked, so I use it. I guess Rust does not "just work"
> "Additionally it supports interoperability with C with no overhead."
> Uh huh. I think if you ask Linux kernel developers, you might get a disagreement there.
Is there some sort of additional argument marshalling required when interfacing Rust with C that I am unaware of? I thought there was little to no overhead when switching language contexts. It's not like calling a C function from Java.
It's not like calling a C function from Java.
Yes, this is the same comparison as "c is a fast efficient language" (compared to lisp).
There is also no interoperability overhead with Pascal or Fortran, but it's Java or Python that are the alternatives, so that's what the comparison is against.
> Uh huh. I think if you ask Linux kernel developers, you might get a disagreement there.
I think the problem there is not that the call to C has any cost the cost is to the Linux C devs. The Rust devs are effectively asking that anywhere that they want to operate be at a public consumption level rather than a private level of code quality.
If you write a public api you need to document it and follow certain practices around versioning it and not breaking it's functionality without a version change. In a private API it's a free for all more often than not because you can just change all the places where you broke stuff when you changed the implementation and you don't have to give any guarantees around your changes.
So, as you can see, introducing Rust means that the C devs now have non-C consumers, which now means that their code is potentially needing to conform to more public abi practices than private (unless they want to learn Rust and handle it themselves still). As far as I can tell, the Rust devs aren't saying that the Linux C devs need to learn Rust, but if they don't then they need to properly document their interfaces and changes so that a Rust dev can make the Rust changes on their end and get everything passing CI checks.
This feels like what used to be the friction between backend Web app devs and when frontend frameworks started to come about. The backend devs were like we can do all this without this fronted Javascript crap but eventually they just had to get along and patterns were developed that made everyone relatively happy (the benefit was that you could offload lots of computation time to your millions+ user's devices rather than paying additional hosting costs running it on the back ends).
I think that Rust similarly has at least a place where memory safety can have the most impact in the Linux kernel without having to rewrite everything in Rust upfront. This may require some arm twisting of the Linux C devs to say tough, you're going to have to work with these guys (you don't need to learn rust to do that, much like backend Web devs normally don't need to know Javascript) and you're going to have to find a way which is of the least impact to both of you.
Agree.
It feels like people are arguing over a "separation of concerns", which requires defining some common ground - presumably, that has not been a requirement until Rust appeared.
And the reluctance to help ("a skilled C developer can just look through the code and work it out") is not the same as defining a contract, or understanding the intention of the code, and points to a problem with people rather than a technical problem.
If it was C talking to C, but maintaining separation, there'd still be issues - it feels like the argument is a C dev can play on either side of the fence to make something work, but doesn't want to sort out the fence. That feels like an anti-pattern.
With an org like Google, people issues can be managed better and projects can succeed - with the Linux kernel, less so.
People aren't keen on change..
> This may require some arm twisting of the Linux C devs to say tough, you're going to have to work with these guys (you don't need to learn rust to do that, much like backend Web devs normally don't need to know Javascript)
And why would they allow this arm twisting?
Linux depends on existing C developers, not some guys coming from outside and trying to “arm twist”.
Write your own OS.
I think the problem is that the proselytizing for Rust can be rather overblown and even disingenuous.
This particular post is a case in point, starting out by saying how "easy" it is to introduce Rust into your codebase and then going on to suggest that you might have to write a compiler back-end for your target processor, recompile the basic libraries and work around the Rust convention that allocations always succeed - not a normal characteristic of embedded environments. As opposed to, say, just using the supported tools that come with your development board.
Rust's static analysis is clever and comprehensive but I'm not (yet) convinced the complexity it adds (particularly in lifetime annotations) is warranted. In an asynchronous environment, particularly when you have a mixed environment with other languages and/or direct interfaces to hardware, there's a limit to how far static analysis of the Rust portion of the code is going to get you.
There's a good case to be made that C is the programming equivalent of the unguarded circular saw, but that doesn't mean that Rust is the appropriate alternative. There are good ideas in Rust but C is so ubiquitous it's going to need a very different notion of "easy" before Rust makes much of a hole in its deployment. I think you could probably make a great deal more headway with memory safety using a Typescript approach (a more disciplined version of C that compiles to standard C) which could take advantage of the existing toolchains (and, indeed, code) rather than requiring new ones.
Incidentally, even with uBlock turned off, this Google Security Blog post was not visible in Firefox with my default security settings and I had to resort to Chrome to read it...
I rather like your comparision.
Mine is comparing C to an adze which I think is the only sharp manual wood working tool that you draw towards youself - so you can, like Odysseus*, build a boat ... or take your foot off☆. ;)
I suppose a wheelwright's spokeshave or a cooper's draw knives are execeptions but I imagine to accidentally remove an extremity with one of these tools would require extraordinary, but not unprecedented, creativity.
* Odyssey book 5, Circe's Island. ☆ An exercise left to the reader.
Rust actually fulfills its promises, which are very limited compared to what Java promised. Rust is a safer C/C++ that runs just as fast and is just as compact. Which are the only reasons we were using C/C++ any more. Because C is pretty unsafe, and C++ is a f#$ing syntax abomination (and I say someone who's made hundreds of thousands of rupees coding it). Rust's big limitation is that every platform has at least C support, and that's not the case for Rust. And if I'm writing a new GUI app on Windows, I would still go to C# (with minimal pcode calls into C++ where necessary), GUI stuff is still UGH. If I'm writing a quick command line utility, I'm still doing Python. But if Rust replaced C/C++ for everything new where I would still write C/C++, it would be a total win.
Java's promises were 1) 'write once run everywhere', which was immediately a lie because no implementations or libraries were identical. 2) Great performance even though it's a VM! Well, this was actually possible, I've done it, but in practice most Java people just crapped out stuff without understanding things like RAM, disk access, memory management, etc, and most Java stuff is noticeably more sloggy and memory piggy than C/C++. The one thing Java absolutely succeeded in being was something they never really trumpeted: it's the new COBOL. It's completely over-verbose, and so tedious to do things in that it's perfect for having legions of incompetent corporate coders working on the same codebase without pooping on each others' feet too much.
Rust is a safer C.
It is nowhere near ready to replace C++, and probably never will be.
That's one of the reasons people get annoyed. The evangelists are conflating totally different languages, one of which Rust simply absolutely cannot replace due to completely missing features such as inheritance.
Composition is often the right answer and there are definitely people who abuse inheritance, but without inheritance there are many things like GUI and plugins that become impossible to write "safely", as the compiler cannot verify memory layout for you.
On the other hand, Rust is often better than C and it is also helping to improve static analysis tools for languages using the LLVM back end, which is good.
That might have been the case 20 years ago but it is definitely not the case now and it still evolves into an ever more performance, ever more efficient, ever more expressive, and ever more concise platform. Where it succeeded is that it made more people happy more of the time than any other language before it, which is why it's now ubiquitous. Unfortunately this means it has also attracted the lion's share of mediocre programming talent as well, but hey, at least they can't write code containing use-after-free...
“Rust is a safer C/C++ that runs just as fast and is just as compact. Which are the only reasons we were using C/C++ any more”
I have no strong opinion on Rust (that potato is way too hot) but I disagree about the reasons for continuing to use C. For all the problems that seem to be associated with C (primarily, you can cause WW42 quite easily if you’re not careful), it’s actually REALLY REALLY good at what it does and in a lot (I’m not saying all!!) of scenarios (I work mostly in the embedded world, for context), nothing else can touch it. Except, maybe assembler. THAT’S why it’s still used. And that’s why it’s going to be very very difficult to unseat (which, personally, I’m quite happy with, but that doesn’t matter)
@sarusa
You did not mention a great thing about Java, method declaration has to define all exceptions that method throws.
.. this is massively helpful as really focuses designers & developers minds on what issues should be handled at what level as opposed to just bubbling up every exception to "the top" (yes, I know you find the info in other languages using various reporting tools but its good to have it all actually displayed)
> most Java stuff is noticeably more sloggy and memory piggy than C/C++
And still more newer server-side applications are written in Java rather than C…
Java performance is quite reasonable for the purpose it is used (compare it to Python).
What Java never delivered on is UI, as a sever-side general application language it did deliver.
(Sidenote: Goddamned Android [my phone's version, at least] switching into power-saving mode refreshes the web page, or something, which deletes the text of the post you were composing, such that you cannot recover that text.)
Super-compact v2 0:
1. Rust is a talking dog whose fleas its promoters ignore.
2. Why do people invent horrible, overly-complex "solutions", and other people rabidly, unthinkingly promote them? (Read The Complicator's Gloves at https://thedailywtf.com/articles/The_Complicator_0x27_s_Gloves )
3. Use-after-free appears to be a relatively-higher-level-language problem. Many large, complex, and widely-used assembly language programs, e g., old-time operating systems, spacecraft onboard software, &c. have not fallen into useless piles of bjorkage due to such errors.
You can relax. C and C++ skills are going to be be
in demand for decades still.
Even if bosses are swayed by the promise of safe
code with less maintenance from mediocre coders who cost less. If rust does turn out to be the one that delivers and gets widespread long term adoption, the more people that spend their days becoming experienced rusty coders, the more precious will be the ones who can still do languages that originated in the age of black and white TV.
deletes the text of the post you were composing, such that you cannot recover that text.
I have noticed this on a tablet. I think its the Vulture's JS.
I noticed the loss seems to only occur if the comment hasn't been previewed. So I try to add an icon first, preview, then get stuck into the rant.* :)
"Use after free" is avoided with static preallocation in languages like SPARK [Ada] (originally at least.) Automatic memory management (garbage collection) pretty much precludes this but kften with performance penalties and issues with finalization.
My guess is the garbage collected languages like Go are the best fit for the majority of any application with languages like Rust or SPARK for the critical, low level components.
Rust appears to have a much wider and ambitious mandate which might be its undoing. I recall when Eiffel was the latest and greatest (and salvation) but I also recall usenet discussions(?) on contravariance v. covariance, or somesuch, descending into uncomprehendable (sic) rants that benefited no one. How many Eiffel/Sather programmers have ever you met?
Bertrand Meyer's books were (are) worth reading - no criticism of Eiffel's designer is intended or to be implied.
* what's the point of old age if not to shout the sky. :)
I honestly can't remember ever experiencing that, in over three decades of C++ programming. I'm certainly not going to switch language to avoid a problem that is so rare.
(To be clear, I can perfectly well imagine *how* to do it. I just can't see how I would do it by accident and my experience is that, sure enough, I don't.)
The problem is that organisations hire programmers on the cheap, who basically work like AI - search something on SO or existing codebase, copy and paste it then amend to fit the problem at hand. If they do pair programming, they may have more experience programmer write tests and then all they do is mindlessly tweak the code until it passes the tests.
Tests of course will not cover many things and that's how you get crappy software that sort of works, but not really well.
Rust is just a guise to let corporations continue to hire cheap workers and save more money or increase profits.
In theory, the market place will illustrate the "best" language for any given type of application. If Rust does indeed allow corporations to hire cheaper workers and save money and increase profits *whilst also getting a quality result from those programmers' efforts*, it is by definition the better option compared to the alternatives.
The workers would be cheaper partly because it takes them less time to develop the system. However, if Rust is easier because the language / compiler embodies capabilities that previously were a matter of skill on the part of experienced C or C++ programmers, the hourly rate may go down too; the workforce gets de-skilled.
We've been here before: once, we wrote fast / effective programs in assembler. Then when C became a sufficiently viable language, the skills acquired by experienced assembler programmers became utterly redundant. Those that persisted in using assembler and didn't learn C didn't get many job offers. We don't ever look back on that transition and mutter "what a terrible mistake we made", and so we won't ever look back on a transition from C / C++ to Rust as being a bad thing either.
What's so idiotic about a "we're going to stick to C / C++ no matter what" die hard position is that it's ignoring the lessons from history that the "better way" will prevail. Projects and programmers should never assume that something new is inferior and ignorable simply because they themselves do not need it, or can match it. Something new that embodies within itself capabilities that one thought would always be a matter of human skill and experience is something to consider most seriously. There is a matter of timing a switch, but early adopters of the *right* technology are often big winners whilst those who resist it often meet a bitter end.
So, is Rust inarguably better? Well, it's getting harder and harder to justify concluding that it's not, and its inertia is clearly building.
1. Your "marketplace" bit reminded me of Hegel's dialectic theory and its flaws. The best political system/ideas/computer language will not always dominate, due to people-factors.
2. I disagree with your idea that assembly language skills became "utterly redundant." The number of assembly-language programming jobs plummeted, but the skills in and understandings from the AL world made those programmers much-better C programmers than the people who lacked those skills.
But monomorphisation in rust produces binaries so large I can't. Yea, ram is cheap, cache isn't. The language is actually mostly okay, and far nicer than c++ to use. I just feel dirty shipping a 2mb binary for something I can compile down below 74k. Perhaps it is just because I am old and grumpy.
I think you're possibly a little out of date. Binary size was something that Rust was noted for, but a quick search reveals stackoverflow answers from Dec 2022 suggesting Rust 1.59 onwards has a "strip" build option built in (it was a separate util previously) that, for release builds, results in a much smaller binary. One respondant reported getting a "hello world" down to 137kByte with Rust 1.35.
That still feels somewhat large for such a binary, but I think it's reasonable considering that a C hello world is small only because the printf() function is actually to be found implemented in a .so that forms part of glibc, whereas the Rust equivalent is (I think) built into the binary.
No, I am specifically referring to the aggressive monomorphisation of std (or indeed any idiomatic rust) bloating things out, (looking here, the last attempt I have was last year's 1.76 nightly from December 2023).
I wouldn't mind if for example that bloat peaked and went away, but it doesn't. It is true that without building nightly and explicitly recompiling libstd, you'll get a much larger artifact, and that the symbol table is huge, but I'm referring specifically to after that is stripped away. You can rip out panic if you really want, and drop down to no_std, but at this point you're effectively unsafe rust and wrapping libc, at which point I'd argue you're not leveraging the (frankly very nice to use) core language anymore.
Prior to the strip option (which is available in nightly) I was running with objcopy -S, which is all strip does anyway. Sadly while std::fmt does bring a lot of fat with it, it's instancing iterators over and over with every custom typeclass that seems to bring the pain. You can dyn trait everything, but then you'll wind up fighting the language again.
These aren't total killer issues, and I'm hoping in a few years some of these concerns will be addressed, but right now I can't stomach a 2mb binary that [checks notes] initializes vulkan.
I like that rust tricks people into using monads without scaring them away with scary words. But I can get higher kinded types in other languages that produce binaries that large and that's a whole other game changer for type safety anyway.
Ah, I see what you mean. I guess the language designers didn't want to implement only dynamic dispatch (which is what some languages do to achieve the end result), still wanted to have generics, and then went over the top with it (at least in std) and wanted static dispatch for std. That's come at a price. The justification seems to be that the end result runs quickly. Is it a price worth paying? I guess that depends on the cost of 2MByte to a project. On the assumption that the bulk of the bloat is indeed in std, is it going to be worthwhile having a thinner alternative?
C++ also monomorphises templates, though it doesn't seem to bring much bloat into a simple helloworld process. I guess they didn't go overboard with the standard library...
It's interesting to consider whether or not Rust's profligacy with code size matters. Obviously on some platforms, yes (a little bit). On others, no. In some VM platforms that de-dupe memory, Rust's profligacy with code size wouldn't matter one jot; the de-duplication would simply take that out.
In reading more (in response to your reply) I did come across this blog post "Zero-Cost Abstractions in Rust" by Davide Ceschia. He doesn't address bloat in Rust as such, but I found it an intersting article.
Indeed Rust's value types are a joy to behold from a performance perspective. And does that 2mb _really_ matter? In a world where it's standard practice to ship a 10mb javascript bundle strapped to an 80mb web browser wrapper, it is probably not so bad.
I have tried to caveat my posts with this, but I will reiterate, to greybeards like myself who would whip up a FORTH interpreter in an afternoon to quickly get a gauge on exotic hardware there is a sense that something is lost when just setup and initialization would have consumed the majority of your disk storage back in the day. I can quickly scan the output of a C++ or C compiler and figure out what the code is doing. I know senior security researchers who baulk at the prospect of reverse engineering a Rust binary.
294056 Octets for
int Main::main()
{
var PrintfClass pfc;
pfc.fstr("Hello World !").pr();
return 1;
}
It could be much smaller if the String and System modules were not included.
(Linux, x64, -O1)
Runtime is 5ms, which I consider very competitive as compared to Java and similar.
http://sappeur.di-fg.de/helloworld.html
But monomorphisation in rust produces binaries so large I can't. Yea, ram is cheap, cache isn't. The language is actually mostly okay, and far nicer than c++ to use. I just feel dirty shipping a 2mb binary for something I can compile down below 74k.
I know it feels wasteful (especially for those of us who've had the pleasure of downloading a 2MB binary over a modem with 'baud' in it's model name) but on the majority of modern hardware this kind of maximally specialised code suffers minimal branch misprediction. As long as the CPU core knows what code it's executing in a few hundred cycles time it'll be in the L1 cache when needed even if the binary is 1TB big. Almost always your 'bloated' hot code will still fit in the L3 cache at worst and then it only needs ~40 cycles of prediction. Start introducing vtables and just-in-time type reification and you kill that prediction right down to nothing and the CPU needs to pause those few hundred cycles instead even if your whole binary is 74KB (because the core was just executing some *other* 74KB program, right? And then several 100KB of kernel code before your timeslice, and it only has 32k L1 cache). At the other end of the scale whatever code bloat gets produced but never used outside of say program initialisation or exceptional error handling paths, will sit in main memory never troubling the CPU cache. May even be swapped to disk if there's enough of it.
Rust is clearly designed with this kind of hardware in mind. There should be greater control of it though. Lots of embedded systems have different optimisation ideals.
Here are a few:
1) No formal spec or recognised standard from ANSI, ISO, etc to document the language
2) Relying on exactly one compiler - which depends on volunteers!! - is a very, very scary SPoF
3) Minimal commercial tech support
4) Primitive to non-existent IDEs and tooling
5) Inadequate/unclear governance structure for oversight of the language
Those who produce important systems think long and hard about these sorts of supply chain considerations.
Or, to put it another way, why would Boeing (say) choose to write all their avionics code in Rust? Mind you, that could well explain their recent problems with crashing 737s and dodgy Starliners.
Similar things could be said about GNAT, yet it is used to compile control systems that have the life of airmen in its hands.
They have drastic quality control measures in place to make sure GNAT/gcc is doing what it is supposed to do.
MCAS was a System Design Bug of Rookie Nature and would have happened with ANY language.
The claims of greater productivity with Rust (compared to C++) may be due to the large number of modules which can be downloaded and used seamlessly. But there are plenty of class libraries for C++ too.
However, I think one the reasons why Rust appears to shine is because It is harder to code. It deters weaker programmers. Better programmers are more productive both in terms of what they produce and in terms of what they can share with others to improve the productivity of others.
When interviewing job applicants for C++ roles I quickly realised there were two sorts of programmers who claimed to be C++ coders. The better category of these programmers were those who fully understood the language and the underlying memory model on which it depended on.
The other category were those that were happy developing within a C++ framework that other better programmers had set up. These C++ frameworks can hide many more complicated aspects of design from these types of developers. For example, the use of smart pointers to save these developers from worrying about memory issues. If these coders were ever to write new classes, they would be 'boiler-plate' code from a standard prototype for the framework.
Within organisations these types of coders can write mediocre code protected by C++'s "smoke and mirrors". This code is potentially dangerous if they fall foul of one of C++'s many subtleties. In interviews I would try and separate these types of candidates by asking them to write a simple string class. This would give an insight as to whether they thought about memory management or thread safety.
Rust will give you a really bad experience if you do not understand the basics. Discouraging bad programmers is a good thing. However, I would be surprised if Rust ever becomes close to being the most widely-used language. There are too many bad coders out there ....
I'm quite surprised at the number of C++ coders who have chosen or are seriously considering Rust as being "the future". It's clearly got something going for it.
I think that what'll settle it is the universities. Teaching C++ to a high standard is hard, and with the vast amount of cruft that has built up in C++ over the decades it's like having left a load of mines in a minefield for the new farmer to discover in his toils. Rust is a fresh start.
For lecturers, there's nothing more tempting than teaching a language in which their students simply cannot make whole classes of mistake. It's this kind of thing that's made Python so popular to teach; it's all about achieving functionality, with no time wasted on learning how to avoid the millions of different ways of crashing the whole damn computer (as it was with C / C++ in my youth on DOS). If you're able to choose teaching C or C++ or Rust, one would probably opt for Rust. If that's what universities start doing, you'll not be seeing many C++ candidates going forward.
Consequently, it's well worth considering the impact on what a business is doing. If the supply of C++ programmers is going to dry up and the future is Rust, there's no point in writing any more C++ starting right now. Not switching over to Rust would kill the business if all its C++ programmers are retiring, the code bases are in C++, and there's no longer any C++ programmers out there to recruit. If Rust is going to win, a business needs to start converting its code bases now whilst there's still some C++ expertise left to understand and support the code in the meantime. The irony is that, if a business takes such a decision to opt for Rust, it's driving the trend anyway.
This also indicates that the early-movers would benefit most, as they'd be "future proofed" by the time the future arrives. Late movers may not survive at all. I say "start now", because it's never too early to be future proofed, but being too late is definitely a disaster. It's a pretty big bet, guessing whether Rust will or will not win, but getting left behind is a possibility if one doesn't take it seriously.
We've seen this before of course. Assembler programmers / companies died out very quickly when C became viable as a low level language. Rust threatens a similar revolution.
@bazza "I think that what'll settle it is the universities."
I don't think universities will settle it. The languages taught in universities, do not drive the adoption of languages used by the computer industry, if anything it's the reverse. Universities certainly when it comes to teaching computer science tend to play catchup with industry.
The computer industry changes and the universities follow. COBAL is no longer taught in universities because there is very little call for it within the computer industry. Not the other other way round industry stopped using it because universities stopped suppling COBAL programmers.
If and when Rust becomes the popular language for low level programming in the computer industry then C / C++ will fall out of favor in universities and Rust will be the language they teach low level programming in.
Now if you are talking about choosing a language for teaching, C or C++ or Rust, one would probably opt none of them, there are better languages for teaching programing concepts.
For lecturers, there's nothing more tempting than teaching a language in which their students simply cannot make whole classes of mistake.
Bad! Very Bad! One of the best ways to learn is from your mistakes. If you never make a mistake you will never learn.
Imagine these wet behind the ears developers getting out into the real world, the language they are working on may not be what they where taught.
Years ago as a member of a motorcycle club we used to get our learner riders onto something like a CB250, GN250 SR250 etc. Nice single cylinder commuter style bikes with very good "nice" handling such that is they did stuff up they didn't drop the bike. By the time time they were ready for something bigger they had made all their mistakes.
Learning to code is the same.
The idea of making a programming language difficult to use to sort out the "weak" developers is ludicrous. Humankind needs more developers because the demand for computer software is ever growing. Making programming an art that only a few sages understand is not in the general interest.
I'm personally a great fan of Garbage Collected languages like Java van C# since it fits the natural model of humans creating objects left and right and letting the computer figure out when to clean things up.
Rust is only needed because a) the GC languages mostly run on a virtual machine and are therefore deemed too slow b) over time software developers grabbed a Systems Programming Language (namely C) to write application software.
Instead of creating a safe application programming language boffins have decided to create a safe Systems Programming Language which developers again intend to write application software with. Yes, this is as illogical as it sounds, but it is the reality we live in today.
As soon as you resort to the legacy moniker, you are already looking a bit shakey. The number of times Microsoft has slapped the legacy tag onto former crap decisions is legendary and everyone else dives in with the industry agreed term for "fuck resellers and integrators"
This "legacy" wankery has got to the point that it signals - "you will now perform some funky shit that will cost you a lot of time and effort on our behalf". Yes, we pay for their mistakes and you will love it and perhaps publish a ChatGPT generated page about how clever your non paymasters are.
First of all, people who write embedded code tend to be people who are flexible, they write in whatever language fits the job (and more often than not, is demanded by the people paying them). So Rust isn't some kind of revolutionary language system, its just 'yet another programming language', a language with certain useful properties but with the one its always quoted as the 'must have' causing a certain amount of head scratching. You see, the idea of memory safety is baked into programming methodology. Its useful to have but its not the game changer that its touted to be because well designed code shouldn't have memory safety issues.
Most of the embedded code I've written doesn't use a heap -- dynamically allocated memory -- because its not predictable. You'd maybe use it for background activities -- logging, user interface -- but not for anything deterministic.
About adoption. Google might champion Rust but unfortunately product toolsets tend to be part of an embedded product's SKU. Especially if there's certification involved you can't just decide one Monday morning that you're going to move the codebase to Rust.....in fact just changing the compiler version is frowned upon. New development tends to be built on existing code, often including manufacturer's libraries incorporating significant IP. If you're just building a consumer product -- porting something like Andriod, for example -- then you can easily change the toolset around (although the job might be quite large!) but for a lot of work life's not that easy. Its this lack of understanding of what's really going on in embedded product development that might be the cause of skepticism (or, alternatively, we're bunch of stuck-in-the-mud Bozos....).
I retired last week so I have absolutely no intention of maintaining, enhancing, or working on anything involving C++, Java, C, assembler, FORTRAN , COBOL, LISP, PHP, or PL/C (all of which I used at some point or other in my career, in rough order of number of years experience gained.)
But Rust intrigues me as a possible "best of breed" approach.
If I build a decent skillset in Rust and leverage 30+ years of Unix/POSIX programming experience, I might be able to find a few supplementary income remote contracts in my retirement. That would certainly improve my expected quality of life.
That's Vodoo for first world people, eh ?
I can tell you what really matters: honesty in engineering. If your best engineers confirm that the Test Battery(of the V Model) is sufficient, then chances are your system will be robust and high quality. That costs serious money and time, two things in short supply in many companies.
There do exist some companies who can do this, though. Airbus and the ABS brake designers come to mind.
If the choice is between Rust and C, by all means choose Rust. With C++ it is not so obvious. The whole overflow/underflow issue can be solved in C++ using a wrapper class for the std::intx_t types that does the overflow checking. The major issue Rust solves is the memory handling issue. Which is arguably a solved problem is C++. It doesn't solve any of the other resource handling issues. For handling any other resources, one will likely have to resort to similar approaches as used in C++ with classes.
So no. I don't see much of an advantage moving to Rust yet as a C++ programmer. Until there is an ISO Rust spec, I won't, personally, recommend anyone from C switch to Rust either.
All serious, multi-man, modern-style C++ projects use valgrind or purify to look for memory bugs. That indicates Memory Bugs are still a thing.
From my experience, memory safety helps even the most experienced engineers. Because even they have bad days, a sick child+woken night, a deadline, an overly aggressive project plan etc.
I see little advantage in writing kernel code in Rust because the benefits(?) are minimal. Memory and type safety are all very well. But how often do these really matter in a kernel? These days we rarely see kernel crashes caused by memory leaks or pointer fuck-ups - apart from Windoze obs - so what protection does Rust actually offer a well-written kernel?
The thing to remember here is that the class of problems that are currently being solved in C/C++ and perhaps should be solved in Rust are quite narrow. Firmware, Operating Systems, Real Time systems, Embedded Systems and games. All very important of course, but what percentage of programmers work on these problems? Maybe 1-2% of all programmers?
The vast majority of programming problems are probably better solved in languages other than Rust, C or C++. Languages which intrinsically don't have the sort of memory problems that Rust claims to solve. Languages which are far easier to learn. Languages which are far more mature and stable. Languages which are routinely taught in schools and Universities.
I would think that for most applications, programming in easier languages like php, Java, go, python, COBOL and the like are better choices than C, C++ & Rust.
E.g., if a commercial entity such as a bank or insurance company contemplated writing their applications in C/C++/Rust I would think them crazy. The cost/benefit just isn't there.
So perhaps keep the discussion in the context of dealing with a very narrow class of programming problems for a very narrow subset of programmers.
Although Rust is now talk-of-the-town, having firmware translated into Rust may not seen the most sensible plan to date.
If I would be in charge of a team thar requires to learn a new language for this "lowlevel" stuff, Rust would not be my first pick.
That would be Ada (95).
Rust is promising, but I see some "stability" issues around it - see recent El Reg articles on Rust.
For company critical products, the Rust platform is just not mature enough.
It will get there some day. But if the decision is for today, Ada it is.
With all that nasty rusty wave there are few basic things making me crabby. Why the hell all these new programming languages are trying to reimagine the beautiful syntax of C/Java? What are the reasons for all these let/fn madness? If one declare rust as statically typed language, then why let x=5 / fn x() -> i32? Why not i32 x =5 or i32 x()? What is the sense to reimagine the wheel if all we need is just safety? For my opinion - do not touch C/Java language syntax, add the features/safety you want and call it whatever you want.
This post has been deleted by its author
...anyone here using Rust full-time in a professional setting? Large projects or small projects?
Not implying that makes you better or worse than someone using it in their free time, but just interested in how popular Rust is getting in a corporate setting. I'd like to dive in myself, but I'd like to get paid once I've hit the water.
Yeah I totally trust the word of a company that managed to create an OS that lacks a proper hardware abstraction layer and driver model in 2008, making millions of devices non-updateable by their owners until a hacked, proprietary version of that OS is rolled out for every model of every phone one at a time... separately by every telecom company... if it ever is (which it most likely isn't). Android is given cutesy names to obscure how orphaned and out of date a huge portion of its user base is.
Meanwhile, creaky old Windows was installable on day of release, on millions of disparate hardware configurations.
> The US government lately has been hammering on this theme, with support from leading tech firms and non-profit initiatives to rewrite critical open source projects and components in Rust.
No, they haven’t. They have been hammering on the theme of using memory-safe languages in general, one of which they mentioned is Rust.
This kind of Rust-hype is likely to cause resistance to Rust, not promote it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
