
Rust's 2017 Roadmap - steveklabnik
https://blog.rust-lang.org/2017/02/06/roadmap.html
======
sgentle
I'm very excited about improvements to the maturity of the Rust library
ecosystem. I'm happy with Rust's syntax, the borrow checker doesn't bother me
that much, and the build tooling works well (though more speed would
definitely help).

What it comes down to again and again with projects I think about using Rust
for is "how much extra effort is it going to be compared to a language with
good libraries for this?" Often I don't use Rust just because the cost/benefit
of having to (re)write code that would otherwise be in a library doesn't make
sense.

I'm still bullish on Rust. I know it takes time and it's an unfair competition
against the likes of Node and Python (with a zillion library authors), or Go
(with a huge company dedicated to a kickass standard library). But nonetheless
that's the playing field, and I think a stronger library ecosystem is probably
the most important thing for Rust adoption right now.

Well, that and not having to use nightly rust for serde, but you already fixed
that.

~~~
kbenson
> Often I don't use Rust just because the cost/benefit of having to (re)write
> code that would otherwise be in a library doesn't make sense.

On the other hand, if you're looking to fill out your resume or get some open
source credentials, you can see this as another frontier opening up (depending
on how popular you think Rust will be in a few years). Become the solution for
that need in the Rust ecosystem, and there are probably massive reputational
benefits to be reaped. In some ways, reputation is better than money, because
when invested wisely can have a much higher rate of return, and depending on
location and circumstance, can be levered into high-paid employment.

One person's problem is another person's opportunity.

------
adamnemecek
> Plans include a new book,

You should consider publishing an official, printed book. I would totally pay
$30-40 for something like this. And once it's already written, the actual
publishing shouldn't be too time consuming (but idk lol). I think that there's
a lot of people who'd buy it just to support the project.

On one hand, I do have environmental concerns, but on the other hand, I feel
like my retention rate with print is like 70% as opposed to like 40% with
digital.

~~~
Animats
Rust needs a Rust book not written by the Rust developers. "Rust for Dummies",
if you will.

~~~
dbaupp
Why couldn't Rust's developers write "Rust for Dummies"? I feel like you're
connecting dots that aren't actually connected. Obviously having more books
from different authors/perspectives is great for Rust, but I don't see, prima
facie, why a non-Rust-developer author would do a better job of "Rust for
Dummies" than a Rust developer.

For one, I would be surprised if a non-"expert" (which is, I presume, why
you're so dismissive of Rust developers) could write a book that gives an
accurate/useful mental model of Rust: teaching is the true test of one's
knowledge about anything. Additionally, people paid to work on Rust and on
Rust documentation/teaching materials (i.e. "Rust developers") are the people
most regularly interacting with all sorts of beginners, and thus are likely to
have great insight into, for instance, the common difficulties people hit,
rather than just anecdoata about their own personal experience/background
(which is good too, but is only one point of reference for things that people
find hard).

Rust developers can write beginners books (indeed, the Rust book is designed
to be this, and the second edition succeeds better the first, I've heard) just
as much as non-Rust-developers can write expert books.

~~~
tormeh
You're usually best able to explain something just after you learned it
yourself. After a while you forget what was difficult about the thing you
learned.

A C programmer, a Python programmer and a Java programmer should write the
book together, with expert insight from a Rust pro.

~~~
dbaupp
I'm not sure I agree with the anecdote in your first paragraph, and indeed I
preemptively addressed it in my comment: one's own experience is just one way
in which something can be hard to learn, whereas people who are regularly
teaching and interacting with beginners have a broader view on what people
find hard. My experience is, broadly speaking, good teachers are those that
have had a lot of practice teaching their material.

------
jimrandomh
Non-Rust-user here. I tried Rust about a year ago and gave up on it as not
ready. Unfortunately, I don't think this roadmap addresses the problems that
made me reject it the first time around.

The main problem I have with Rust is that it's not up to the task of dealing
with C APIs, particularly POSIX. The issue I got stuck on was
[https://www.reddit.com/r/rust/comments/47a0s3/dealing_with_v...](https://www.reddit.com/r/rust/comments/47a0s3/dealing_with_variation_in_c_ffi_interfaces/)
. There are two possible things Rust could do that would make me give it a
second chance: either commit to maintaining bindings for all of POSIX and libc
as part of Rust core, or fold rust-bindgen into core and get it into shape.

Creating higher-level libraries like Tokio is nice for some use cases, but
right now Rust doesn't have a working safety valve for things C can do that
Rust can't. This greatly magnifies problems like lack of bindings for select()
(see
[http://esr.ibiblio.org/?p=7294&cpage=1](http://esr.ibiblio.org/?p=7294&cpage=1)
; I too ran into that problem, and lost a few days to it.)

~~~
steveklabnik
Did you try the nix crate? It looks like maybe not. It should have all of that
stuff already wrapped for you. For example:
[https://docs.rs/nix/0.7.0/nix/sys/termios/fn.tcgetattr.html](https://docs.rs/nix/0.7.0/nix/sys/termios/fn.tcgetattr.html)
(select is in there too
[https://docs.rs/nix/0.7.0/nix/sys/select/fn.select.html](https://docs.rs/nix/0.7.0/nix/sys/select/fn.select.html)
)

rust-bindgen has been improving a ton, and it is in fact on that roadmap,
under

> Integration with other languages, running the gamut from C to JavaScript.

~~~
jimrandomh
Happy to hear bindgen is getting attention; I didn't actually notice that when
I looked through the roadmap.

I didn't try the nix crate at the time, but looking at it just now - it
doesn't solve the portability issue. It defines struct Termios in
[https://github.com/nix-
rust/nix/blob/master/src/sys/termios....](https://github.com/nix-
rust/nix/blob/master/src/sys/termios.rs) , with something #ifdef-ish branching
on operating system, but not on CPU architecture. On quick inspection, I think
it's probably incorrect on x86-32, and this crate is definitely a major
liability for portability.

~~~
steveklabnik
Sounds like you should open an issue; it's pretty much the crate for safe
bindings, but as I'm sure you know, there's a lot of tiny details to get
right.

(Also, I'll stop here and only reply on our Reddit conversation, ha!)

~~~
jimrandomh
[https://www.reddit.com/r/rust/comments/5sg9d3/rusts_2017_roa...](https://www.reddit.com/r/rust/comments/5sg9d3/rusts_2017_roadmap/ddf5ly9/)

(The first few comments are mirrored between here and Reddit.)

------
tormeh
I once said that Rust would never become really, Java-level, popular. Mostly
because I thought it focused too much on performance to the detriment of
elegance and productivity. I'm not so sure anymore. This is a step in the
right direction. That said, what makes me most nervous about Rust is pointers
and mutability being mandatory for certain things, rather than the absence of
books. Maybe that's just me, though. Anyway, in my opinion, pointers and
mutability should be something I think about once I'm optimizing the program,
not something I do while figuring out the logic. As long as copying everything
every time fits in my compute budget I don't get why I should be forced by the
stdlib to do otherwise.

Anyway, huge fan of what the Rust devs are doing. It's truly awesome.

~~~
mdzn
References (lifetimes and borrow checking) and mutability are there for
safety, not speed.

~~~
tormeh
Copying everything every time is a trivial (and very slow) solution to the
memory safety problem. It just means that everything is on the stack (or at
least that only one stack frame has a reference to any given object), so it is
simply deallocated along with the stack frame. That's it. There's nothing
unsafe about it.

What do you mean by saying mutability is for safety? That's a very unusual
opinion.

~~~
richardwhiuk
Explicitly tracking shared mutability is for safety - obviously not mutability
in of itself.

Copying everything every time isn't a solution in a multithreaded world if you
actually want your threads to share data.

~~~
pkolaczk
"sharing data" is quite illusory. Even if two threads have a reference to the
same object, the CPU deals with it internally by making several copies,
asynchronous message passing and locking, and in many cases it can lead to
abysmal performance. It is often much better for performance to design
parallel algorithms around shared-nothing i.e. local mutability + explicit
message passing right from the start.

~~~
acqq
> "sharing data" is quite illusory. Even if two threads have a reference to
> the same object, the CPU deals with it internally by making several copies,
> asynchronous message passing and locking,

No. Two threads on the same CPU core really access the same data(1) without
the delay and no locking happens unless the programmer wrote some locking
code.

Synchronizing the different cores or processors is another topic, but it's
also typically dependent on the software.

\----

1) But there is also reordering
[https://en.wikipedia.org/wiki/Memory_barrier](https://en.wikipedia.org/wiki/Memory_barrier)
and out-of-order execution [https://en.wikipedia.org/wiki/Out-of-
order_execution](https://en.wikipedia.org/wiki/Out-of-order_execution)

Most of the time the implemented techniques do significantly speed up the
execution. And it's mostly software design that initiates the slowdowns, not
the CPU.

~~~
pkolaczk
Even on a single core, there are several copies in different cache layers and
synchronizing them is done by sending asynchronous messages. Sure, in that one
particular edge case when the threads are sharing a core you're right, but
this is not a typical scenario for multi-threaded applications. Most of the
time for high multi-threaded performance you want exactly opposite - one
thread per core and pinning threads to cores. And if you don't do anything,
you can never be sure if your threads run on the same core or not and you
should assume the worst.

> And it's mostly software design that initiates the slowdowns, not the CPU.

This is quite vague statement and I'm not sure what you really meant here.
Software written using a simplified abstraction model (e.g. flat memory with
stuff shared between threads, ordered sequential execution) much different
than the way how CPU really works (hierarchical memory, out-of-order
execution, implicit parallelism etc.) is very likely to cause "magic"
slowdowns. See e.g. false-sharing.

Also algorithms designed around the concept of shared mutability do not scale.
Sure, you may hide some of the problems with reordering, out-of-order, etc. To
some degree it will help, but not when you go to scale of several thousands
cores in a geographically distributed system.

~~~
acqq
> See e.g. false-sharing.

It's also an effect of a badly written software, not something that is
constantly present in the CPU execution. You based the claim to which I've
replied on "sharing is illusory", "if two threads" and "the CPU deals with it"
like it's necessary to happen all the time in the CPU as soon as the threads
exist and they access the same data.

> when you go to scale of several thousands cores in a geographically
> distributed system.

There you are not describing "a CPU" (as in, the thing that's in the CPU slot
of the motherboard) which is all I discussed, and I'm not interested in
changing the topic.

------
ainar-g
Does the "lower learning curve" goal include the lowering of learning curve
for people who already know how to program? Because right now, the Book
sometimes seems like it's aimed for people who either didn't program a lot, or
didn't program in a language with types.

What I actually would like is a few "Books" like "Rust for C++ people", "Rust
for Go people", etc. Those would describe in many examples how things that are
achieved in language X using A, B, and C can be done with D in Rust.

Personally, I would like a "Rust for Gophers" book that would describe things
like how does Rust do composing (that is, how to do what Go calls embedding),
interfaces in Rust (with dynamic vs static dispatch), HTTP in Rust (this may
be waiting for Tokio?), how to model your application's types and not get into
who-owns-what traps.

Also, what I _really_ want is some kind of a list of Rust "warts" and their
explanation. Like the fact that sometimes you can't do a.b().c(), but have to
write tmp = a.b(); tmp.c().

~~~
steveklabnik
You will probably like the O' Reilly book. It's a bit closer to "Rust for C++
people", IMHO.

I fully agree that more of this kind of thing would be great.

~~~
ainar-g
What about the warts part?

Also, as someone who've tried to get into Rust three times now, I've been
thinking, have you or anyone from the rust documentation team ever had
sessions where you just

\- take a random C++/Go/Python developer

\- ask them to solve a not-too-simple but not-too-hard task, something that'll
generally take them less than an hour in their "native" language, in Rust

\- look and take notes on their struggle with it

This might shed some light on why people (like me) have so much trouble
getting into Rust.

~~~
steveklabnik
> What about the warts part?

I'm not sure enough time has passed to tell what Rust's warts truly are. I
always joke String should have been called StrBuf...

I do this, yes. This is one of the reasons I hang out in IRC so often; it's an
effective way to collect these kinds of things.

More data is always better, and collecting it across multiple venues. I don't
think IRC is inherently going to be a representative sample. It's one of the
reasons you'll see me pushing for details in Rust threads here, for example.

~~~
pjungwir
So I'm only a Rust amateur (I mean I don't get paid to use it), but I'm on my
third round trying to build something with it, and I feel like I'm finally
starting to get it. A couple warts I've encountered:

\- No support for default struct fields: [https://github.com/rust-
lang/rfcs/issues/1594](https://github.com/rust-lang/rfcs/issues/1594)

\- Terrible signatures for functions that return iterators:
[https://www.reddit.com/r/rust/comments/2h26cj/functions_retu...](https://www.reddit.com/r/rust/comments/2h26cj/functions_returning_iterators/)

If the next push is going to be for ease-of-use, those would be two nice
things to fix.

~~~
comex
A feature designed as a fix for the second problem is already in nightly:

[https://github.com/rust-lang/rust/issues/34511](https://github.com/rust-
lang/rust/issues/34511)

Who knows when it'll be stabilized, though.

~~~
steveklabnik
"sooner rather than later"

------
moosingin3space
> fast, reliable, productive--pick three

I love it. Short and simple, describes what Rust is. Between that and "an
anti-sloppy programming language", pretty sure the marketing is there. Well
done community leads, this is exciting.

~~~
zyxzkz
Man, if developing programming languages was this easy, we should have done it
years ago!

~~~
lmm
We did. The ML family has been around for about 4 decades now. Not sure why
they never caught on until Rust.

~~~
kod
Pretty sure F# adoption dwarfs rust.

~~~
geodel
Right. Though I checked in Google trends and found Rust to F# interest went
from 1/40 to 2/3 in 5 years or so. I think Rust will become more popular in
next 2 years.

------
doesnotexist
I'm impressed with the direction they've laid out. It is great to see a
deliberate effort is being made to make the language easier to learn and to
strengthen the community's ability to leverage shared code.

~~~
monk_e_boy
Is there an good IDE for windows? Something that will step through debug?

~~~
vvanders
I've used VSCode, you have to pick the GNU abi and install a couple plugins
but it works reasonably well.

~~~
moosingin3space
I think VS Code is what the community is rallying around to become the
flagship cross-platform Rust IDE, with intellij-rust as the second choice.

~~~
agmcleod
Ive found Atom to be better in terms of having the lint as you go. RustyCode
is pretty good though otherwise :). I'm interested to see where the debugging
goes with it as well.

~~~
gcp
RUSTYCODE IS DEAD.

I wish more people knew this, because it's probably the thing most people try
to install as it has the most downloads. It's no longer maintained and doesn't
work correctly with current stable. There's a fork that is being updated
that's just called "Rust" in the VSCode addons.

~~~
wofo
Thanks! I was still using RustyCode...

------
mamcx
I wish it have a good history for mobile development (iOS, mainly). I think a
modern language without a good foot inside the mobile is non-ideal.

Also, a nice history for UI native widgets will be a plus. This is ask a lot,
I know.

Right now I have some projects where the less-worse option is .NET, swift if
only iOS+Linux, Delphi is because cost (and free pascal is unfocused). Then
obviously C++, but that is where I draw a line (ie: For a C-like language Rust
is the only that look nice to me. I wish pascal instead or similar)

~~~
girvo
If you like Delphi/Pascal, have you seen Nim?

~~~
mamcx
Some year(s ?) ago I look at it. Seem nice. Don't clear if is good (enough)
for mobile/UI. Need to recheck...

~~~
girvo
Check out this link for an example of how to build iOS apps with it:
[http://www.thomasdenney.co.uk/blog/2015/1/27/nim-on-
ios/](http://www.thomasdenney.co.uk/blog/2015/1/27/nim-on-ios/)

Because it compiles directly to C, I've found it reasonably easy to bring into
different environments myself, though I've not attempted iOS yet :)

Edited to add: Also check out
[https://github.com/yglukhov/nimx](https://github.com/yglukhov/nimx)

------
tux3
I'm happy to see the focus on productivity.

I saw the long awaited Non-Lexical Lifetimes tentatively mentioned in there,
and I can only hope this will help move things forward, since it's pretty
frustrating spending time fighting the borrow checker and refactoring correct
code that really ought to run as-is.

Cheers and happy 2017 to the Rust project!

~~~
flukus
As far as fighting the borrow checker goes, how familiar are you with more
functional style programming approaches, mainly immutability?

I'm extremely new to rust so I don't know if fighting the borrow checker is in
my near future or something I will largely avoid.

~~~
hyperpape
Mutability makes it worse, but there are at least some issues with borrowing
that have nothing to do with mutability. If your experience is with garbage
collected languages, I suspect you'll encounter errors that surprise you.

~~~
stable-point
Could you provide an example where the borrowing would cause issues for
immutable data?

I'm still learning Rust, but I thought the fact that you could have as many
immutable borrows as possible would limit what errors the borrow checker could
throw at you.

~~~
hyperpape
This is embarrassing, but I'm now second-guessing whether what I wrote was
accurate. Sorry.

In penance, here are some links:
[https://www.reddit.com/r/rust/comments/5ny09j/tips_to_not_fi...](https://www.reddit.com/r/rust/comments/5ny09j/tips_to_not_fight_the_borrow_checker/)
[https://m-decoster.github.io//2017/01/16/fighting-
borrowchk/](https://m-decoster.github.io//2017/01/16/fighting-borrowchk/)

~~~
stable-point
Fantastic! Thanks a lot in any case.

I do find the image of "fighting the borrow checker" is quite harmful to how
people view Rust. As those links state, an important aspect of teaching Rust
is educating people about why the borrow checker complains, so that they might
adjust their mental model.

------
olivier1664
I would love to see some improvement in the desktop GUI libs.

\- GTK is a painfull to install.

\- Conrod: I was unable to do an hello world application with it. It just miss
some tutorial.

\- KISS-UI: some dll to install

\- Qt: not totally free

\- Neon to plug on Electron: I'm not sure if I can do some callback from Rust
to the GUI with this method.

I finnally give up to play with Electron in javascript.

~~~
gcp
_GTK is a painfull to install._

Also pretty bad on Windows AFAIK?

My personal wish would be for an easy way to use Servo to render the UI.

~~~
blaenk
That's actually a cool idea. IIRC Servo was even (going to?) comply to the
chromium embedded framework API/ABI so that it could be a drop-in replacement.
If they're doing that, hopefully they'll go further in creating a rich API for
embedding.

------
onmobiletemp
This plan addresses everyones biggest complaints, especially the 1.0 crate
issue. Its so nice to finally quiet all the people that try rust for a couple
hours and then declare it useless.

------
JoelMcCracken
This was ultimately my problem with Rust, and I am really glad this is being
addressed directly.

At the end of the day, the primary thing I want from my PL is to boost my
productivity. In the kinds of software that I write, I can tolerate bugs and
GC. Does Rust actually make me more productive?

~~~
jamwt
If your _primary_ goal is productivity, I don't think rust will ever be the
right language for you.

If you want to remain relatively productive while building things that are one
or more of (large, fast, safe), it's an excellent choice.

~~~
vertex-four
Add maintainable to that list. A program where its developers have a fuzzy
idea of ownership of data is not in any way maintainable.

~~~
JoelMcCracken
This is one of those things that seem plausible, but I have no idea if its
really true. I'm not disagreeing, I just can't see it as being obviously true.
Can you give me an example of how a fuzzy idea of ownership causes, ideally, a
real problem, or a less ideally a simplified example problem? I'm 100%
genuinely interested in this.

~~~
vertex-four
It's pretty much _the_ reason for segfaults and use-after-free issues (which
manifest as either memory corruption or security vulns) in reasonably sized
codebases - without a good understanding of ownership, it's non-obvious when a
pointer is supposed to become invalid, and if that doesn't match up with when
the data is actually freed, you have an issue that's hard to track down later.

If you're using a language with garbage collection, it's obviously not going
to result in segfaults, but you can still run into logic errors when part of
your code assumes that it's done dealing with a piece of data and another part
has a different idea. More generally, if your object is stored in multiple
places in your code, you have to remember to clean up all references to it
properly, in all the different states your system can be in, and your compiler
can't verify you're doing that correctly without a borrow checker.

~~~
JoelMcCracken
Problems involving memory deallocation in the GC applications I've written
seem to happen infrequently, certainly infrequently enough that it is one of
the lowest items on my list of things I'd like to fix that cause problems in
development.

> but you can still run into logic errors when part of your code assumes that
> it's done dealing with a piece of data and another part has a different
> idea.

Mostly I think this is sufficiently handled by not mutating shared state as a
practice. However, since Rust has mutable borrows, it seems to me that you're
still in danger of running into this.

~~~
vertex-four
Mutable borrows are not shared - you can't touch the data elsewhere while it's
borrowed mutably, and you can't get a mutable borrow while there's immutable
borrows. Shared state is unfortunately a common affliction on large codebases,
and if the language supports and even encourages it, it can be difficult to
prevent it from happening as the codebase grows and customers want features
that don't fit into the architecture wonderfully.

------
loeg
It's good to see incremental builds and async socket support
(select/kevent/epoll) on the map. Those are essential to the kind of software
I work on in C.

~~~
steveklabnik
We just hit beta with incremental builds! [https://internals.rust-
lang.org/t/incremental-compilation-be...](https://internals.rust-
lang.org/t/incremental-compilation-beta/4721) Give it a try :)

------
didibus
I'm really on board with this roadmap. I'm actually quite impress to see a
language publish such a clear direction, they have really good focus, and if
they keep this focus year over year, Rust will become a really great language.

------
progman
The Rust 2017 Roadmap sounds really nice. Congrats for the development so far.

However, what I still miss is bootstrapping from source. It would make porting
to other platforms much easier. It confuses me that Rust is proclaimed as a
safe language while anyone is forced to install a binary with wget | sh.

------
crncosta
I wish a GCC Rust compiler, but it's not planed for 2017. Hope this can change
in 2018 :)

~~~
zeotroph
The closest to that is mrustc [1], a reimplementation which skips the borrow
checking part can generate C code. Eventually you might be able to compile
rust code on more platforms, though you should still develop with the official
rustc for the borrow checking.

1:
[https://github.com/thepowersgang/mrustc](https://github.com/thepowersgang/mrustc)

------
Siecje
I'm surprised cross-compilation is not on the roadmap. I've heard that it is
ready and that it's not quite ready.

Can I create a Windows executable for Windows on Linux?

~~~
steveklabnik
It's not a high-level goal, but it is part of many of those high-level goals.

> Can I create a Windows executable for Windows on Linux?

Yes, but it's a little gross at the moment: [https://github.com/rust-lang-
nursery/rust-forge/blob/master/...](https://github.com/rust-lang-nursery/rust-
forge/blob/master/cross-compilation/to-windows.md)

We do plan for all of this to be much, much easier in the future. Working on
it.

> I've heard that it is ready and that it's not quite ready.

The _foundations_ are strong, but the details are tough. So like, doing the
cross-compilation is there, and is the simple bit, it's all of the stuff
around it: linkers, other platform stuff, things like that. But the foundation
to make all of this easy is in place. It just needs time and effort.

------
lukaszjb
Ambitious goals but if they pull this out it will be amazing. Very happy that
they want to focus on beginners and dev experience.

------
shmerl
Good to see plans for further improvement of code reusability.

------
EugeneOZ
Please start from point 2

------
Animats
That's a good list. Get the basics right.

Rust has been putting much effort into "l33t features" in template land. I
fear Rust may be going down the C++/Boost template metaprogramming rathole.

~~~
steveklabnik
Which features are you thinking of, specifically? We actually just rejected an
RFC for one of these features for being too complex, though it isn't a
rejection of the feature entirely.

~~~
dochtman
Which one is that?

~~~
steveklabnik
[https://github.com/rust-
lang/rfcs/pull/1657#issuecomment-270...](https://github.com/rust-
lang/rfcs/pull/1657#issuecomment-270458055)

------
DeepYogurt
Don't change the language to make it easier (unless that can be a free lunch),
but get someone doing a "Today in rust" or "Doing X in rust" blog/vlog. Also
please get some sort of RNG into the main language (not as a crate).

~~~
Manishearth
Any particular reason rng must be in the stdlib? It's an "official" crate,
maintained by the Rust developers. In general Rust tries to keep things out of
its stdlib instead opting for crates. It lets these evolve independently of
the stdlib (not tied to rustc releases), and also lets them have their own
versioning (none of that urllib2 urllib3 nonsense)

~~~
XorNot
I would say random numbers are a fairly core programming construct for a
standard library. They're important, difficult to get right, and have huge
implications if you get them wrong.

~~~
Manishearth
This doesn't answer my question, though. Most of the "fairly core programming
constructs" are not in the stdlib for Rust (like regexes)

The Rust stdlib is mostly core abstractions and platform-dependent stuff.

Given that, why should they be in the stdlib? The rand crate is officially
blessed and the one everyone uses.

~~~
sevensor
In that case, it sounds like "officially blessed crates" are a second-level
stdlib with weaker guarantees about availability across time and across
platforms. I'm fine with that idea, but from my outside perspective this is a
confused message. Better to call the blessed crates "stdlib extensions" or
something like that.

~~~
Manishearth
Why "weaker guarantees across platforms"? These crates have the same
guarantees about platform support. Availability across time is also similar,
really.

~~~
1wd
In most other programming languages functions in the standard library:

* Are guaranteed to work correctly on all platforms where the language works.

* Will always work with the latest stable release of the language.

* Will be available under one single permissive license (with a single copyright holder (body) for any purposes of required notices etc.)

* Will be supported (security patches, bug fixes, etc.) with backward compatibility, more or less indefinitely (with reasonable long time frames for deprecation windows and recommended transition plans etc.)

* Are under no danger of being abandoned simply due to lost interest of the author.

* Crucial: Will only depend on other code in the standard library. (So all these guarantees are transitive!)

And anything that's not in the standard library usually implies there are no
such guarantees. This is immensely more helpful and important than the
comparatively trivial ease-of-installation.

If the Rust team really does explicitly extend such guarantees to non-standard
library crates, that should be clearly and widely communicated. So far the
focus seems more on how small the standard library is. What's the advantage
for the language user? I see advantages for the Rust team, and mainly I see
disadvantages for the (professional) language user. Easy-to-use cargo is nice
(especially for casual language users) but is nowhere close to really making
up for that.

~~~
Manishearth
Most of these are true for rand. It's in the nursery so it might (probably not
though) be deprecated in favor of a different library, but it would continue
to work because Rust is backwards compatible.

[https://github.com/rust-
lang/rfcs/blob/master/text/1242-rust...](https://github.com/rust-
lang/rfcs/blob/master/text/1242-rust-lang-crates.md) has some of the
motivation behind this.

~~~
1wd
Thanks, but I still don't see where such guarantees are advertised. Also it's
not really clear what "the nursery" is exactly. Where is it? Why is it called
that? It sounds more like "not mature = ready for prime time = don't use
this".

According to that link, regex is also in the nursery. According to crates.io,
regex depends on other crates maintained elsewhere, by a "random" single
developer, under a different licenses, with zero obvious guarantees.

~~~
Manishearth
Crates.io lists the authors as "The Rust Project Developers", and has the Rust
libs team as an owner. The dependencies are almost all maintained by Rust libs
team members or are otherwise trusted crates.

[https://crates.io/crates/regex](https://crates.io/crates/regex)

(Regex moved out of the nursery a while back)

The nursery is more of a "These crates are officially blessed and we wish to
make them part of rust-lang, unless the community comes up with something
better".

The guarantees aren't advertised, they're known. We can do a better job of
advertising this, some of the work this year is related to that.

~~~
1wd
Sorry, I meant the author and license of e.g. this dependency of regex:
[https://crates.io/crates/aho-corasick](https://crates.io/crates/aho-corasick)

I'm sure the Rust team knows and trusts these (or they even are Rust team
members), but how should outsiders know this?

Researching trustworthiness of individual authors, getting approval for
different licenses, tracking and updating required notices in documentation
etc. for every single dependency _transitively_ (!) seriously takes a lot of
effort. Updating dependencies that switch sub-(sub-...)-dependencies freely
can turn from a simple cargo command into a month of work. A big standard
library (or an equivalent construct) can really save the day there.

> The guarantees aren't advertised, they're known.

It is known. -- Jhiqui

Glad to hear improving this is in the works anyway.

