Hacker News Reader

>> The only way to do this properly, if desirable, is to make GCC an official backend of the main frontend. That will defocus some progress that happens with LLVM (every feature has to be implemented on both backends) and can make dev lives hard (eg “oh this problem comes up with GCC so use the LLVM backend “)

No. The correct way is to create a Rust language specification that describes what the correct behavior is.

Then whether LLVM, GCC, or something else is used does not matter. There won't be one implementation with defacto behavior, there will be multiple implementations that follow the spec.

This is the way mature languages work.

It doesn't even have to stop progress. C++ does a new rev of the standard every 3 years. Rust has editions, which is a similar but less rigorous concept, and which could be made more rigorous.

Exactly. The C++ standard (https://isocpp.org/std/the-standard) is the specification that describes what a compiler must do to implement a particular "version" of C++ (for example, C++ 20).

Just as there is a C++ standard and multiple C++ compilers that implement the standard, there should be a Rust standard and multiple implementations.

This is the way that mature languages work.

This is the way that very few languages work. Python is a great example of an extremely popular, mature language that does not work this way. It is unclear that most people think that this sort of process is required for “maturity.”

If this is the benchmark, then among popular languages you basically have C, C++, C#, JavaScript, and... is that it?

I wouldn't say it's a benchmark, but surely Pascal, Fortran and COBOL (to name but three) are all standardised?

There are more languages that have standards, sure, but the languages you mention, at this point, and in general, are mostly relegated to historical maintenance and maybe some very specific niches. To me personally, a “mature” language that’s not really being used isn’t the goal. And if developers truly believed standardization was valuable, you’d expect this property to give them a significant leg up against the sorts of languages like Ruby, Python, PHP, Perl, TypeScript, etc.

That being said, I do think, considering it longer, there are languages that I am missing, like SQL, and ones that have a spec, even if it’s not under an ECMA/ISO process, like Java and Go, that I was forgetting.

I still think that using this as a necessary condition for “maturity” is misguided.

Well, I agree that standardisation and "maturity" (whatever that may mean) are not connected, but I think most C and C++ programmers (to name two very widely used languages that I personally have a lot of knowledge of) find the respective standards for those languages very helpful, and somewhat lament the lack of formal standards for other languages they may use.

Yes. I do think that standardization is generally good. I am pro Rust getting a specification! I just think it is one pro among many, and not something required for success.

The C and C++ specs are full of UB though, more like a "minimum common denominator" for compiler devs than a strict spec that users can rely on. It's way too easy to write spec-abiding code that behaves differently with different compilers/architectures/optimizations.

Specs are definitely a good thing to have, but often they're just brandished as a bullet point without looking at the details: how good is the spec, what does it add over the existing tests/CI/RFCs/proofs, etc.

In a past life I worked on a COBOL compiler for IBM.

There is a COBOL specification, but AFAIK nobody actually implements it fully. Implementations pick and choose new features based on customer demand.

Also, COBOL is dominated by large legacy codebases, which means that if there's a discrepancy between an implementation and the specification, the users normally don't want it fixed, because they may have written code that depends on the "incorrect" behaviour and it's a lot of work to audit.

IBM built a new backend for its COBOL compiler using the optimizer from their JVM. IIRC by the time I left it generated code that was ~2x faster than the old compiler, but uptake was still slow because of migration concerns. In particular, we spent a lot of time working on features to help guarantee that code with some forms of undefined behaviour would have the same result as the old version.

The other languages without a spec don't market themselves a C/C++ replacement or as systems languages.

Having a webapp depend on a CPython implementation detail is very different from having a kernel depend on an implementation detail of a language without a spec that was used to implement it.

And languages actually stack on top of each other. Imagine depending on a CPython implementation detail that depends on an implementation detail of a specific C compiler. Those things do happen and they make programmers' lives miserable sometimes, but imagine how often that would happen if C didn't have a spec that all compilers strive to implement.

Linux uses GCC extensions. So the Linux kernel depends on the implementation of a compiler already.

Those are intentional deviations from the standard, and I think there's a reasonable assumption that those stay the same/compatible from version to version. I think the other kind are a bit more problematic, and without a standard it can be difficult to tell whether your assumptions are reasonable.

Sure, and people in that space do care more. But it's clearly not a blocker, even for the stuff you're talking about. It's not a hard requirement to get Rust code into Linux, for example. (Not to mention what my sibling talks about, which is very much already true.)

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

Ada, Fortran, Cobol as well.

This is specially relevant in the industrial sector with certified compilers.

Such standardized specifications are typically a response to many divergent implementations existing and a need to standardize a common ground between them.

Few languages find such specification before that time.

Python also lacks it despite some competing implementations, since none actually diverge enough from CPython.

PyPy famously diverges from it a lot (namely for native modules).

Standardization is helpful for tool building and experiments (ie here are the invariants we’ll never change). Languages don’t work that way and seeing how C/C++ have evolved (or really failed to do so at a meaningful pace), I’m under the impression (clearly unpopular due to the downvotes) that standardization and multiple competing tool chains are the cause of a lot of unnecessary complexity (not just within the language but also users of said language).

Having multiple independent implementations (and a spec) is key to being a serious portable systems language, a claim that Rust already makes. I believe it's too early for that, but sincerely wish them success achieving those goals in the future and having multiple implementations is certainly going to help here.

> eg “oh this problem comes up with GCC so use the LLVM backend “

The point of having multiple implementations is making the language independent of the underlying system. A programming language is an abstraction. The only way to test whether an abstraction is a good one is trying out how well it abstracts away various underlying systems. That's why Rust needs ports to various architectures, OSes and compiler backends. Having GCC as a backend counts double here, because you get a few new target architectures for free with the port not just a new backend.

It's of course much different with Python but I can still clearly see how having an implementation defining a standard hurts the language.

Strongly disagree. It will only benefit the language to have more than one quality implementation. C++ has benefited hugely by the competition between g++ and clang; both compilers have gotten much, much better. To be fair, it will take a while before the GCC Rust front end is competitive, but for some purposes it doesn't have to be, like bootstrapping.

If "progress" means "rapidly add more and more new features in each release", multiple implementations will slow things down. But that problem can be addressed with editions: at some point, if the project is a success, the gcc front end will be a feature-complete version of some Rust edition, plus enough extra features to build an older version of the Rust compiler. At that point, you have a better solution to the bootstrapping problem (how to get a Rust compiler when you only have a C compiler and you want to build everything from source and not trust some binary you download from somewhere).

> C++ has benefited hugely by the competition between g++ and clang; both compilers have gotten much, much better.

yet rust has a single implementation and by some metrics does better than both.

Compilation speed isn't one of them though.

>If "progress" means "rapidly add more and more new features in each release", multiple implementations will slow things down

This has to happen at some point anyway otherwise we'll just get another C++. And I don't think Rust would benefit from that. New languages are designed to fix problems with the old ones, not to replicate them after all.

I just hope the designers will choose that point wisely.

In some extent, given the use of macros and Haskell like libraries, it is already another C++.

Besides, if Rust doesn't become another C++, it won't fulfil the industry needs that C++ caters for, thus while it might become a success in some domain, it won't replace C++ in the OS and GPGPU SDKs.

Rust will not in any case replace C++, in any core application area.

Rust might move in alongside C++, in some, in time. Or, Rust could still very possibly fizzle. That would be the normal course of events for a new language, barring a miracle as was dispensed to Javascript, Java, C++, and vanishingly few others.

Will Dart survive and thrive? Kotlin? Scala? Clojure? Go? All doubtful, based on prior experience. Having a lot of code and a lot of users does not seem to suffice. Many other languages had those, and faded. Ada even had $billions in backing, and faded.

What we can say confidently about Rust's future is that it is not certain to fade. The miracle has come in less deserving cases.

> Ada even had $billions in backing, and faded.

Yet, NVidia picked it up over Rust, go figure.

> otherwise we'll just get another C++.

I don't see why this is a bad thing. I'm a C++ developer, and I like C++. (I like rust as well)

> It will only benefit the language to have more than one quality implementation.

As long as "quality implementation" means "implements the entire Rust language and not a subset".

Because otherwise, people will start getting requests to avoid using features that the non-standard Rust toolchain doesn't support.

Remember that Rust is supposed to be an alternative to C or C++, where the "this problem comes up with GCC so use the LLVM backend" is really rare and generally a sign of a bad codebase (exceptions being things like the Linux kernel that are so huge, optimized and domain-specific that they often end up relying on compiler dialects).

One exception to this is Visual Studio's toolchain but let's not talk about Visual Studio's toolchain on a weekend...

Yeah, when one forgets that there are more C and C++ compilers out there in the industry than just the pair that the FOSS community cares about.

The general sentiment of the community and leadership is that this project is a good thing, so you are unlikely to get your wish.