Allow unstable features in 1.0

[mahkoh]

Partially revert "Stability as a Deliverable" by allowing users of the stable
compiler to opt into unstable features and standard library functions.

Rendered

[brson]

This RFC is in very bad faith @mahkoh. It is an utter troll. Please consider how your attitude affects others.

[mahkoh]

@brson There are much easier ways than taking 3 hours out of my day to do research and write an RFC if I wanted to troll.

[mahkoh]

What I want is pretty clearly spelled out in the first post and I think the RFC contains several arguments why this is desirable for people who want to use Rust as a systems language. I've also given you reasons why the current stability system cannot be maintained long-term and why the current system ("only stabilize what's necessary for the standard library") is harmful for people who want to use Rust as a systems language.

[geofft]

@mahkoh, I'm curious what your thoughts are on ABI-stability guarantees. I think that's also necessary to be a "systems language" in its fullness.

A stable ABI seems to me to be a much more common issue than #![no_std], and also one more compatible with crates.io. If you're writing a serious kernel (i.e., you care about it working with Rust 1.0, not just Rust unstable), you probably want loadable modules. You don't want to require that you happen to have the exact same rustc version that was used to build the kernel you're running. While having a loadable-module interface that requires going through a C ABI on both ends is kind of awful (but doable), it seems similar to how depending on libc for userspace is suboptimal but workable; a standalone systems language shouldn't be leaning on C like that.

But you also want loadable modules if you're thinking of replacing libc: apart from things like NSS or PAM, even if you just have a Rust-language system library, you probably want a Rust ABI, not a C ABI that has to transit through unsafe on both ends. You don't, strictly speaking, need #![no_std] for this: you can (and perhaps should) just tell libstd how to find implementations of the low-level stuff from the current crate. As a straw-man proposal, you could make a pile of lang-items for the functions libstd uses from libc, and teach it how to use those lang-items instead of dynamic symbols from libc.so.

And (unfortunately) a stable ABI is something that exists yet, so merely opening or closing feature gates wouldn't help resolve this by Rust 1.0. It is potentially something that can be done outside of the core language, by transiting through unsafe inside a crate, but it hasn't yet been done.

Would you be in favor of qualifying the website text about a "systems language" and mentioning that it works very well for conventional userspace—including, importantly, replacing C ABI libraries, as long as they're not libc—but while replacing libc or the kernel continues to be a goal, Rust 1.0 delivers language stablization but remains a work in progress? (I think the truth of that should be uncontroversial, it's mostly how to phrase that on the website.)

[huonw]

Stable 1.0 is just a beginning: it doesn't, can't and shouldn't include each and every desirable feature. The nightly/stable split in the reference implementation makes the division between experimental vs. not crystal clear, and is actively recognising that people will want to do things beyond what has been stabilised & giving them the power to easily use the experimental features: rustc-nightly-Rust is still Rust, but a more powerful dialect, just like GCC's extensions to C is a dialect, not a distinct language.

You list two downsides of using the rustc-nightlies, neither of which I can understand; could you clarify my confusion?

• "Most platforms will only have stable compilers available": this seems like speculation. We currently offer nightlies for 100% of the platforms for which we offer stable compilers. The intention would presumably be to continue this trend: if a builder for a stable compiler on a certain platform is hooked up to the buildbot instance, it seems sensible to also use it for building nightly compilers.
• "unstable features opt-out of cargo": it seems to be working pretty well so far, and the question in the detailed design of disallowing unstable crates on crates.io seems strictly more like "opting out of cargo" than what we have now.

Also, comparisons to other language ecosystems with many compilers are ignoring the fact that the stable Rust ecosystem is currently -2 months old, while languages like C and C++ are decades old. Rust is aiming to start with a base of stability which should make it easier for alternate compilers, especially ones not based on LLVM, to implement Rust 1.0 (for example) and automatically use the crates on crates.io that work with that version of the language (of course, this particular fact is independent of the implementation details of the split in the rustc implementation). Users of those compilers are free to use whatever extensions those compilers have implemented, but that's their explicit choice, just like using nightly is an explicit choice. My point is: it doesn't make sense to me to conclude that it is silly to require users install a different compiler (rustc-nightly) to get rustc's extensions/experimental features from the fact that people can get around the stability restrictions by installing a different compiler (e.g. a hypothetical gccrust).

In any case, one can get the exactly same semantics as 1.0 + unstable features by pinning to the nightly at the 1.0 release instead of the released stable compiler.

---

I'm not sure language-lawyering about the details of what is and what isn't a systems language is very productive, e.g. even standard C doesn't satisfy the definition: inline asm isn't in it (and thread local and atomics were only added recently). People have said "C is a systems language" for years, and it seems equally coherent to say "Rust is a systems language".

(Of course, it'd be great if stable Rust was useable for OS/driver/... development.)

---

On the point of Mozilla: the core team guides Rust, not Mozilla. The FUD around Mozilla is quite unnecessary, the RFC would be much improved if it was just removed outright. I can safely say that there's no mysterious corporation pulling strings to get Rust into the shape they want: e.g. the Servo developers were pretty unhappy when libgreen was removed, and I've heard of people inside Mozilla complaining that the project is too community focused and that the core team doesn't listen to the internal concerns enough. I find it particularly ridiculous to frame the reference implementation's standard libraries having special powers in the first release as evidence for "Mozilla" trying to monopolise Rust implementations.

[CloudiDust]

IMHO, premature stablizing is a bigger problem than not permitting unstable features in stable rustc. The latter means we'll get some features later for wide-spread usage, the former means we have to stick with the mistakes before the next major release. Worse, the widespread usage of the misfeatures may make correcting them impractical even in new major releases. (Actually this is also one reason against "unstable features in stable releases".)

The problem I have with rustc now is that I am not sure whether it is ready for a beta or not. Modules like io were only recently marked stable. There are also some language design warts to deal with. (I am biased here as I push for one such RFC.)

[brson]

There's hardly a paragraph in this RFC that isn't dripping with contempt. It could never be accepted as written and is insulting.

[Gankra]

This is honestly a bit confusing to me. Vendor-specific non-standard functionality is the premium means by which an entity takes control of an ecosystem. This is the entire basis behind the infamous embrace-extend-extinguish strategy. We're actively resisting this effect by making it difficult for users to embrace our extensions. Your proposal to avoid this is to make it... more easy for users to develop a dependence on us? Meanwhile this makes no reference to the one way we're currently really locking down the ecosystem: the lack of a clear language specification (although that's never stopped Ruby...).

Otherwise I generally agree with @huonw here; Rust 1.0 sucks. Well, it's ok. But I'm pretty sure everyone is hurting for major pieces of functionality that won't be in 1.0. Using Rust really seriously is still a waiting game. 1.0, to me at least, mostly means "your shit will stop completely breaking". The 1.0 of literally every language ever has similarly sucked.

It's also not like Rust 1.0 will be C99 or whatever. There's going to be another release in 6 weeks. And another. And another. Forever. Until Mozilla will activates their trap card and takes control of the ecosystem to reroute all resources to The Web

[geofft]

The latter means we'll get some features later for wide-spread usage, the former means we have to stick with the mistakes before the next major release.

I thought features could be stabilized in a point release. In particular, I thought the two features mentioned in this RFC, #[no_std] and inline assembly, could be stabilized as soon as the 1.1 release, which will happen no later than the end of June, if they're ready by then.

If that's the case, and if it's at all realistic for these features to land by then, then both options, allowing opting in to instability and declaring Rust not a systems language for six weeks, seem like overreactions. If not, then I certainly think it's important that there's some strong plan for these (as well as, IMO, a stable ABI).

There's hardly a paragraph in this RFC that isn't dripping with contempt. It could never be accepted as written and is insulting.

I care about Rust being usable for the use cases @mahkoh has in mind, so I'm happy to rewrite the RFC from scratch in a respectful manner, if there's in fact a concern here worth addressing. (I certainly think all the stuff about Mozilla doesn't belong.) But I'd first like @mahkoh's feedback on stable ABIs, and whether merely clarifying on the website how complete Rust 1.0 (and 1.1, and 1.x) are would address the concern.

[steveklabnik]

This RFC is certainly not being accepted as written, so I'm giving it a close. As others have said, it's utterly disrespectful, and is not an actual solution, just thinly veiled complaining.

It is important that we stabilize features like inline assembly. But stabilizing them prematurely isn't the answer, and allowing for defacto stabilization isn't the answer.

[nikomatsakis]

@geofft Stable ABIs are certainly on the radar as a priority, but I'm not sure just what that has to do with this RFC. After all, muddying the waters between experimental/unsupported and stable features will not help bring about a stable ABI any faster (quite the opposite, I would say, since any attempt at such an ABI would have to consider more things -- and things that are still in motion).

[mahkoh]

@geofft

A stable ABI seems to me to be a much more common issue than #![no_std], and
also one more compatible with crates.io. If you're writing a serious kernel
(i.e., you care about it working with Rust 1.0, not just Rust unstable), you
probably want loadable modules. You don't want to require that you happen to
have the exact same rustc version that was used to build the kernel you're
running.

I'm not writing a kernel. If I were writing a kernel I would probably want a
Rust and a C API and I don't want people to have to use the same compiler
version. But this is a much bigger problem than systems programming. It's not
possible to have binary distributions that work for multiple compiler versions.
If you want to write a GUI application that uses Rust's equivalent of Qt then
you will first have to compile the GUI library which will take a huge amount of
time.

even if you just have a Rust-language system library, you probably want a Rust
ABI, not a C ABI that has to transit through unsafe on both ends. You don't,
strictly speaking, need #![no_std] for this: you can (and perhaps should)
just tell libstd how to find implementations of the low-level stuff from the
current crate. As a straw-man proposal, you could make a pile of lang-items for
the functions libstd uses from libc, and teach it how to use those lang-items
instead of dynamic symbols from libc.so.

I don't think that's a reasonable idea. If I were writing a rust system library,
then I would want it to be "rustic." I would not want to provide the C library's
interface and the correct semantics which can be quite complicated. libstd even
uses some private glibc symbols on Linux so using lang-items seems out of the
question.

And (unfortunately) a stable ABI is something that exists yet, so merely
opening or closing feature gates wouldn't help resolve this by Rust 1.0. It is
potentially something that can be done outside of the core language, by
transiting through unsafe inside a crate, but it hasn't yet been done.

I don't think Rust needs to define one stable ABI. It would be good if library
authors could opt into some kind of stable ABI. For example

pub "rust_abi_1" fn ...

Where rust_abi_1 is some kind of fixed ABI that supports the parts of the
language that existed when it was defined. Or library authors could even define
their own ABI which could be encoded as some kind of metadata.

Would you be in favor of qualifying the website text about a "systems language"

I don't care how this issue is addressed unless it's addressed by making 1.0 a
systems language. Continuing to advertise your product as a "systems language"
to attract this segment even though you know that it's not a systems language is
disingenuous. When I read about a stable 1.0 language release and the first
thing I read on its website is "is a systems language" then I expect it to be
usable as a systems language and not "might be usable as a systems language in
1.1 or 1.2." Would you agree?

In general I think Rust-internal features such as the ABI cannot be compared to
Rust-external features such as inline assembly and atomic operations.

---

@huonw

Stable 1.0 is just a beginning: it doesn't, can't and shouldn't include each
and every desirable feature.

You've gone a bit too far with "shouldn't." If 1.0 could be the final and
ultimate language release with every desirable feature then everyone would agree
that it should be like that.

The nightly/stable split in the reference implementation makes the division
between experimental vs. not crystal clear, and is actively recognising that
people will want to do things beyond what has been stabilised & giving them the
power to easily use the experimental features: rustc-nightly-Rust is still
Rust, but a more powerful dialect, just like GCC's extensions to C is a
dialect, not a distinct language.

This is already crystal clear today because you have to explicitly opt into
every unstable feature. If you say that there have to be two compilers for
people to notice that they're using unstable features then you don't believe
that people can think enough for themselves. This line of thinking is a pattern
in rustc development where you go beyond what's necessary for memory safety and
try do enforce other "safety" features. (E.g. people cannot be allowed to opt
out of integer overflow checks because they cannot be trusted with such power.)

just like GCC's extensions to C is a dialect, not a distinct language.

I don't have to install multiple compilers to use those features. They are
available with the default compiler and don't even need extra flags.

"Most platforms will only have stable compilers available": this seems like
speculation. We currently offer nightlies for 100% of the platforms for which
we offer stable compilers. The intention would presumably be to continue this
trend: if a builder for a stable compiler on a certain platform is hooked up to
the buildbot instance, it seems sensible to also use it for building nightly
compilers.

That's not what I meant by "available." Of course, if you can have a stable
compiler on a platform then you can also have a nightly, by compiling it
yourself if necessary.

This is less of a problem on Windows but on Linux you cannot expect anyone but
language enthusiasts to install compilers that are not in the official
repositories. Nightlies will probably not be available in any of the major
distros. The current version of GCC in Debian stable is 4.7.2 (released
2012-09-20). The current version of Go in Debian stable is 1.0.2. The current
version of Firefox in Debian stable is 31 (released 2014-06-22.) If the first
stable release of Rust is included in the next stable Debian release, then this
is the version you will have to write code against for a long time.

"unstable features opt-out of cargo": it seems to be working pretty well so
far, and the question in the detailed design of disallowing unstable crates on
crates.io seems strictly more like "opting out of cargo" than what we have now.

Because most people only have one Rust version installed. How does Cargo work
when you want to use stable 1.0 and nightly compilers on the same system? Can
you even install a nightly and the rustc from your package manager at the same
time? Will endusers have to hack around with shell scripts in addition to
installing multiple compilers? Why can't the package manager of a language that
expects people to install multiple compiler versions automatically detect the
correct compiler?

All of these problems lead to the conclusions that, if you write a library that
uses unstable features, then downstream won't be able to use it in cargo like
they do with other libraries.

Not allowing unstable crates in crates.io would not be a serious problem for
people who want to use unstable crates. As long as cargo can deal with git
branches and tags, having a git dependency seems fine.

Also, comparisons to other language ecosystems with many compilers are ignoring
the fact that the stable Rust ecosystem is currently -2 months old, while
languages like C and C++ are decades old.

You've got it the wrong way around. I started with the idea of stability you're
trying to enforce and concluded that such stability cannot exist if you have
multiple competing compilers.

Rust is aiming to start with a base of stability which should make it easier
for alternate compilers, especially ones not based on LLVM, to implement Rust
1.0

I don't see how not providing simple but essential systems language features
such as atomic operations, inline assembly, etc. hinders alternative
implementations of the language. This doesn't seem to be an honest argument
since you can apply it to every single language feature.

Users of those compilers are free to use whatever extensions those compilers
have implemented, but that's their explicit choice

So it adding #![featurue(..)] to your crate.

My point is: it doesn't make sense to me to conclude that it is silly to
require users install a different compiler (rustc-nightly) to get rustc's
extensions/experimental features from the fact that people can get around the
stability restrictions by installing a different compiler (e.g. a hypothetical
gccrust).

Both Clang and GCC are in the repositories. Clang-nightly and GCC-nightly are
not. A different stable compiler release is much easier to get than a nightly.

I'm not sure language-lawyering about the details of what is and what isn't a
systems language is very productive, e.g. even standard C doesn't satisfy the
definition

I wasn't language lawyering. That's what you're doing by bringing language
standards into the discussion. I was talking about actual compilers used for
systems programming such as GCC which have had extensions for a long time. It
would be silly to compare the C standard to anything since there is no Rust
standard or even a complete language reference.

People have said "C is a systems language" for years

GCC and other compilers have had extensions for years. The C model is also quite
different from the Rust model. In C you compile object files which you then link
together to create a executable. I can simply use an assembler and combine C
compiler output and assembler output in the same library. How am I going to do
this with rlibs and cargo?

On the point of Mozilla: the core team guides Rust, not Mozilla.

You cannot deny that the core team consists mostly of Mozilla employees and that
others are being paid to work on Rust by Mozilla. (I'm not sure if you or wycats
receive any financial compensation.) It seems that Mozilla is the only company
that pays people to work on the core team. It's fair to say that Rust is a
Mozilla project.

I've heard of people inside Mozilla complaining that the project is too
community focused

You're saying that people inside Mozilla were trying to influence the direction
of the project?

Correct me if I'm wrong, but I think the push to make Rust a systems language
(moving away from libgreen etc.) came mostly from outside the core team. If this
is true then it seems fair to say that the core team is not focused on making
Rust a systems language. Doesn't the fact that you're releasing a 1.0 release of
a systems language before you have the systems features complete support this?

---

@CloudiDust

IMHO, premature stablizing is a bigger problem than not permitting unstable
features in stable rustc. The latter means we'll get some features later for
wide-spread usage, the former means we have to stick with the mistakes before
the next major release.

Yes, some believe that 1.0 is rushed. But I don't think it's fair to compare the
long term impact of explicitly unstable and stable features.

---

@gankro

This is honestly a bit confusing to me. Vendor-specific non-standard
functionality is the premium means by which an entity takes control of an
ecosystem. This is the entire basis behind the infamous
embrace-extend-extinguish strategy. We're actively resisting this effect by
making it difficult for users to embrace our extensions. Your proposal to avoid
this is to make it... more easy for users to develop a dependence on us?

That doesn't make much sense. You cannot EEE your own project. I don't think
unstable features create a dependency either, especially since everything is
open source under permissive licenses.

---

@brson

I recommend you read

• http://en.wikipedia.org/wiki/Polemic and
• http://www.slate.com/articles/technology/technology/2012/12/i_m_not_a_troll_why_does_everyone_on_the_internet_keep_calling_me_one.html

Trying to disrupt an active discussion by throwing in off-topic comments is a
form of trolling if done intentionally.

After you've shut down the mailing list, this is the only place where this kind
of language discussion is possible. (I don't consider i.r-l.o with it's
gimmicky, buggy, and javascript ridden software to be an acceptable platform.)

---

I see @steveklabnik has gone ahead and tried to shut the discussion down. Of
course, if you don't care about systems programming and only want a faster Ruby
then that is a reasonable thing to do.

For you I recommend the following article:

http://www.panarchy.org/russell/decalogue.1951.html

In fact, I consider this article so essential for any kind of discussion that
I'll reproduce it here:

---

1. Do not feel absolutely certain of anything.
2. Do not think it worth while to proceed by concealing evidence, for the
   evidence is sure to come to light.
3. Never try to discourage thinking for you are sure to succeed.
4. When you meet with opposition, even if it should be from your husband or your
   children, endeavour to overcome it by argument and not by authority, for a
   victory dependent upon authority is unreal and illusory.
5. Have no respect for the authority of others, for there are always contrary
   authorities to be found.
6. Do not use power to suppress opinions you think pernicious, for if you do the
   opinions will suppress you.
7. Do not fear to be eccentric in opinion, for every opinion now accepted was
   once eccentric.
8. Find more pleasure in intelligent dissent that in passive agreement, for, if
   you value intelligence as you should, the former implies a deeper agreement
   than the latter.
9. Be scrupulously truthful, even if the truth is inconvenient, for it is more
   inconvenient when you try to conceal it.
10. Do not feel envious of the happiness of those who live in a fool's paradise,
    for only a fool will think that it is happiness.

[steveklabnik]

I see @steveklabnik has gone ahead and tried to shut the discussion down.

No, if I was doing that, I could have clicked the 'lock pull request' button, which disallows further comments. This RFC in its form is simply not going to be accepted, and so I've closed it, just like any other RFC.

Anyway, that's my last comment in this thread.