8 is even stretching it, May will be four years since things have actually been stable. Even that was the minimum we could provide guarantees for.

Rust is much more complex than C, it is not even in the same sphere of usage. A language like zig could be a decent C replacement.

On the other hand, Go has a very readable specification that was written early and is maintained to always be up to date.

Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline.

> Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline.

It's not that, it's that we take the idea of a spec very seriously. We want to have a spec that's extremely solid, and so there's a lot of foundational work that needs to be done first. That work has been ongoing. Not all specs are created equal, and good ones take a lot of time.

For comparison, C was created in 1972, and the first specification happened in 1989.

Okay, but this seems like letting the perfect get in the way of the good? A maintained, readable, informal spec should be quite useful as a starting point for writing a more formal spec later.

It need not be definitive. It would be quite reasonable to point out areas that aren't nailed down yet - this is also useful for the reader.

What do you want out of an informal spec that isn't provided by "The Rust Reference"[1]?

[1] https://doc.rust-lang.org/reference/index.html

It's useful but I'd like to see a bit more top-level completeness. Every feature should be listed and have at least a cursory description, even if it's not entirely nailed down.

(Maybe it already is like that, but the disclaimers say it's not.)

The vast, vast majority does, but there may be some missing bits. Printed out, it's about 170 sheets of paper, so there's a lot there.

Borrow checking rules.

I don't know what the current state of affairs is, but this is something they have rightly delayed specing. The original borrow checking rules were quite byzantine compared to what we have today.

I don't know if there is active work going towards making them more relaxed (NLL landed I believe). However, a ton of work has happened to get them out of the way as much as possible.

That's what the reference is, and it's there for exactly that purpose.

The Rust team adopted a rule in December 2016 saying that all new language features must be documented in the language reference before landing on the stable release branch:

https://github.com/rust-lang/rfcs/blob/master/text/1636-docu...

As far as I can tell after adopting the rule they didn't proceed to enforce it.

It's more complex than that. From a development standpoint, doing it this way was a real pain. This is due to the reference being in a different repo than the change itself.

We decided to relax this rule last year, and so instead, issues need to be filed. They then get filled in after. This has its own set of drawbacks.

Its not unreasonable to expect Rust to have looked at history, and improved upon it. To start out less than C means what? We don't want to wait 50 years for another language to 'mature'. Why can't it start out as good as, or even a step ahead of what came before?

That may be the source of the disappointment surrounding deployment of Rust - why is it behind and not ahead of other tools?

That doesn't make any sense. What do you mean "less than C"? Rust definitely looked at history and improved upon it, that's the whole point of the language! The author's gripe was that they feel Rust is evolving quickly much beyond C (like C++), not that it's trying to catch up on C. And do you really expect a language to just appear one day, fully grown, like Venus from a seashell?

The author's opinion of Rust being less is that, an opinion. It does have large advantages over C: memory safety, an incredibly powerful type system, a compiler that supports detailed error messages, a powerful build tool (Cargo), an expressive macro system, etc.

Others who have built applications with Rust seem to be coming away with a much different impression that the author. He does mention some gaps (lack of a spec, unstable ABI) but these are not hardstops for all usecases. The main thread of complaints appear to be from lack of choice of tooling and compilers.

I'd wager that the advantages outweigh the drawbacks for many projects, though not all.