You're welcome :)

I also think that year-from-now Rust will be way nicer than at the moment, it's absolutely early days. But there's a lot you can do, even on stable, right now. This is why I said it depends on what you're doing. Some use cases have absolutely no choice but to use unstable things. Others have options, and others only use stable.

As to your three points:

1. You can configure things so that you only need nightly when doing benchmarking, and run on stable the rest of the time.

2. Compiling `rustfmt` needs nightly, but using it doesn't, as it's a binary.

3. Yeah, the SIMD stuff just happened, so it's gonna take some time.

It would be good if the core Rust team owned `rustfmt` the way the Go team owns their extremely opinionated format tool. It heavily enforces very consistent code formatting throughout all publicly available Go code.

Developers like to say they want choice when it comes to formatting, but take it away and you're left with resigned programmers who are very productive at reading code.

^^ Perhaps not the right outlet for this, but maybe you can point me to where this discussion is taking place.

Yes, our intent is to officially adopt rustfmt, and we expect that it will be widly used. It's just not ready yet. nrc, who's leading up the work, is a Mozilla employee, and in general, everyone wants it to be ready. Software just takes time :)

The first two are developer tools. It's fine to have to use nightly at dev time (better, in fact, due to compile time improvements!), and then ensure your build works on stable too.

Also, rustfmt is a binary which can work without nightly once you've compiled it.

Rust's users are all developers so there's no distinction between expert and novice users.

I built rustfmt with nightly Rust and it dynamically links all kinds of shared objects from the Rust install. This doesn't happen for a simple hello world so there must be something different in rustfmt's build.

There is an important distinction when it comes to stability. Stability for libraries is much more important that stability for devtools

Stability mainly matters when you release a library and it stops working on a newer compiler, breaking everyone downstream. That's a pain for the downstream users, because they need not necessarily understand your library internals, and the software they're building will be completely broken until you update it.

If an optional developer tool breaks, it's only you that's affected, not downstream users. You can wait for it to be fixed, no problem.

Rustfmt uses internal Rust APIs to parse and reason about the code. It could use something else (like syntex), but that would be more work.

Can't rustfmt avoid dynamic linking?

Actually, I'm surprised it does link dynamically, since Rust binaries are typically statically linked. But yes, it should be able to avoid that.

Won't nightly be the new stable in about ~15 weeks? That is pretty damn amazing. Using multirust [1] makes it easy to track (cargo,rust) for stable, beta and nightly on a per directory basis, super handy.

[1] https://github.com/brson/multirust

Current nightly will be stable in 7 weeks, actually, there's a release a week from tomorrow.

That doesn't mean that everything that's available on nightly will be available in stable in seven weeks, of course. Everything lands as stable and then is made stable at some point in the future, at least one full cycle after it's landed. There's lots of pre-Rust 1.0 stuff that's still nightly-only.

Thanks for the clarification. Makes a ton of sense.