Hacker News Reader

Comment by skybrian | Hacker News Reader

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.

View on HN

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

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

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.

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.

Reply on news.ycombinator.com