
Rust 1.0: Scheduling the trains - steveklabnik
http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html
======
Jemaclus
I'm pretty stoked about this. I've been following Rust since 0.4, and it's
been super fun to play around with. I have two major problems with it, but
none of them are Rust's fault -- purely flaws of my own:

1) I have no idea what to do with it. I'm primarily a web developer, and I
really want to get into systems programming, but I have no idea what to do
with it or where to start. I wound up implementing about 50 different Rosetta
Code things in Rust 0.9 and 0.10, but I still never came up with a really
solid use-case that I could start and finish.

That said, I've been really impressed by rust-doom
([https://github.com/cristicbz/rust-doom](https://github.com/cristicbz/rust-
doom)) and the new Iota editor
([https://github.com/gchp/iota](https://github.com/gchp/iota)), and I wish I
had the know-how to even start down that path.

2) Given that the last time I touched systems programming was in college (15
years ago), I've found it difficult to wrap my head around some of the
concepts (ownership in particular). I actually hung out in the IRC chat room
for awhile, but I felt more than a few times that people were treating me like
an idiot because of my questions ("Ha! You did X? Why in the world would you
do that??"), so I wound up not really going back. I'm sure it was all my
imagination and that I'm just being sensitive, but I think it would be very
helpful to have more people interested in getting new people on board --
specifically people like me, with over a decade of programming experience in
higher-level languages.

I guess the TLDR of this is: I love Rust, but I don't know what to do with it.

Congrats to the Rust team, though. 1.0 is a huge milestone. Good job!

~~~
saosebastiao
I feel like the projects where where rust is best positioned in terms of
comparative advantage fall into two categories:

1) Large and complex systems that are slow to evolve due to being written in
languages that are unsafe or are relatively poor in abstraction (in addition
to the immense domain complexity). Examples: SQL and/or distributed databases,
Paxos-ish systems, Operating Systems, IDEs, GIS, etc.

2) Extremely high performance systems on the fringe of research. Examples:
MIP/LP/CP/SAT Solvers, Theorem Provers, Formal Verification tools, Rete-based
Rule Engines, Machine Learning algorithms and frameworks, Statistical Samplers
for MCMC, etc.

Unfortunately (maybe, I don't really know if it will turn out well or not),
most of the hype for rust comes from back-end web developers. That is
fine...I'm sure there is some performance to eek out there...but it is also
trying to compete in an area where garbage collection has its greatest
competitive advantages (namely, long running server processes). The
comparative benefit is relatively small.

~~~
kibwen

      > most of the hype for rust comes from back-end web 
      > developers
    

It may seem that way because 1) most of the hype for anything programming-
related these days comes from back-end web developers, and 2) because back-end
web developers are the primary audience of HN. At Rust meetups that I've
attended I've seen interest in people doing video games, robotics, AI,
numerical work, databases... they just don't have as public and excitable a
forum as this. :)

~~~
saosebastiao
I honestly wish we could get some of HN's mobile crowd hyped on Rust. A Rust-y
take on Xamarin's ideas would be phenomenal, and with resource constrained
phones, the performance gain from not having garbage collection or reference
counting would be certainly welcome.

------
Sir_Cmpwn
I'm getting less optimistic about Rust. At first, I liked that they were
willing to make breaking changes pre-1.0 to get the language right. However,
leading up to 1.0 they've decided to leave cruft in, in the name of getting
the release out.

For example, the current build system is functionally equivalent to #including
a bunch of C files in your C project and only passing one file to cc. I
brought this up and had a long discussion about it and how it might be
improved with the community, but then when core contributors showed up, the
discussion was shut down with the justification that "1.0 comes in a month".
I've heard other stories about poor management of the project and I'm just not
as excited about Rust as I used to be.

~~~
fngegngkg
Agreed. At this point Rust is already looking rusty. A solution desperately
searching for a problem. We need something to replace C (so we are told), but
maybe Rust won't be that tool.

~~~
throwawayanonon
The C and C++ hate comes mainly from web developers and language hipsters.
They dominate the echo chambers of HN and /r/programming.

When you mention you are a C programmer or like coding in C, they begin to
blabber about C being legacy, Rust this, and Go that (languages they think are
more like Python). All in an effort to cope with the insecure feelings they
have because the C programming language and C++ (read: pointers) intimidate
them.

~~~
pcwalton
> All in an effort to cope with the insecure feelings they have because the C
> programming language and C++ (read: pointers) intimidate them.

You have to know pointers and manual memory management to program in Rust.
Rust isn't there to save you from having to learn about pointers. Rust is
instead a reaction to the empirically observed fact that nobody [1] has ever
written a multi-million-line program with a large team in C or C++ without
accidentally making dangerous memory-management-related mistakes, and "just
program better" is an approach that has been tried, and failed, again and
again and again.

[1]: OK, maybe the Mars rover and the like are counterexamples, but the
extreme amount of verification required means that this approach is far too
costly to be practical for most software development.

~~~
throwawayanonon
Rust will not replace C. Rust will merely exist.

~~~
pcwalton
Sure, Rust's goal isn't to convert all users of C everywhere. C is immortal;
that'd be unrealistic. Our goal is indeed to exist alongside C—and to provide
a more productive, more secure alternative. :)

------
asb
I do wonder if Rust 1.0 is being branched just a little bit too early. I
understand that you have to draw a line in the sand somewhere, and the rolling
release model means new features can be rolled out quickly. On the other hand,
I'm rather disappointed that the ergonomics of error handling may change
substantially after 1.0. This is something that is going to affect every
single Rust program written, and people may be surprised if 'the best way' to
do this changes after 1.0.

[https://github.com/rust-lang/rfcs/pull/243](https://github.com/rust-
lang/rfcs/pull/243)

~~~
deathanatos
Are they really ready for a 1.0? I'm looking at the standard library, and
things (or core functionality of things) like file-system I/O, vectors,
strings, _iterators_ … are marked as "experimental"; I was particularly
curious as to how they were going to deal with iterators, since I think this
is a particularly hard problem. (In many languages these are either pointers
(C++) or close to it.¹)

I wouldn't really consider a language without a standard library "complete",
and a good standard library is important to me in a language. (As it's going
to help you get stuff done.)

¹Python, for example, doesn't specify iterator invalidation rules AFAICT; you
just have to look at what CPython does. And in CPython, there are ways to make
an iterator return a sequence of items that does not make any sense. (e.g.,
the same item twice, or skipping items…) In C++, invalidation is well-
specified, but the compiler doesn't really help catch errors.

~~~
aturon
I completely agree that a strong standard library is essential, and we've been
working very hard over the last months to set explicit conventions, revamp
APIs, and generally get Rust's standard library into a 1.0 state.

You shouldn't read much into the "experimental" tags right now; they're part
of an API stability tracking system that is heavily in flux at the moment. In
particular, for most of the modules you mentioned, only the module name itself
has not been marked "stable", while the contents have been. For example, if
you look at the Vec type itself:

[http://static.rust-
lang.org/doc/master/std/vec/struct.Vec.ht...](http://static.rust-
lang.org/doc/master/std/vec/struct.Vec.html#)

you'll see that most methods are unstable or stable, rather than experimental.
(The "experimental" status is currently the default, to help us keep track of
API "stabilization" progress.)

This stability tracking is part of our general story about API compatibility;
you can read more at

[http://blog.rust-lang.org/2014/10/30/Stability.html](http://blog.rust-
lang.org/2014/10/30/Stability.html)

These markers won't take on their full meaning until we ship 1.0.

For 1.0, _all_ of the APIs you mentioned will be "stable", and indeed most of
their internals already are. Over the next few weeks, we'll be updating
stability markers to reflect the API scrutiny and design work that we've been
doing.

More generally, for all but a couple of the modules listed at

[http://static.rust-
lang.org/doc/master/std/index.html?search...](http://static.rust-
lang.org/doc/master/std/index.html?search=#modules)

we have already performed a detailed scrutiny of the API, and have either
landed changes needed for 1.0 or will do so very soon. Most truly experimental
APIs have already been deprecated or removed.

For IO in particular, you can read a very recent RFC that proposes the final
set of API changes for 1.0:

[https://github.com/rust-lang/rfcs/pull/517](https://github.com/rust-
lang/rfcs/pull/517)

Hope that helps!

------
scanr
I really, really hope that abstract return types make it in or are not
considered a breaking change for a future release:

[https://stackoverflow.com/questions/26329231/returning-a-
sim...](https://stackoverflow.com/questions/26329231/returning-a-simpler-
iterator-interface-instead-of-a-map-in-rust)

[https://github.com/rust-lang/rfcs/pull/105](https://github.com/rust-
lang/rfcs/pull/105)

~~~
aalvarado
Yup, seeing method signatures like these is discouraging:

``` core::iter::Zip<core::iter::FilterMap<'_,
(&std::collections::hash::set::HashSet<attr::Attribute>, &attr::Attribute),
&attr::Attribute,
core::iter::Zip<core::iter::Repeat<&std::collections::hash::set::HashSet<attr::Attribute>>,
core::iter::Map<'_, (&attr::Attribute, &()), &attr::Attribute,
std::collections::hash::map::Entries<'_, attr::Attribute, ()>>>>,
core::iter::FilterMap<'_,
(&std::collections::hash::set::HashSet<attr::Attribute>, &attr::Attribute),
&attr::Attribute,
core::iter::Zip<core::iter::Repeat<&std::collections::hash::set::HashSet<attr::Attribute>>,
core::iter::Map<'_, (&attr::Attribute, &()), &attr::Attribute,
std::collections::hash::map::Entries<'_, attr::Attribute, ()>>>>> ``

~~~
kibwen
Ha, we hate them too, which is why we're so eager to finalize their design so
that we can replace all of that hideous garbage with just `impl Iterator`. :)

And who knows, it might happen for 1.0 if enough people push on the design and
are willing to put in the legwork of implementing it.

~~~
aalvarado
thanks for your hard work. Sometimes we take simplicity for granted!

------
swetland
The biggest question I have regarding rust-1.0, is what's the likelyhood of
small/standalone binaries being possible? Last time I looked, while there was
talk about lightweight core libraries on the website, but the basic hello
world binary was 2MB+ _and_ depended on a bunch of shared libraries. I spent a
little time trying to figure out how to build static/smaller binaries without
much luck.

~~~
steveklabnik
It shouldn't be _both_ 2MB _and_ depend on a bunch of shared libraries, it
should only be glibc and libgcc. And you can make it smaller by asking Rust to
do dynamic linking rather than static linking.

The smallest known Rust binary is 151 bytes:
[http://www.reddit.com/r/rust/comments/2iwtjh/151byte_static_...](http://www.reddit.com/r/rust/comments/2iwtjh/151byte_static_binary_for_x8664_linux_in_rust/)

My sibling also has great info.

~~~
alkonaut
That must be under something other than windows. Rust on Windows definitely
still has issues with static linking, dependence on gcc libs for 32bit
exception handling etc. Being able to build smaller statically linked binaries
on windows is hopefully a priority.

~~~
steveklabnik
As I said before, a dependence on libgcc and glibc are expected. It's not an
issue with static linking, you don't generally statically link those two
dependencies.

~~~
swetland
Is that expected to ever change and/or does Rust expect to work with other
libcs (bionic? musl-libc?) Being able to build completely self-contained
static binaries can be very nice at times, and for embedded use, glibc is
pretty large...

I thought Rust used llvm for compilation? That makes the libgcc dependency
seem a bit odd. Maybe I misunderstood?

~~~
steveklabnik
Right now, it can't work with other libcs, but if you strip things down
enough, it's not required to use glibc either, for example, if you're building
an OS. You just end up throwing away a lot of the standard library. Check out
stuff like [http://zinc.rs/](http://zinc.rs/) for embedded Rust.

libgcc is used for stack unwinding, not for compilation. So it does seem a bit
weird at first :)

------
piokoch
Now Rust needs some killer app. Maybe a message broker, something like Apache
Kafka, maybe even with Java Messaging Service compatybility as an option. Rust
with its low level I/O and efficient memory management should enable creating
something very performant.

------
seren
What is the roadmap after 1.0 ? Is it going to evolve quickly ? Or will it be
the right time to join since things are going to be more stable ?

My question sounds obvious but depending on the project 1.0 can mean very
different things.

~~~
kibwen
1.0 only means "code that you've written against a stable release won't break
on future stable releases". Rust will still be evolving quickly for quite a
while, though we'll at least be free of this nonstop update-your-broken-code
treadmill that we've been on for years. :)

------
XorNot
So something that always holds me up with new languages: workflow.

What's a Rust development workflow look like at the moment, from editor, to
reference materials, to debugging? I tend to be an IDE person (which obviously
doesn't and won't exist for some time) so I'm pretty eager to hear how other
people have been doing it.

~~~
thristian
I've only dabbled in Rust, but my setup for writing Rust in Vim is pretty
similar to my setup for writing anything else: vim on one side of the screen,
where I do my editing and type ":make" to try and build it (with Vim's makeprg
configured to run "cargo test"). On the other side, a browser open to the Rust
stdlib docs, and a terminal for interactive testing.

------
alexandre_m
I predict some confusion about Rust crates.io and this project
[https://crate.io/](https://crate.io/)

------
jaredonline
This is incredibly exciting. Way to go Rust team!

------
does_not_matter
Lie #3: Code is more important than data

This is the biggest lie of all. Programmers have spent untold billions of man-
years writing about code, how to write it faster, better, prettier, etc. and
at the end of the day, it's not that significant. Code is ephemeral and has no
real intrinsic value. The algorithms certainly do, sure. But the code itself
isn't worth all this time (and shelf space! – have you seen how many books
there are on UML diagrams?). The code, the performance and the features hinge
on one thing – the data. Bad data equals slow and crappy application. Writing
a good engine means first and foremost, understanding the data.

[http://www.insomniacgames.com/three-big-
lies/](http://www.insomniacgames.com/three-big-lies/)

