1. Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant.
2. This has been demonstrated.
3. This one hinges on your definition of “obscure,” but the “without an operating system” bit is unambiguously demonstrated.
4. I am not an expert here, but given that you’re testing binaries, I’m not sure what is Rust specific. I know the Ferrocene folks have done some of this work, but I don’t know the current state of things.
5. Rust as a language does no allocation. This OOM behavior is the standard library, of which you’re not using in these embedded cases anyway. There, you’re free to do whatever you’d like, as it’s all just library code.
6. This also hinges on a lot of definitions, so it could be argued either way.
ironically if we look at how things play out in practice rust is far more suited as general purpose languages then C, to a point where I would argue C is only a general purpose language on technicality not on practical IRL basis
this is especially ridiculous when they argue C is the fasted general purpose language when that has proven to simply not hold up to larger IRL projects (i.e. not micro benchmarks)
C has terrible UX for generic code re-use and memory management, this often means that in IRL projects people don't write the fasted code. Wrt. memory management it's not rare to see unnecessary clones, as not doing so it to easy to lead to bugs. Wrt. data structures you write the code which is maintainable, robust and fast enough and sometimes add the 10th maximal simple reimplementation (or C macro or similar) of some data structure instead of using reusing some data structures people spend years of fine tuning.
When people switched a lot from C to C++ most general purpose projects got faster, not slower. And even for the C++ to Rust case it's not rare that companies end up with faster projects after the switch.
Both C++ and Rust also allow more optimization in general.
So C is only fastest in micro benchmarks after excluding stuff like fortran for not being general purpose while itself not really being used much anymore for general purpose projects...
I think Rust (and C++) are just too complicated and visually ugly, and ultimately that hurts the maintainability of the code. C is simple, universal, and arguably beautiful to look at.
C has the same problem, but it lacks a common package manager like other languages do. Just because you need to clone git submodules or run package manager commands (hope you're on a supported OS version!) doesn't mean C doesn't have package manager issues.
C projects avoiding dependencies entirely just end up reimplementing work. You can do that in any language.
But is optional. For this kind of project, is logical to adopt something like the tiger battle ethos and own all the code and have no external deps (or vendor them). Even do
your own std if wanna.
Is hard work? But is not that different from what you see in certain C projects that neither use external deps
The lack of dependency hell is a bit of an illusion when it comes to C. What other languages solve via library most C projects will reimplement themselves, which of course increases the chance for bugs.
Then don't? In C you would just implement everything yourself, so go do that in Rust if you don't want dependencies.
In C I've seen more half-baked json implementations than I can count on my fingers because using dependencies is too cumbersome in that ecosystem and people just write it themselves but most of the time with more bugs.
If you care about not having any dependencies, then choosing dependencies that themselves don't have many dependencies should be going into the ones that you choose.
Rust insists on its own package manager "rustup" and frowns on distro maintainers. When Rust is happy to just be packaged by the distro and rustup has gone away, then it will have matured to at least adolescence.
Distributions generally package the versions of compilers that are needed to build the programs in their package manager. However, many developers want more control than that. They may want to use different versions of the compiler on different projects, or a different version than what’s packaged.
the rust version packaged in distros is for compiling rust code shipped as part of the distro. This means it
- is normally not the newest version (which , to be clear, is not bad per see, but not necessary what you need)
- might not have all optional components (e.g. no clippy)
but if you idk. write a server deployed by you company
- you likely want all components
- you don't need to care what version the distro pinned
- you have little reason not to use the latest rust compiler
for other use cases you have other reasons, some need nightly rust, some want to test against beta releases, some want to be able to test against different rust versions etc. etc.
rustup exist (today) for the same reason why a lot of dev projects use project specific copies of all kinds of tooling and libraries which do not match whatever their distro ships: The distro use-case and generic dev-use case have diverging requirements! (Other examples nvm(node), flutter, java etc.).
Also some distros are notorious for shipping outdated software (debian "stable").
I'm a Debian Developer, and do some Rust both professionally and for fun. I restrict myself to using only libraries and tooling from Debian. The experience is quite OK. And I find the Rust language team to be quite friendly and sympathetic to our needs.
Rather, what makes it hard is the culture and surrounding ecosystem of pinned versions or the latest of everything. That's probably in part the fault of Rustup being recommended, I agree. But it's not nefarious.
One question towards maturity: has any working version of the Rust compiler ever existed? By which I mean one that successfully upholds the memory-safety guarantees Rust is supposed to make, and does not have any "soundness holes" (which IIRC were historically used as a blank check / excuse to break backwards compatibility).
The current version of the Rust compiler definitely doesn't -- there's known issues like https://github.com/rust-lang/rust/issues/57893 -- but maybe there's some historical version from before the features that caused those problems were introduced.
In general, the way Rust blurs the line between "bugs in the compiler" and "problems with how the language is designed" seems pretty harmful and misleading. But it's also a core part of the marketing strategy, so...
You are correct that Rust's marketing does not claim that there are no bugs in its compiler. In fact it does the opposite: it suggests that there are no problems with the language, by asserting that any observed issue in the language is actually a bug in the compiler.
Like, in the C world, there's a difference between "the C specification has problems" and "GCC incorrectly implements the C specification". You can make statements about what "the C language" does or doesn't guarantee independently of any specific implementation.
But "the Rust language" is not a specification. It's just a vague ideal of things the Rust team is hoping their compiler will be able to achieve. And so "the Rust language" gets marketed as e.g. having a type system that guarantees memory safety, when in fact no such type system has been designed -- the best we have is a compiler with a bunch of soundness holes. And even if there's some fundamental issue with how traits work that hasn't been resolved for six years, that can get brushed off as merely a compiler bug.
This propagates down into things like Rust's claims about backwards compatibility. Rust is only backwards-compatible if your programs are written in the vague-ideal "Rust language". The Rust compiler, the thing that actually exists in the real world, has made a lot of backwards-incompatible changes. But these are by definition just bugfixes, because there is no such thing as a design issue in "the Rust language", and so "the Rust language" can maintain its unbroken record of backwards-compatibility.
> And even if there's some fundamental issue with how traits work that hasn't been resolved for six years, that can get brushed off as merely a compiler bug.
Is it getting brushed off as merely a compiler bug? At least if I'm thinking of the same bug as you [0] the discussion there seems to be more along the lines of the devs treating it as a "proper" language issue, not a compiler bug. At least as far as I can tell there hasn't been a resolution to the design issue, let alone any work towards implementing a fix in the compiler.
The soundness issue that I see more frequently get "brushed off as merely a compiler bug" is the lifetime variance one underpinning cve-rs [1], which IIRC the devs have long decided what the proper behavior should be but actually implementing said behavior is blocked behind some major compiler reworks.
> has made a lot of backwards-incompatible changes
Not sure I've seen much evidence for "a lot" of compatibility breaks outside of the edition system. Perhaps I'm just particularly (un)lucky?
> because there is no such thing as a design issue in "the Rust language"
I'm not sure any of the Rust devs would agree? Have any of them made a claim along those lines?
The Rust team may see this as a language design issue internally, and I'd be inclined to agree. Rust's outward-facing marketing does not reflect this view.
> I linked the same bug you did in the comment that that's a reply to
Ah, my apologies. Not sure exactly how I managed to miss that.
That being said, I guess I might have read that bit of your comment different than you had in mind; I was thinking of whether the Rust devs were dismissing language design issues as compiler bugs, not what third parties (albeit one with an unusually relevant history in this case) may think.
> Rust's outward-facing marketing does not reflect this view.
As above, perhaps I interpret the phrase "outward-facing marketing" differently than you do. I typically associate that (and "marketing" in general, in this context) with more official channels, whether that's official posts or posts by active devs in an official capacity.
Oh, I didn't realize steveklabnik wasn't an official member of the project anymore (as of 2022 apparently: https://blog.rust-lang.org/2022/01/31/changes-in-the-core-te... ). I do think he still expressed this position back when he was a major public face of the language, but it seems unfair to single him out and dig through his comment history.
Rust's marketing is pretty grassroots in general, but even current official sources like https://rust-lang.org/ say things like "Rust’s rich type system and ownership model guarantee memory-safety" that are only true of the vague-ideal "Rust language" and are not true of the type system they actually designed and implemented in the Rust compiler.
Yeah, Steve has been "just" a well-informed third party for a while now. I would be curious if he has commented on that specific issue before; usually when unsoundness comes up it's cve-rs which is mentioned.
> but even current official sources like https://rust-lang.org/ say things like "Rust’s rich type system and ownership model guarantee memory-safety" that are only true of the vague-ideal "Rust language" and are not true of the type system they actually designed and implemented in the Rust compiler.
That's an understandable point, though I think something similar would arguably still apply even if Rust had a "proper" spec since a "proper" spec doesn't necessarily rule out underspecification/omissions/mistakes/etc, both in the spec and in the implementation. A "real" formal spec à la WebAssembly might solve that issue, but given the lack of time/resources for a "normal" spec at the time a "real" one would have been a pipe dream at best.
That being said, I think it's an interesting question as to what should be done if/when you discover an issue like the trait coherence one, whether you have a spec or not. "Aspirational" marketing doesn't exactly feel nice, but changing your marketing every time you discover/fix a bug also doesn't exactly feel nice for other reasons.
Bit of a fun fact - it appears that the particular trait coherence issue actually has existed in some form since Rust 1.0, and was only noticed a few years later when the issue was filed. Perhaps a proper specification effort would have caught it (especially since one of the devs said they had concerns when implementing a relevant check), but given it had taken that long to discover I wouldn't be too surprised if it would have been missed anyway.
I agree that it's a tough situation. "The type system guarantees memory safety" is an extremely important pillar of Rust's identity. They kind of have to portray all soundness issues as "more compiler bugs than something broken in the language itself" (see eg https://news.ycombinator.com/item?id=21930599 which references a GitHub label that AIUI would've included the trait coherence thing at the time) to keep making that claim. It is a core part of the marketing strategy.
Yes, so there's a few things going on here: the first is, I absolutely pattern matched on the cve-rs link. Most people bringing that up are trying to bring up a quick gotcha. I did not follow the first link, I assumed it was to that. I am not educated on that specific bug at all.
I still ultimately think that the framing of Rust being any different than other languages here is actively trying to read the worst into things; Rust is working on having a spec, and formally proving things out. This takes a long time. But it's still ongoing. That doesn't mean Rust marketing relies on lying, I don't think most people even understand "soundness" at all, let alone assume that when Rust says "there's no UB in safe code" or similar that there's a promise of zero soundness bugs or open questions. That backwards incompatible changes are made in spite of breaking code at times to fix soundness issues is an acknowledgement of how sometimes there are in fact bugs, this doesn't change that for virtually all Rust users most of the time, updating the compiler is without fanfare, and so in practice, it is backwards compatible. I have heard of people struggling to update their C or C++ compilers to new standards, that doesn't mean that those languages are horribly backwards incompatible, just that there is a spectrum here, and being on one side of it as close as realistically possible doesn't mean that it's a lie.
But, regardless of all of that, it does appear that the issue you linked specifically may be not just a bug, but a real issue. That's my bad, and I'll try to remember that specific bug in the future.
> They kind of have to portray all soundness issues as "more compiler bugs than something broken in the language itself" [] to keep making that claim.
That's part of the "interesting question" I referred to in my comment. There's probably multiple factors that go into the decision of what to put onto the front page, and the presence/absence of soundness issues is just one of those factors.
For a little more color on 5, as a user of no_std Rust on embedded processors I use crates like heapless or trybox that provide Vec, String, etc. APIs like the std ones, but fallible.
Of course, two libraries that choose different no_std collection types can't communicate...but hey, we're comparing to C here.
and this things you can do in rust too, through with a bit of pain and limitations to how you write rust
and then there is the rest which looks "hard but doable" in C, but the more you learn about it the more it's a "uh wtf. nightmare" case where "let's kill+restart and have robustness even in presence of the process/error kernel dying" is nearly always the right answer.
> Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant.
I’d love to see rust be so stable that MSRV is an anachronism. I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable.
This is extremely common in the embedded and systems programming space, which Rust is otherwise attractive to use in.
For example, a very popular library in the systems/embedded space, cjson, works with C89. FreeRTOS works with C99. This is a very common pattern in major libraries. It is very rare that taking a dependency could force you to update your toolchain in the embedded space.
Toolchain updates invalidate your entire testing history and make you revalidate everything, which is often a giant PITA when your testing involves physical things (ex you may have to plug and unplug things, put the system in chambers that replicate certain environmental conditions, etc).
I feel like that's ever-so-slightly different from what GP was talking about. Beyond the potential hyperbole ("unthinkable", "any reason"), I think there's a difference between "we support C89 because nothing in later standards is useful/interests us" (which is what I interpreted GP to be talking about) and "we support C89 because we want to support platforms/compilers that don't support C99/later". cjson looks like an example of the latter, at least:
> cJSON is written in ANSI C (C89) in order to support as many platforms and compilers as possible.
And if you look through the issues/PRs you can see there was at least nominal interest in moving to later standards, though it seems those plans never came to fruition.
Not entirely sure about FreeRTOS, but something similar wouldn't surprise me all that much.
Sure, I think we’re essentially looking at the same thing from different angles. They are saying the changes in the C standard are minor enough that forcing people to upgrade isn’t worth the costs, such as losing compatibility with old toolchains for niche platforms. So they stay on an old C version.
It would be amazing if Rust was as the point where people were ready to have conversations like that.
New versions of Rust add so many handy, useful features the cost of staying on old Rust versions is very high right now. Or put differently, the ROI of picking up new versions of Rust is very very VERY good. So most packages do.
Going back to the bigger picture issue though: it’s very common in embedded to lock your toolchain and very rarely change it. This is very desirable to drive down risk and testing burden. It would be sweet if this was more easy to do in Rust. If I need to take an update to a dependency to pick up a bug fix, as it stands today, there’s a good chance these days that I’m going to hit something in the chain that bumped MSRV and will force me to update.
In real-world embedded projects using Rust, you end up with painful options:
- chase MSRV of deps and keep on new Rust. Adds risk and testing burden.
- minimize deps and reimplement everything yourself. Adds lots of cost.
- use C and incur all of the memory safety risks, and assorted foot guns
In the end, Rust still feels worth it, but it’d be super nice to not have to make that trade.
> Sure, I think we’re essentially looking at the same thing from different angles.
I sort of lean towards thinking that they aren't exactly the same thing in general, but in the embedded C world they're correlated enough that it can be hard to separate individual influences.
> They are saying the changes in the C standard are minor enough that forcing people to upgrade isn’t worth the costs, such as losing compatibility with old toolchains for niche platforms. So they stay on an old C version.
Right, and I think that's a not unreasonable position when worded that way! I'm mostly complaining about the hyperbole - "unthinkable" and "any reason" are pretty high standards which I feel are basically impossible to meet in general - as with many things, there are always tradeoffs and the balance will shift over time.
I do wonder what effect LLVM has had, if any, on the Rust ecosystem's general fast pace. Less support for embedded systems means less early ecosystem pressure that might have motivated more stability, or something along those lines.
Because given the work needed to actually get a feature into the standard I'd assume there's at least some demand motivating the addition.
I'd also be a bit hesitant about claiming that nobody is using said features. It's quite possible that the "new" feature is actually "just" a standardization of something that exists in practice. WG14 is hardly a stranger to that kind of thing, from what I understand; it wouldn't surprise me if something similar occurs for the Fortran/COBOL working groups as well.
That's a reasonable assumption, but it turns out to rarely be the case with WG5/SC22/J3. There are exceptions (like SIND, SINPI, &c.), but most new features in Fortran standards are committee inventions without prototypes, reference implementations, or official conformance test suites. This leads to incompatible implementations, and then lack of use in codes that need to be portable. It's a mess, really. I have a test suite of examples of this kind of thing that accumulated during the implementation of flang-new, in which it was a difficult task to figure out what portable Fortran really means in a way that's meaningful to users.
2. This has been demonstrated.
3. This one hinges on your definition of “obscure,” but the “without an operating system” bit is unambiguously demonstrated.
4. I am not an expert here, but given that you’re testing binaries, I’m not sure what is Rust specific. I know the Ferrocene folks have done some of this work, but I don’t know the current state of things.
5. Rust as a language does no allocation. This OOM behavior is the standard library, of which you’re not using in these embedded cases anyway. There, you’re free to do whatever you’d like, as it’s all just library code.
6. This also hinges on a lot of definitions, so it could be argued either way.