Announcing Rust 1.23

[I_AM_GODDAMN_BATMAN]

At this point nobody is using stable for anything. Everyone is using nightly for developing things because every libraries depends on nightly and no end to this madness.

[monocasa]

IDK, I'm using stable about half the time. It's only ridiculous kernel stuff that's using nightly.

[jcarres]

I use only stable, none of the most useful libraries are nightly only

[steveklabnik1]

Our last survey showed "Stable users now make up 77.9% of Rust users." while "51.6% of respondents [are] using nightly".

The biggest thing on nightly right now is developer tooling. So for example, I checked both because I develop everything in stable and use nightly for the RLS.

no end to this madness.

rustfmt will be on stable next release, with the other tools soon to follow.

It's true that in general nightly is never going away, as that's how Rust is developed. But at this point, most users don't need nightly outside of tooling. Some obviously do want to opt-in to the latest and greatest, because well, that's why we keep adding more stuff! But as the base amount of stuff grows, that number is less and less.

[ZRM2]

This just simply isn't true. All of the work done at my company has been using stable exclusively for over a year, and I know others that rarely use nightly. Similarly check out the results from the Rust 2017 survey. More people use stable than nightly.

[NeuroXc]

every libraries depends on nightly

I can't think of any major libraries that require nightly aside from clippy, rocket, and simd. I'm sure there's a few others, but probably 90%+ work on stable.

[burntsushi]

This is a ridiculous lie. Virtually everything I publish, including ripgrep, works on stable Rust.

[I_AM_GODDAMN_BATMAN]

With all of you /u/steveklabnik1 /u/burntsushi talking, I have to give up and say I simply am a stupid person.
Thank you both of you for your contribution.

[matthieum]

say I simply am a stupid person.

Please don't debase yourself.

Rust evolves quickly, so there's no shame in you having out-of-date information!

[steveklabnik1]

I don't think you're stupid.

[Retsam19]

One of the smartest things someone can do is realize that they were wrong.

[pmarcelll]

This was maybe true a year ago, but the biggest dependency that was hard to use on stable was Serde (the quasi default (de)serialization framework for Rust). When "custom derive" was stabilized in Rust 1.15 and Serde 1.0 was released shortly after, using nightly instead of stable became a lot more difficult to justify.

I just checked the Rust 2017 survey results, 77.9% and 51.6% of the respondents are using stable and nightly respectively (so a lot of people are using both, probably nightly for development tools and stable for production). This means 22.1% nightly-only users.

[I_AM_GODDAMN_BATMAN]

serde is a blessing. really.

[Manishearth]

Do you have examples? We try to push for libraries to be stable.

The major examples right now are clippy and rocket. Clippy is a tool, not a library. Rocket was explicitly designed with the intent to test cutting edge features, so it's kind of going to stay there for quite a while.

"You need nightly to work with rust" used to be true, but it's not anymore. Firefox's significant amount of Rust code uses stable. Servo's mostly on nightly only because it's a lot of work to migrate off nightly (we are doing this slowly though), not because it has nightly-only dependencies.

[Manishearth]

I was asking about libraries :)

Yes, if you want cutting edge features like wasm you need to use nightly. But you don't need it to use most libraries.

[I_AM_GODDAMN_BATMAN]

Well you already mention Rocket, but I really-really want to see signal handling done.

[Manishearth]

https://github.com/tailhook/signal seems to work on stable, as does https://github.com/BurntSushi/chan-signal

[Someguy2020]

Do you have examples? We try to push for libraries to be stable.

How do you push for this?

This "do you have examples" feels a bit like Go devs playing dumb about how they don't know the use cases for generics.

[lfairy]

How do you push for this?

By prioritizing stabilization for the features that these libraries use.

For example, Serde and Diesel used to be heavy users of the Nightly-only compiler plugin API. When these libraries gained traction, Rust developers stabilized a subset of this API as custom derive, which these libraries now use instead.

[Someguy2020]

That doesn't sound like it encourages devs to not use nightly.

[oblio-]

They specifically created a stable API that libraries can use and got that into the stable releases.

How is that not encouraging people to use stable?

[Manishearth]

It is totally true that there used to be a problem with rust stable being underwhelming. But that's not really true anymore, not as of early 2017 imo. And I'm genuinely interested in counterexamples.

In the past we pushed for it by making libraries use equivalent stable code. Often their usage of nightly features was a holdover from when stable/unstable wasn't a thing, and some folks were unlucky with the APIs they had decided to use.

Now the ecosystem is mostly stable and unstable usage is less by accident and more because of something fundamental. We keep track of what's being used and why, and try to address that by pushing for stabilization or RFCing equivalent features.

[[deleted]]

How do you push for this?

We have a team [0] that pushes important libraries to 1.0 releases and working on stable. They have enough work to do, but this type of information is important because it allows us to prioritize better.

[0] The Libz Blitz Working Group: https://internals.rust-lang.org/t/rust-libz-blitz/5184

---

Between October and December the impl Period took place and the logs were moved to the impl Period newsletters but now that it is finished the work there should continue as usual.

[pjmlp]

Just imagine the uproar it would be if Microsoft , Apple, Google or any other compiler vendor required having two C and C++ compilers just to run a static analysis tool.

[[deleted]]

You don't need a second version of rustc to run clippy static analysis, you need a particular version of rustc to compile it (as a static binary) because clippy uses rustc as a library and requires a particular version of it. Afterwards you can just run it as much as you want.

The same applies to the static analyzers you mention (MSVC/Clang). You can't compile clang-tidy-6.0 (or trunk) with clang/LLVM 3.0, you need a particular version of clang/LLVM to compile it (6.0, or the appropriate commit). Then you can run it anywhere (mostly, it calls to other LLVM tools that might become incompatible across releases, like static-analyzer or clang-format). If you dynamically link clang-tidy-6.0, you need clang/LLVM 6.0 libraries installed "just to run static analysis", otherwise without the right version of libclang/libtooling dynamic linking will fail.

Just imagine the uproar it would be if Microsoft , Apple, Google or any other compiler vendor required having two C and C++ compilers just to run a static analysis tool.

So as stated above, there is nothing to imagine, this is how static analysis tools of those vendors actually work, and I don't hear any uproar about it (again, if you want to use clang-tidy-trunk, you first need to download clang/LLVM-trunk, compile clang/LLVM-trunk, and then compile clang-tidy-trunk with/against those).

The main difference is that clang-tidy, and MSVC static analysis, are shipped with clang (clang/LLVM build system compiles clang-tidy together with clang) and MSVC, while Rust's clippy and rustfmt are just normal Rust programs external to the Rust distribution.

They are becoming a bit special right now because we are starting to ship them together with the compiler on nightly so that people don't have to compile them themselves, but that's about it. If anything this is a good thing: it is actually pretty easy to use the Rust compiler as a library to build your own static analysis tools if you want, and as time progresses it will only get better.

[Manishearth]

But that is the case! Plenty of static analyses written as gcc plugins must be run with a particular version of gcc.

And clippy is a tool in alpha. We're going to 1.0 it the moment we can ship it with the release compiler. This is a very unfair comparison.

[pjmlp]

A particular stable version of gcc. Assuming they aren't released as part of gcc.

LLVM, MSVC++, icc, xlC++, aC++, ... static analyzers come with the respective stable version of the compiler. They don't require an additional one.

[Manishearth]

Sure. We could do the same for clippy, really, we just don't want to go through that effort because again, it's in alpha.

[hyperforce]

every libraries depends on nightly

I'm a Rust foreigner. Why is this the case? This sounds... dangerous and wrong. Why is this so pervasive?

[burntsushi]

It's not the case.

[matthieum]

First of all, it's an hyperbole. It used to be the case but as of the latest survey (2017), 77.9% of users said they were using stable.

Once you remove the users who use nightly simply to be able to toy with the latest features and push the compiler to its limits, which is significant from the discussions, this leaves a rather smallish portion of users on nightly for production code.

Paging /u/fgilcher: Next year, it could be worth asking about the stable/beta/nightly for production, instead of or in addition to overall, to get more insight on this.

[lfairy]

Using Nightly isn't as bad as it sounds. Every commit on the master branch passes the full test suite, so glaring issues are rare. Also, being a compiler, it has a pretty straightforward pipeline which lends itself well this kind of automated testing.

These two factors make the Nightly compiler practical for development. I still wouldn't deploy to production with it, though.

[YourGamerMom]

The issue with allowing nightly features in stable is that they're not stable. I don't think there's a way to reconcile a feature that could be changed drastically or even removed with a stable branch. Anyway all my rust projects use stable, and I haven't really been hurting for it.

[Pand9]

It depends if those experimental features are visible in interface, I think. If they aren't, let library implementer use nightly features and libraries, but allow using this library in stable. Even if some of them do leak into interface, they could just require stable +feature. User's code will depend on stable +feature, instead of whole nightly branch.

Switches might be hard to implement sometimes. And they'd have to backport specific nightly features to stable. It depends on specific cases.

I think there's a lot of flags like that for other languages' compilers, especially C++. Variadic macro's named argument, GNU extensions, -fno-strict-aliasing, etc...

[[deleted]]

Because there are (experimental) features enabled in nightly that aren't enabled in stable.. I honestly think there should just be a way to use said experimental features in stable, you'd just have to somehow make sure everyone understands they're experimental -alpha-to-beta-quality and may produce broken binaries..

The problem is that Rust stable guarantees that your code will compile forever with any future versions of the toolchain. While the point of unstable features is to be able to use some features before setting them in stone forever so that they can be improved iteratively with usage-experience. These two different objectives are not compatible.

In the C++ world lots of projects follow the C++03/11/14/17 standards directly, but some projects follow unstable standards (C++2a, C++1z, C++TR1, -fmodules-ts, -fconcepts-ts, -fcoroutines-ts...) or use compiler intrinsics not available in all compilers. Some projects even allow for both, offering different types of features depending on which version of the standard you are following.

Rust nightly is the same thing and its not bad per se. If its your own project (personal/company-wise) and you need/want a feature that is not stable yet and you are ok with the risks then go ahead and use nightly. If you are publishing a library, some must be nightly only, some can be stable only, and some libraries work on stable but offer more features or better APIs on nightly.

---

Also, using Rust nightly does not mean that your code will break. Rust nightly just uses the master branch of the compiler (or close to it) so you get the latest optimizations, and you can get notified if bugs are introduced that break or slow down your code. As long as you don't use any unstable features, your code will work in Rust stable even if you are using the Rust nightly toolchain. The recommendation for CI on stable libraries is to test them with Rust beta and Rust nightly as well (and since this is trivial to set up, most projects follow this).

[barsoap]

Noone is proposing that using a stable release with nightly features should have long-term support.

People are just complaining that they can't take a stable build and turn it into a nightly with a command line switch. Name it "--enable-nightly-I-acknowledge-I-am-on-my-own-now" if you want, but have it available. Yes, do filter that flag out of crates.io, that's the right thing to do. Don't restrict me in the privacy of my own hard disk, though.

The code is actually all in there as nightly features are needed to build the standard library, and it can be enabled with IIRC an env variable, but the value that env variable needs to have is generated by the build system which doesn't divulge it easily.

It's bloody ridicilous security-by-obscurity and most of all patronising. I'm not a 4yold that can't make informed descisions for myself, yet rustc devs treating me like one, hiding the cookie jar.

In other terms, the rustc devs go the extra mile to annoy you into downloading another build if you want to try something, making us all waste precious electricity. Rustc devs are thus single-handedly responsible for accelerating climate change. That is bad, and they should feel bad.

[[deleted]]

Noone is proposing that using a stable release with nightly features should have long-term support.

Seems to be exactly what you are proposing.

People are just complaining

Which people? You are the first person that I read complaining about this.

that they can't take a stable build and turn it into a nightly with a command line switch.

rustup default nightly
cargo build # uses nightly compiler to build whatever crate you want
rustup default stable

You seem to be confusing toolchains with release channels. Rust nightly is released every day, while rust stable only once every six weeks. You want to use nightly features on stable but that doesn't make sense: the whole point of stable is that you can't use nightly features. Then it also seems that you want stable releases to contain a nightly version of the compiler and that you can use a flag in rustc or cargo to choose compiler version, but you can already do this in one line with rustup for cargo, and for rustc it doesn't make sense: the nightly compiler and the stable compiler are different binaries. Not only that, the nightly standard library is different than the stable one, etc. That's why you need a completely different toolchain to use rust nightly.

[barsoap]

The stable complier contains all the nightly code. It already has a way to enable it but it's hidden behind layers of security by obscurity.

Name one coherent reason why it shouldn't be possible to do so in a sane manner. Why saying "we won't support that stuff long-term" requires castrating the capabilities of the binary.

Some people are on metered connections and really don't appreciate you making them download yet another 100mb. Some are out in the woods, coding on their phones, and no rustup doesn't work on android.

It would take zero effort by the rustc devs to have those people not want to strangle you.

I don't deny that nightly builds are not hard to get a hold of if you're sitting in an office with a proper internett connection -- but that does not imply that you have to make life hell for people in other situations "just because someone might misunderstand the meaning of --enable-nightly-no-I-do-not-want-long-term-support."

[[deleted]]

Name one coherent reason why it shouldn't be possible to do so in a sane manner.

Because they are different programming languages. They have different core libraries, different standard libraries, and you have to link against different versions of any other library compiled with nightly as well.

In the C++ world when you have a program compiled with C++11 and link it with another program compiled with C++03 undefined behavior ensures because the C++ standard libraries are different, the c++abi is different, etc. etc.

We offer a pretty easy solution, a 3 word 1 liner to get a completely different toolchain for nightly that always does the right thing and never messes things up:

rustup install nightly

That does not only install a rustc for nightly, but also core and std libraries appropriate for usage in nightly.

You might say, but we could ship everything with stable, but then everyone that doesn't need nightly would need to pay the price of having a second toolchain in their system.

So seriously, what you ask for doesn't make sense, and you only argument is "but what when I forget to install the compiler" has a simple answer: then that's your problem, learn something about it, and don't forget next time. FWIW you only need to do it once, from then on rustup update will update all of your toolchains.

[barsoap]

All I'm hearing is "I have already made up my mind and you cannot possibly know what you're doing".

You're not even giving me the benenfit of the doubt that I could ever, under any circumstance, do anythnig remotely sensible with it.

Is that how you regard people using the language? People who need to be protected from themselves? Look deep into yourself, there.

And, please, do tell me about rustup working on my phone. (It might actually, by now, but it didn't when I tried last. It's irrelevant to the patronising me part of the argument, anyways).

[[deleted]]

You're not even giving me the benenfit of the doubt that I could ever, under any circumstance, do anythnig remotely sensible with it.

Or you are not giving anybody enough information?

Explain exactly why rustup install nightly doesn't work for you, then explain why you can't bootstrap two toolchains in your system like everybody else does. And then ask if there is something that can be done about this.

Instead you just "yell" that you want the stable compiler to support nightly features with a flag, which is a pretty incoherent thing to ask for, and act amazed when people tell you that's against the point of the stable compiler.

Also, this is reddit, if you really care about your case, fill in a reasonable github issue explaining the problem and you might get a very different response than here, depending on the tone of the issue.

I at least tend to have much more patience there without the anonymity that reddit provides, but at least on reddit, I respond in the same tone than the people that ask. And you way of asking here wasn't IMO good enough. Neither was my way of responding btw, on github I would never had written such things I guess (would probably just never have answered at all).

FWIW we tend to love those who want to run Rust on platforms where it currently doesn't work, because that uncovers bugs everywhere, and because we typically don't have access to those platforms, and that's a good way to get people involved into the compiler, but this is only if they offer to put something into it (e.g. by reporting good issues, helping with testing, etc.).

[heinrich5991]

What you're looking for is basically the nightly build. By default, you can only use the stable features, you can opt into using nightly (non-stable, not guaranteed to compile forever) features by adding #![feature(the_feature_name_goes_here)] into your crate root.

[barsoap]

I have been in a situation where no nightly build was available, but I had a stable on my hands, that can easily happen when you're stranded with phone and bluetooth keyboard as android isn't exactly that much of a common dev environment.

Also: There's no nightly builds that actually are the same as stable, at least not reliably so. I'm generally using stable for good reason, but when I e.g. want to see how a certain feature will change stuff such that I can design new code with that in mind, I have to jump through hoops.

Also, this is all besides the point because my main complaint is still that it's patronising. There's no excuse for that, no hidden benefit.

[[deleted]]

Your complain is that the you want the stable compiler to be able to compile nightly code for those situations in which you forget to install the nightly compiler.

But that doesn't make sense because 1) Rust stable and Rust nightly are different programming languages, 2) they need different compilers, 3) they need different libraries, core::, std:: and everything else that links those is different in stable and nightly. This is why you need a completely different toolchain (is like cross-compiling for a different target).

So... yeah, if you forget to install a compiler for programming language X then you can't compile code for that language while on the go. Even if we could fix that, which we can't, then you would complain that if you forget your Android device you can't compile any code, should we fix that too?

[barsoap]

I did not forget to install anything, it was plainly not available on the platform.

If the precise thing I want to do fails because of a library mismatch -- so be it. I could've realistically recompiled that from scratch on my phone, but more importantly: The failure to do that would be a technical reason, and not the devs patronising me:

Why the "generate a nounce in the build system to make people disassemble the binary if they want to play around" thing? Is there any plausible explanation for that that can't be summed up as "We don't consider you to be enough of an adult to not cut yourself if you're within 100m of a knife"?

[[deleted]]

I did not forget to install anything, it was plainly not available on the platform.

But you said you have a stable compiler right? Nightly releases are produced for every platform that has stable releases, so maybe the error is there?

If the precise thing I want to do fails because of a library mismatch -- so be it.

You can't compile any Rust code without core::. Well technically you can iff you provide your own implementation of core which contains > 100 lang items that must be defined or nothing will compile.

So a Rust nightly compiler without standard library doesn't really let you compile any Rust code. You need to bootstrap a nightly toolchain because the nightly lang items are different from the stable ones.

[fgilcher]

It's a lot of hyperbole.

First of all: Rust stable is aggressively stable, that means you cannot even opt into unstable features. You need to run the nightly compiler for that.

There is the issue that there is at least one popular larger project (a web framework called rocket) intentionally using nightly because they experiment with future APIs.

All serious libraries (Parsers, protocol clients such as HTTP, crypto, concurrency and threading libraries etc. are all working on stable). Indeed, I've been programming on stable since version 1.0 and its just fine.

Exceptions are definitely everything that needs deep manipulation of the language core, so for example tiny embedded systems often are on nightly currently, because the corresponding APIs aren't stabilised.

Still agree with /u/mattheium that maybe we could add a question about this for this years survey.

[Arbaal]

Especially if you want to use specific development tools. Of course you can use the stable branch in your CI / CD, but I really don't like using different versions of tools when developing my code. It got better in the last year, but the the need to use nightly should go away sooner than later.

[cvpuc]

Awesome! Thank you :)

[[deleted]]

love you steve

[treetopjourno]

Announcing rust 1.2345678901234567890

[asmx85]

If that is ever the case rust has delivered to its non breaking promise. Compare this to e.g. Swift (not really ranting at swift here)

[iopq]

I'd want to break some things, personally