so,here it is:
Google backs Go.
Apple backs Swift.
Amazon is trying to back Rust.
Edit : What I am trying to say is that Financial Backing and adoption by FAANG companies can really improve ecosystem of Programming language. I am not here to tell that it will be product of certain company.
And that's why languages such as C and C++ are not a reference implementation from a vendor but an international standard.
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.
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.
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 " 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.
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