Just get a few rust standards out of iso, one for the core language and another for some standard libraries, and get it over with.
But more generally, I think you’re approaching this from the wrong angle, perceiving a problem that doesn’t exist—Rust is already not tied to a single corporate interest. But have patience, there are rustlings of independent implementations in a few places, and their fullness will come in a few years’ time.
C was still mostly K&R C when the process started, and in C++ all we had was the C++ARM book.
And no, I don't trust the Rust propaganda machine. When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser.
And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.
How exactly is having one compiler defining what is okay and what is not worse than "what we have now"? The multiple implementations of C++ are all incompatible with each other in various subtle ways, produce code which works differently and at the end of the day everyone just takes one and says "we write C++ which works with <compiler>" and that's it.
> When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser.
Why exactly is it a problem that the core team of a language is interested in the language? Or do you want to imply that the rust devs working on Firefox weren't interested in it? All the progress Firefox made in the last few years tells a very different story (yes, not all of it is due to rust, but a relevant part is).
> And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.
If you haven't read any critical postmortem about Rusts difficulties in these spaces you haven't looked around very much. This is an impression I generally get from your post. You don't like Rust (for some reason, it's not very clear what it is) and seem to have an axe to grind with it. Which is .. okay? No one forces you to like a language, but doesn't make for a very interesting conversation.
This compiler is on the other hand naturally not available on all platforms and is not appropriate for all contexts. Alternate implementations could have filled these gaps, but they're not there.
The fact that the compiler defines the language and vice-versa enables additional flexibility in changing the language/compiler and development speed at the cost of instability. Different projects may tolerate different amounts of instability and for those that are more conservative Rust may not be an appropriate investment.
With C++ one can code for a specific compiler or in a standard way. One can pick C++98 or 17 or anything in between. All of these are supported options and they give C++ its massive breadth and offer the most flexibility to teams. There's obviously disadvantages associated with all that, but claiming that diversity is a weakness is not generally true.
There are already alternative compilers, though most of them are WIP, e.g. mrustc[1], rust front-end for gcc[2][3], or using cranelift[4] for the back-end.
[1] https://github.com/thepowersgang/mrustc
[2] https://github.com/sapir/gcc-rust/tree/rust
It would be interesting for example to see if e.g. the 2015 edition will still be usable/used 9 years later (like C++11) or even ~20 years later (like C++98) but we have some way to go before we can find that out.
On the other hand, there's something exciting about being on the bleeding edge. Right now I'm using C++17 and would probably jump on C++20 when it becomes widely available. But having the knowledge that I have the rock-solid C++11 at my disposal and knowing that it will likely be there for decades gives me a feeling of security that's hard to beat.
Lib A compiled with edition 2018, talking callbacks to functions implemented in Lib B with edition 2020, Lib C edition 2030 importing Lib D edition 2025.
Naturally, I am also assuming that for pleasing the commercial users of binary libraries, typical in C and C++ universe, all those crates are only available as binary libraries being pulled into a multi-edition final executable.
This is a double standard. C was created in 1972 and standardized in 1989. A major C compiler (MSVC) doesn't even fully implement C99 from 21 years ago.
C++ itself was created in 1985 and standardised in 1998. Yet it was adopted.
Yes, things have changed and the bar has been raised. But people don't seem to have followed your reasoning even for C and C++.
> Apart from kernels and drivers (where Rust seems an outright no-go)
Why? From what I've read Rust can actually help with managing hardware resources through its semantics. What blocks it from being used?
It enables experts in different areas from different countries to come and work together under a set of specific rules that are much stronger that words written in wikis or repos. It also makes it clear that the language is designed for the long term and is not under the control of a single party (as was the concern about e.g. Mozilla which the Rust community tried so hard to dispel).
It avoids embarrassing transitions like Python's 2->3 or one corporation taking control of a language like Oracle did with Java by simply buying it. It avoids having to watch a language go extinct because its corporate sponsor wishes it so (Objective-C, VB 6) and many other such unpleasantness.
This is partly why this AWS focus is strange to say the least. I would have thought that it's obvious for the Rust community that having one large sponsor is not healthy. This tells me that Rust was never really as independent from Mozilla as claimed and Mozilla refocusing away from it seriously hurt the language.
Not many people care about standardization, it seems.
I know that it's been renamed, but I think you agree that it's still a very complex and powerful language.
But it's there for those that really need it and personally I like it because it shows what we can achieve when a massive group of experts from all over the planet gets together and they nurture a project over many decades which has to work for such a broad set of use cases under the most strict and diverse of requirements, from avionics to mobile apps, physics simulations to cutting edge video games, medical devices to smartwatches and so on.
These two languages have contributed so much to what we have achieved and they're part of our digital heritage. Maybe that's another reason that they had to be standardized, so that they belong to everyone. :-)
Where is this coming from? I’m also worried about AWS over-representation in the Rust community but they’re far from the only significant corporate sponsors at this point.
As long as a language only has a single implementation or "reference compiler" (like Rust), standardization only adds needless bureaucratic overhead.
The "after 20 years" remark is totally irrelevant because just because the C community was extremely slow it doesn't mean everyone is supposed to repeat the same mistakes.
The only relevant point in your remark is that a standard is required when there are at least two implementations that need to interoperate. That's the only relevant point. A standard is the only way to ensure that interop is possible, and that implementations are reliable.
It is true that the folks working on Rust are focused on "advancing the language," yes. I don't see why it would be any other way?
> Apart from kernels and drivers (where Rust seems an outright no-go),
Rust works great in these scenarios. We'll see about some higher profile examples, like Linux. Work there is ongoing. Only one way to find out.
> C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space.
There are a ton of projects in this space. After all, the Rust compiler, for example, is one of the two OG massive Rust codebases. But there's also tons and tons of projects here.
> Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.
Sort of, but also not really. Implementing a DOM would be easier if Rust had inheritance, is usually what is claimed. Yet, Servo was still built, and nobody would suggest that the DOM was a hard blocker here.
That wasn't the argument. What's problematic is that Rust developers are focused on their language above anything else, to the detriment of the primary product they're developing. When the product - a web browser to stand against Chrome - is much more important than yet another programming language. It's about obsessing on your tools and being in love with a programming language; I call it "thinking with your fingers".
I guess this is the core of it. It is hard for me to understand why you'd think people working on a language would have "the primary product" be something other than the language. There isn't even a single coherent other project to be associated with. Why would "a browser" be special here? It’s even in the name: the Rust developers. We develop Rust.
Do you fault the C standards body for working on C? Or the Ruby core team for working on Ruby? What language do the developers of the language consider something other than the language as their primary product?
Now, of course, as a tool maker, you have to make sure the tool is fit for purpose. You want to enable the people who are working on projects like a browser to be able to do their job. But that's their job, not our job. It seems like you're suggesting that the primary job of Rust developers is to improve Firefox, and it's very confusing to me why you'd say that, when nobody would say that about any other language. Or at least, I've never come across that sentiment before.
> The Servo Project is excited to announce that it has found a new home with the Linux Foundation. Servo was incubated inside Mozilla, and served as the proof that important web components such as CSS and rendering could be implemented in Rust, with all its safety, concurrency and speed.
This is clearly written by someone who sees Servo as a showcase for Rust above anything else rather than what tf it is, such as a state-of-the-art rendering engine. But the developers addressed as readers, such as me, care about the state and coverage of the actual layout engine, CSS parsing/matching, rendering and rendering targets, font handling, and the like.
I'm not the only one bringing this up; when the announcement was discussed [1], there were similar sentiments. For me, a programming language is a means to an end for creating machine code, not an end in itself. This focus (and Mozilla and developers walking away from it) also hints at Servo not being all that useful (or incomplete?) for actual rendering; we don't really know. Anyway, the take away for me is that diving into Servo and Rust is probably not worth my time investment.
You're the best judge of your time, but making a claim about Servo and then, in the last sentence of your post, broadening it to all of Rust, is a bit odd. Servo's not even in production, unlike plenty of other Rust code.
I think the issue here is that this post makes sense to me, but it's about Servo and/or Mozilla. But your initial post was complaining about "the Rust developers." These are two (or three) effectively disjoint sets of people. I think that's where we got off the rails.
If you had said "Mozilla" in your post, I would still disagree, but for completely different reasons. Complaining about a "focus" on a team of ~20ish people in an organization of 1500 people doesn't make a ton of sense to me.
And I'm still not clear why you're drawing conclusions about Rust generally from one single project, that's not even its most popular or widely used exemplar project.
It's not possible for open source project to do such certifications by themselves. In C/C++ world there are companies that implement certified compilers. Usually, these are pretty shitty compilers that implement only previous standards like C++14.
And here is the problem for Rust. If there is no standard for the language and library, how such companies could implement an alternative compiler? Current Rust editions is not an option because they feel like a bottom line and don't answer the question to what extent the compiler has to be implemented to be called "compliant with Rust 2015".
And those fields aren't small. Usually hundreds of million lines of C/C++ power modern vehicle.
I find it's pretty funny that language, which positions itself as safe replacement for C/C++, can't be used in safety critical applications.
"fields" is a bit too broad. Not all applications in those fields require a standard or certification. That being said, you're absolutely right that in some cases, it is required.
> In C/C++ world there are companies that implement certified compilers.
That is true. In Rust, this is what we're seeing too; the first certification effort is being led by a company, in concert with the language team itself. This is still ongoing.
> I find it's pretty funny that language, which positions itself as safe replacement for C/C++, can't be used in safety critical applications.
This is overloading the word "safe." Rust has been about memory safety. Not about every possible meaning of the word "safe." Yes, Rust is not yet mature enough for industries with those kinds of requirements. Yes, they are not small fields. They are still smaller than the sum of all fields that do not require them. Rust doesn't have to be applicable for every possible use at the earliest stages of its life to matter.
We'll see how it goes.
And I find that highly problematic. If anything, Ada would be a much better choice for these safety-critical applications.
That assertion makes no sense at all. If an implementation exists and is already used in production then it's behavior is already relied upon and thus it can already be described. Just write down how it behaves and specify how it is expected to behave. That's it. That's how the whole software world has been for almost half a century.
And no, it makes no difference if a reference implementation decides to implement something that breaks that behavior. That just means it doesn't comply with the standard. That's it.
Why have these basic lessons been forgotten?
I don't know how to describe it differently as GP, but I'll give it a try. Until a formalised model is built, there is no way to describe it's behaviour that wouldn't come down to writing down the implementation that's currently in the compiler (apart from specifying it by example, which would be even more expansive).
It _might_ (don't quote me on this) be possible to more easily formalize and standardize borrow checking if you leave out non-lexical lifetimes (which were added rather recently), but that's a bad idea because you would lose a lot of functionality, and an alternative compiler with an incompatible implementation of NLLs could split the ecosystem, which obviously nobody wants.
That is the point some seem to fail to understand: said model is absolutely irrelevant if we already have production releases of an implementation of Rust.
A standard is not supposed to be academically rigorous. A standard is a specification of the current behavior so that multiple implementations can meet the current requirements, and thus ensure interoperability and compatibility.
It makes absolutely no sense to talk about "a formalized model" because rust is already used in production without said formalized model. The absence of said formalization is irrelevant. The only thing that matters is that the current behavior is specified and set in stone so that it serves as a target set in stone that anyone in the world can target and expect to interoperate.
It's terribly simple: if a rust v1.25 exists then it's behavior and interfaces can be described. Obviously. That description is what a standard is: an implementation target set in stone that others can use as a reference.
If all you have as a reference is a bunch of test cases without any underlying reasoning as to why input A leads to output B, then that's not really a useful target to implement against. At that point you can just go the direct route, not bother with any standard and just implement directly against the Rust compiler.
Suppose you’re a cave man and you’re just figuring out how to double numbers. So far, you’ve figured out how to double each number from 0 to 100. Someone asks you to write down your fancy rule so they can do something with it. Do you really want to be teaching everyone that the way to double a number is: “if the number is zero, the answer is zero; if one, then two, 2 ⇒ 4, 3 ⇒ 6, 4 ⇒ 8, &c. ad tedium”? Even if it covers all the required cases without error, it’s a mess. It’ll do for the moment for your own personal use, but you don’t want to be teaching it to other people until you figure out that you can say “to double a number, add the number to itself”.
Until we have a sound model, any attempt at specifying Rust would, for these key areas, be simply importing the current implementation of the compiler. That’s not a good sort of a specification.
> there are rustlings of independent implementations
was a deliberate choice or just fortuitous, but "rustlings" would be a fantastic term for embryonic new Rust implementations.
I'm not a C++ programmer but when I read C++ programmers discussing their language standard committee, "free and unconstrained by corporate interests" is usually not how they characterize it.
The Rust development and specification happens all in the open on GitHub.
There is no single company controlling its future or direction.
C because when UNIX started to get widespread, that was the way to settle difference across multiple language implementations.
And C++ because Bjarne eventually settled on ISO as means to settle out the differences across the various C++ implementations that sprung off.
https://www.stroustrup.com/hopl-almost-final.pdf
However this is also a reason why nice tools like package managers and IDEs are ages behind, because when one vendor comes up with nice toys (C++Builder, vcpkg, CUDA), they don't land on ISO and you are stuck in one eco-system anyway.
For Rust, so far there is one (main) implementation, which is open source. Very different scenario.
Let a, b, c be integers. Consider this statement in a language:
a = b % c
There are three ways I might go about determining that.
1. I could write some test cases and run them. That will tell me what the deal is for that particular compiler on the particular OS and architecture I am compiling on/for. It doesn't tell me if I can count on that anywhere else. It could be that the compiler doesn't care, and I'm simply seeing the way the underlying machine division or mod instruction works on my particular CPU.
If I care, then, I have to specifically write code myself to make it work the way I want, or make sure to only run my code on CPUs that work the way I want.
2. I could look at the source for the compiler. Suppose I see in there that it compiles it so that it will be consistent regardless of how the underlying CPU works, and it is even doing it the way I want.
Great, now I don't need to write extra code. I can just use "a = b % c" and be done with it, right.
Nope. Maybe in the next release of the compiler they change this to just do whatever the underlying CPU does because that enables some optimization that they could not make when they forced one particular option for this. Then my code breaks.
3. I can read the language specification and see what it says about signs and modulus. If it says it will always work one specific way, I can code to that and be done with it.
Without a specification for language X, you cannot really write X code. You can just write code for the incompletely documented X-like language implemented by specific releases of specific X-like langauge compilers, possibly also limited to specific CPUs.
In other words, it's sufficient if the semantics are publicly documented with adequate precision, and the developers of the reference implementation consider any deviation from this specification a bug.
Is that true though? I mean the spec is so "loose" that most compilers don't even work with the same code if it has any level of serious complexity. Normally that's put under the rug of 'undefined behaviour' but imo it's a "vendored version" of the language, the most common variants being MSVC, GCC and CLANG, and even projects which make efforts to be agnostic or have many eyes (linux) can't support GCC _and_ CLANG easily.