Hacker News Reader

Comment by chrismorgan | Hacker News Reader

Rust is not ready to be specified as is required for ISO and similar standards. A few large chunks of its functionality currently don’t have any good definition written down, but instead are defined by the rustc implementation: most significantly, the ownership and borrow checking system. Research towards formalising this model in a way that a specification could use is ongoing (e.g. https://people.mpi-sws.org/~jung/thesis.html, published a couple of months back), but until then any specification document would be unreasonably complicated and verbose, containing large chunks of the current compiler rather than describing an independently-useful model.

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.

View on HN

Most languages aren't either, they just start the process and evolve from there.

C was still mostly K&R C when the process started, and in C++ all we had was the C++ARM book.

I don't know if your wording here

> 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.

"rustlings" is already a well-known project within Rust world https://github.com/rust-lang/rustlings

I wrote the word down unconsciously, but then noticed the pun when I was going to reword it, and so left it in place instead.

> Rust is not ready to be specified as is required for ISO and similar standards. A few large chunks of its functionality currently don’t have any good definition written down, but instead are defined by the rustc implementation: most significantly, the ownership and borrow checking system.

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?

The problem is that we don’t have a sound, correct model. What we have is a compiler that seems pretty decent, but rejects some things that shouldn’t really be rejected, and accepts a few things that are iffy and potentially unsound. It’s a whole lot of code crafted in a comparatively ad hoc manner, whereas a true, correct model is likely to be simpler and more beautiful. Any specification would therefore be specifying the wrong thing, essentially a form of overfitting.

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.

> Just write down how it behaves and specify how it is expected to behave.

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.

> 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).

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 you want to exhaustively describe the behavior of e.g. Rust 1.25.0, without a formalized model, then the only way to do so it to run it for all kinds of possible (edge-)cases you encounter and document the output.

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.

While I disagree with the general sentiment of “rust needs a standard to be successful generally,” you are absolutely right in this comment. There’s a number of things at play here, but there are folks trying to do exactly this. We’ll get there, in time.

Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now.

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.

> Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now.

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.

Rust is a pragmatic project. They chose a compiler which is performant and widely available and bet everything on it to keep things straightforward. It looks like it's served them well.

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.

Similarly you can compile Rust in "edition = 2015" or "edition = 2018" and soon "edition = 2021" to guard against changes in the language, e.g. adding keywords.

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

[3] https://github.com/Rust-GCC/gccrs

[4] https://github.com/bjorn3/rustc_codegen_cranelift

Technically the possibility is there. What I'm interested in is how this will be regarded by Rust programmers as time passes and how it will continue to be supported.

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.

There's significant difference between the edition system and the C and C++ standards, and that is that the standards are done when they're done, but the editions are not, exactly. That is, new features arrive in the largest set of editions possible, whereas C99 is frozen in time. This is not to say that you or the parent are wrong exactly, but it doesn't really work in exactly the same way.

I still look forward to how editions will actually work in practice, when Rust gets a couple of years behind it.

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.

Rust does not yet have a stable ABI, and there is not any such thing as a "binary crate" at the moment. So it's kind of hard to run into that problem as the entire exercise is impossible.

That exercise is possible to some extent with C and C++, so the whole point is to prove that epochs aren't the gold solution over language selection switches, as they are currently sold.

I'm assuming you mean LLVM by "compiler". If platform support of Rust is your concern here due to limited platform support of LLVM, then that might be going away. Based on the fact that Cranelift recently landed as a non-LLVM codegen backend in nightly, I assume that work is already pretty far on supporting alternative backends that could support alternative platforms.

Correct, I was not precise. Actually LLVM is not a problem for me personally, as the platforms I'm using right now are mainstream. I was merely trying to explain why some wouldn't be content just with LLVM.

> Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now.

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?

Having an international standard behind a language gives it a certain weight that can't even be compared to the ad-hoc structures that are seen in other projects.

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.

> one large sponsor

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.

Yet Python and Java have been around for 30+/25+ years and are some of the most popular languages around.

Not many people care about standardization, it seems.

I don't care so much about standardization as about choice, though, which is what standards tend to create, or the formation of standardization bodies tend to document. C is simple enough to create a compiler from scratch in less than a year (as proven by Tiny CC), but sinking your precious time into a behemoth like Rust (or other language-to-rule-em-all with open research problems) is on another level altogether in terms of commitment. As the language hasn't finalized, can change at any time, only people with inside knowledge of Rust will be able to work on such projects. Others will have to take a significant risk of their Rust code base becoming obsolete, or Rust simply imploding due to lack of new devs outside the inner circle able to pickup. Which makes Rust an irrational choice in the presence of alternatives.

I find the Rust complexity comment quite funny in a world where C++ and Perl 5 are around and they even managed to release Perl 6 :-)

Yes, that's almost 5 years ago now. But please note that since then, it has been renamed to Raku (https://raku.org using the #rakulang tag on social media). You can check out the Rakudo Weekly News (https://rakudoweekly.blog/blog-feed/) if you want to stay up-to-date on developments.

Do you have some sort of Perl 6 alert for HN? :-p

I know that it's been renamed, but I think you agree that it's still a very complex and powerful language.

It's logical to be concerned about complexity in a specific thing even if there are other complex things in the world. That should be self-evident.

Yeah, but his argument was directly coming from a C/C++ perspective, which makes it at least a bit... strange.

I was comparing directly against C. There's no such thing as "C/C++".

One doesn't need standardized tools to get things done. One doesn't even need correctness, performance, privacy, etc as can be seen from a multitude of very successful projects.

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. :-)

Java has a standardization process, it just happens not to be ISO, it is still driven by multiple companies and at each release written documentation comes out.

https://docs.oracle.com/javase/specs/index.html

https://openjdk.java.net/jeps/1

C only became standardized after 20 years or so, and only out of necessity because there were different compiler toolchains moving into different directions and this ensuing chaos had to be brought under control somehow. And arguagbly the standard is just as much a problem as an advantage (look at all the very useful extensions in clang and gcc which will never make it into the standard, and the C standard libary is still essentially a snapshot of what was already the least common denominator in 1989, and far from the "state of the art" even back then).

As long as a language only has a single implementation or "reference compiler" (like Rust), standardization only adds needless bureaucratic overhead.

> C only became standardized after 20 years or so, and only out of necessity because there were different compiler toolchains moving into different directions and this ensuing chaos had to be brought under control somehow.

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 takes a couple of decades before a language has stabilized enough and gets popular enough to spawn multiple competing compiler toolchains. And before all that hasn't happened a standard makes no sense.

> My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser.

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.

There are fields such as automotive and aerospace where absence of Rust's standard is a showstopper for using Rust. Those areas require that all tools that are being used to build software must be certified (ISO 26262 for automotive for example) to ensure that software is safe to use and doesn't kill anybody. And nobody would do that for a language that adds new features every 6 weeks, because such certification is a long expensive process which you have repeat every time when the tool changes.

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.

> There are fields such as automotive and aerospace where absence of Rust's standard is a showstopper for using Rust.

"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.

> Usually hundreds of million lines of C/C++ power modern vehicle.

And I find that highly problematic. If anything, Ada would be a much better choice for these safety-critical applications.

> 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?

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".

> to the detriment of the primary product they're developing

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.

Maybe we're really talking past another, but for example, last week's announcement for Servo's new home page reads

> 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.

[1]: https://news.ycombinator.com/item?id=25125325

Yeah, I think we are.

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.

> 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.

Why would you say Rust is bad for kernels and drivers? Asking this because I am curious, not as an argument.

I would also be interested if there's any specific reasoning there, especially because there's an effort to get rust supported as way of writing kernel modules in linux, a pretty dogmatically C (though not standard C) codebase. I am personally very exciting for rust's potential in low-level embedded applications.

My day job is doing embedded rust, with kernels and drivers. It works great.

Reply on news.ycombinator.com