Stable project structure is a requirement to survive as an enterprise language, which everyone tries to make it into. It can live with the forks, but only as a toy language.
C++ survives having a GCC variant and a MSVC variant, not to mention whatever half-broken compiler you used to get for your microcontroller code.
I would argue the requirement is that each compiler is a stable project. But one language can have multiple compilers that aren't 100% compatible and implement slightly different subsets of the language (as long as there's a common subset libraries can choose to stick to)
C++ has an ISO standard, for better or worse. That's a different beast. Rust is defined by the implementation. Any hope for interoperability between potential adverserially competing forks is just wishful thinking.
Hopefully Ferrocene can lead to Rust itself being standardized.
To me, it seems inevitable that there will be multiple implementations of Rust, especially if Rust continues to be more widely adopted and used in new domains.
I would also not be surprised if Rust were to adopt optional language extensions for specialized use cases, similar to Ada's language annexes:
Why? Because the Rust implementation you use for video game programming does not need all of the same features as the Rust implementation that you use for safety-critical embedded systems (for example: railroad control software).
I'm involved in the Ferrocene project (1), so I'd like to clarify some things about the Ferrocene Language Specification. It is deliberately called Ferrocene Language Specification and not Rust Language Specification. The specification serves first and foremost the needs of the Ferrocene project - we just need a spec to certify the compiler. It may be useful to others, that's why we open sourced it.
It is not a specification that standardizes rust or prescribes any behavior to the compiler. It's a specification that describes certain aspects of the behavior of the existing rust compiler. It's neither comprehensive nor is intended to be. It follows the changes in the compiler. If there's a mismatch between compiler behavior or the spec, the spec is considered faulty. It is also not sufficient to write a new compiler based on the spec.
As such, Ferrocene is not an effort to standardize rust. We consider the Ferrocene project a certified downstream of the rust project. Any push to standardize rust would need to come from the rust project itself. We have not intention to create any such standard.
That said, there is some interest in building a specification for the rust language in the project itself - here's the relevant RFC https://github.com/rust-lang/rfcs/pull/3355
Precisely. The naivety on display here about the realities of long term software development is absolutely astounding, especially for a project with such lofty goals. Keep your dirty laundry out of the public eye if you really care about Rust.
I agree with you on the “realities of long term software development”. But I think I believe there is a fundamental difference between the standard realities on a successful enterprise project and the language itself.
That is, the latter needs to balance the needs of a much, much wider array of customers (all rust compiler users) versus the former with a more specific target user base.
This introduces different requirements. Changes are far, far more likely to be permanent for example. Which means that the discussion around decisions needs to be different.
If you can't resolve that conflict of interest then you have absolutely no business being near the seats of power for a project such as Rust. Rust needs to be perceived as a safe bet, not as the next Ruby, if it is to achieve the goals that have been put forward by those that advocated for the language's adoption.
Perhaps, but it does need to be enterprise level (with all the things that come with it) if you want to be used by enterprises and high-grade projects like the Linux kernel. Many in the Rust community have explicitly stated that they want those type of entities to start using Rust, so being enterprise level is therefore a must-have.
I would argue the requirement is that each compiler is a stable project. But one language can have multiple compilers that aren't 100% compatible and implement slightly different subsets of the language (as long as there's a common subset libraries can choose to stick to)