5 ms·
Right now, a lot of people want nightly (and [Rust 2018]) for NLL. It makes the borrowchecking system a lot more precise and less conservative, which in turn ma
by Tuna-Fish 8y ago
Right now, a lot of people want nightly (and [Rust 2018]) for NLL. It makes the borrowchecking system a lot more precise and less conservative, which in turn makes the language much less annoying to use.
Using nightly as the compiler is much easier in Rust than, for example, using Python 3 early on was, because unlike, say, Python 3, nightly is fully backwards-compatible to earlier stable releases. (While not being backwards-compatible to previous nightlies.)
This means it's easy to limit yourself to the features used in stable + one major change you want, and if there is no change to that major feature, you won't even notice all the instability of the compiler.
There has been some hope of people moving to stable versions as NLL hits them, I think most people will always want the next big feature (personally waiting for const generics) on nightly, at least until the language is a lot more complete.
- steveklabnik 8y ago> Right now, a lot of people want nightly (and [Rust 2018]) for NLL. 9 more days!
- moosingin3space 8y agoNLL is stable in 1.31?
- steveklabnik 8y agoFor 2018 edition code, yes. 2015 will come later.
- moosingin3space 8y agoI am incredibly excited for this!
- cies 8y ago> at least until the language is a lot more complete. Or used in larger projects. Or used in environments where (a) dev's prefs cannot be nightly.
- steveklabnik 8y agoWhat's a "large project" to you, incidentally? We know of several codebases that are over a million lines. To some people, that's big, and to many, it's not. (Note also that this data shows a majority of people do use stable.)
- kbenson 8y ago> To some people, that's big, and to many, it's not. This boggles my mind, so I have to ask, who considers a million lines of code in a code base not a large project? I mean, sure there are plenty of projects larger than that, but when considering whether a project is large or not, I think I would consider a million lines of code well into the "large" category.
- steveklabnik 8y agoAs with most things, people's experience is colored by their previous experience. There are people who work on 10MM LOC codebases that say "oh well you don't even have one of those", or for example, take Google's C++ codebase, which last I saw is estimated at something like 2 billion lines? Yes, that's a bunch of small projects, but since it's in a monorepo and uses one big build system, to people thinking about scale, they consider it one, or so I've heard. Add in a general sense of bragging rights, and well, I've heard people say "call me when you have a real project" about more absurd (to me) things than just this in the past...
- cies 8y agoMaybe I should have said "used in large project more often" > (Note also that this data shows a majority of people do use stable.) Well, that kinda proves my point then, right? > What's a "large project" to you, incidentally? It's more that the larger the project (either in code or number of devs working on it), the more tool-stability becomes a requirement. Just my experience, and it is quite understandable.
- steveklabnik 8y ago
- jordigh 8y agoIn case anyone else was wondering what this jargon meant, "non-lexical lifetime": https://github.com/rust-lang/rust/issues/43234 https://github.com/rust-lang/rust/issues/43234 Took me a bit of websearching to figure out what people were excited about.
- steveklabnik 8y agoGood call, thanks. Additionally, even that is kind of jargon. The simplest answer is “the borrow checker will allow some kinds of code that is sound, but the previous borrow checker could not understand that it was sound.”
- cpeterso 8y agoI see that NLL makes the borrow checker easier to work with for developers, but does NLL actually change when objects will be dropped at run-time?
- steveklabnik 8y agoNLL does not affect things that implement Drop. This is called "eager drop", and while it would only affect unsafe code, we deemed it to be too likely to cause problems with said code. Even though it's unsafe, we don't want to make that even harder to understand.
- cpeterso 8y agoThat makes sense. A developer writing unsafe code can more easily and clearly control their drops by introducing new scopes than deciphering where the eager drop happened.
- deleted 8y ago[deleted]