
Rust 1.1 Stable, the Community Subteam, and RustCamp - steveklabnik
http://blog.rust-lang.org/2015/06/25/Rust-1.1.html
======
kibwen
The 1.1 release came out a day earlier than I expected, I suppose we're
releasing on Thursdays now. :P Note that 1.1 is a relatively small release,
since, due to launching the train release model, it was in development for
just three weeks prior to 1.0 (rather than the usual six weeks that all
subsequent releases will have spent in development), and during that time we
were all understandably in a tizzy preparing for a post-stability world. :)

However, despite that short and distracted development window, we still
managed to squeeze out compiler performance improvements that should result in
30% faster compiles for crates in the wild. You can expect even more progress
on the compilation speed front for 1.2, due to be released August 6, along
with a slew of stabilized and much-demanded stdlib APIs.

Let me also mention that tickets have just gone on sale for the first official
Rust conference, a small one-day event in Berkeley:
[http://rustcamp.com/](http://rustcamp.com/) We'll be using the experience
from this proto-conference as a guide for larger events in the future, so even
if you can't go we'd love to get your feedback as to what you'd like to see
from a Rust conference.

~~~
kbenson
If I wasn't going to be on vacation during that conference, I would be
strongly tempted to go, and I haven't written a line of rust. I get excited
about every rust submission I see on HN though, and greedily gobble up as much
information as I can. I can't help it, Rust just excites me.

So, whatever you guys are doing, WRT marketing, you are doing _something_
right.

~~~
mlitchard
What I like about rust is how I think it will go together really well with a
language like idris. The idea is, whatever rust cannot guarantee an idris-to-
rust transpiler can. People should have a much easier time making solid low-
level code in the future.

~~~
cwzwarich
Idris is already more safe than Rust. What would this give you?

~~~
jroesch
Unfortunately safety is not the only concern. Idris' tooling is severely
limited. There are very few executables written in Idris (and even fewer that
aren't bit-rotted), the build tooling and package management are very simple,
the runtime is heavily optimized, concurrent or parallel (like GHC's) and the
single-threaded performance is far from Rust's.

I want to be clear that I'm not hating on Idris I love the goals of the
project and am probably one of the few people outside the core contributors
who has written a backend for the compiler, but you can't really compare a
production quality compiler with a full time team of 10 or so to a research
compiler worked on by researchers (who have different goals) and volunteers.

Edit: To clarify for this reason I could see why it would be cool to be able
to write some critical code in Idris and extract to Rust where you could get
performance and tooling for the rest of your application.

------
exacube
I'm happy things are moving along, but I would still like to see the
documentation be more polished. I still don't know how to write a task queue
(ie queue of closures) that executors can concurrently read and run from.

I don't feel like the docs empower me enough to write multi threaded code
comfortably without the borrow checker spitting at me. Is it just me, or does
anyone else feel this way?

~~~
steveklabnik
When you start documenting a language from scratch, you have to start at the
beginning. A language is a huge project as well. The current book is about
~250 pages when rendered as a PDF. I've finally gotten to the point where the
basics of almost everything have been documented, and am starting to move on
to more intermediate style things.

In addition, we've only had a stable Rust for six weeks: there just hasn't
been enough time to write more advanced things. Nobody wants to invest in
stuff while things are still changing. As an example of this, I know there's
an O'Reilly book coming out in the fall which covers advanced topics
exclusively.

A basic task pool isn't too many lines of code: [https://github.com/rust-
lang/threadpool/blob/master/src/lib....](https://github.com/rust-
lang/threadpool/blob/master/src/lib.rs) Hopefully that can help for that case,
though obviously, this isn't just a comment about threadpools :)

~~~
kybernetikos
I love the rust docs, but I do agree that the intermediate/advanced stuff is
missing. I won't feel like I truly understand until I can implement a bunch of
different datastructures, and it turns out that that is exactly the kind of
code that throws up lifetime issues that as a beginning rust programmer I'm
not really prepared to deal with.

I'd love a 'learn to write rust with datastructures' style intermediate
tutorial.

~~~
elektronjunge
You may also be interested in this post[1] by nrc for a couple of strategies
for implementing graphs. And this companion[2] by Niko Matsakis.

[1]
[https://github.com/nrc/r4cppp/blob/master/graphs/README.md](https://github.com/nrc/r4cppp/blob/master/graphs/README.md)
[2]
[http://smallcultfollowing.com/babysteps/blog/2015/04/06/mode...](http://smallcultfollowing.com/babysteps/blog/2015/04/06/modeling-
graphs-in-rust-using-vector-indices/)

------
gamegoblin
I hope the Rust team also starts prioritizing compiler crashes.

I started using Rust exclusively for hobby projects after the 1.0 release, to
force myself to learn the language, but I found myself running into compiler
panics on nearly a daily basis.

Admittedly, the code the compiler tended to crash on was very macro-heavy, but
a goal of rust is safe macros. (And even if the macro-expanded code was
invalid, the compiler should just report an error, not crash).

There are currently 207 open issues regarding ICE (Internal Compiler Error):
[https://github.com/rust-lang/rust/labels/I-ICE](https://github.com/rust-
lang/rust/labels/I-ICE)

~~~
Jenny1975
I've seen this complaint about the Rust compiler a number of times now, here
and at other sites. Isn't one of the main selling points of Rust that it's
supposed to make it much harder to write code that crashes? It is my
understanding that the Rust compiler is mostly written in Rust. While maybe
these ICEs aren't traditional segfaults that can be exploited, they're still
unexpected crashes none the less! The software stops working without warning.
If the best Rust experts around have so much trouble avoiding those kinds of
crashes, then how is an average Rust user, or even a complete beginner like
me, supposed to write Rust code that's any less susceptible to crashing?

~~~
steveklabnik
TL;DR: don't underestimate the power of technical debt.

Longer answer: The Rust compiler was written in Rust before the Rust language
was even what it was today. As one particular example, the AST used to be
garbage collected! And when you have a codebase that's 320,000 lines long, you
don't update the entire codebase to the latest idiom, because if you did,
you'd never actually ship the language.

Basically no other Rust program will ever have to contend with this kind of
situation. As such, while I can sympathize with this line of argument, I don't
think it's representative.

EDIT: I previously had 750,000 but it's actually 323,326 LOC as of right now.
Whoops!

~~~
Jenny1975
Legacy code and inexperience with new technologies are not problems that are
unique to Rust and the Rust compiler. And presumably Rust will continue to
evolve, will it not? If my team starts a large, multi-year project using Rust
1.1 today, does Rust offer anything that will help us avoid the sorts of
crashes that the Rust compiler suffers from?

~~~
Aatch
Just to expand on what Steve said.

An evolving language is one thing. Pre-1.0 was more like many stages of
violent metamorphasis. Some changes to the language required changing almost
every line of code in the tree. Normal technical debt is when you find an old
approach doesn't work any more and you need to fix it. Much of rustc's
technical debt is from things like features disappearing from underneath it,
or things designed before the features that you would use now even existed.

Looking at rustc as a regular large Rust project is unfair. A new project can
at least assume that the features you are using today will exist tomorrow and
design with that in mind. Your designs may become obsolete due to new
features, but you aren't going to have to pick between a hacky workaround and
a redesign/rewrite of 1000's of lines of code.

------
alricb
Have there been documentation improvements? For instance [http://doc.rust-
lang.org/nightly/std/str/](http://doc.rust-lang.org/nightly/std/str/) is still
quite obscure: it talks about the traits returned by certain methods, but
there isn't an obvious way to get to the documentation for those methods, if
you'd like to know how .lines() is different from .lines_any(), for example.
Compare with
[https://docs.python.org/3/library/stdtypes.html#str](https://docs.python.org/3/library/stdtypes.html#str)
where all the methods are listed, along with what they do.

~~~
gmjosack
You probably want this page for str:

[http://doc.rust-lang.org/nightly/std/primitive.str.html](http://doc.rust-
lang.org/nightly/std/primitive.str.html)

It's unfortunate that most of the links navigate you to the less useful doc.

~~~
bpicolo
I'm getting bizarre rendering errors in chrome for whatever character prefixes
"self" in all those (I assume &?)

~~~
kibwen
People were hitting that a few months ago, is this the first time that you've
visited the docs in a while? In their case it was due to a problem with the
page's font file itself, and it may be that your browser still has that
version of the font cached. Maybe try a force-refresh?

~~~
bpicolo
Hmmm. Force refresh did nothing. It's possible I have Source Code Pro like the
other commenter suggests. Dunno

------
jrapdx3
I'm glad to see Rust's progress. I'm still very interested in Rust, and
incrementally learning the language. I do appreciate the documentation, IMO
the developers have done a tremendous job in that respect.

One question though. When is Cargo going to be available on FreeBSD (and other
BSD's)? I think these platforms are significant in the server space where Rust
would be highly relevant. Having Rust usable there would likely augment uptake
of the language.

~~~
brson
I've heard progress on this front recently (it's mostly about the automation
infrastructure), and I might expect official nightlies of both rustc and cargo
for FreeBSD by the end of summer.

Don't hold me to that.

------
mwcampbell
What exactly does MSVC support entail? For example, will one be able to debug
Rust programs with WinDbg or the Visual Studio debugger? IIUC, that would
require LLVM to output PDB files.

~~~
alexcrichton
In addition to not interacting with the GNU toolchain at all (through MinGW),
MSVC support will indeed enable native Windows debug info (as you mentioned)
so native tools can be used to debug Rust code. Note that this isn't 100%
implemented yet, but it's coming soon! Additionally you'll get interoperation
with MSVC-compiled libraries. Libraries compiled with MinGW don't interoperate
well with MSVC (and vice versa), so this enables Rust code to link against an
MSVC-compiled native library.

~~~
jnbiche
Will MinGW still be supported, or will that be dropped?

~~~
steveklabnik
There's no plan to drop it.

------
bfrog
Impressed daily by the amount of stuff being done to advance Rust as an
incredibly useful language.

------
alexnewman
OOh and there's a rust podcast out as well. You can find it in the new section
of hacker news.

~~~
kiliancs
Just providing the direct link [http://rustyrad.io/](http://rustyrad.io/)

------
worklogin
So I assume 1.x.x won't break features from 1.0? Is Rust using proper semantic
versioning?

~~~
MetaCosm
Rust core team has taken the approach of breakage without major version
increments being acceptable as long as they deem the breakage "minor" (based
on crates.io and companies they have close relationships to).

~~~
kibwen
Qualifying with "close relationships to" is misleading, as _every_ company
using Rust is welcome to sign up to receive new versions of the compiler to
run against their codebases to test for regressions. See the email address in
my profile if you'd like to add your company to our list!

~~~
MetaCosm
OK -- replace "close relationships to" to "have emailed kibwen at his gmail
address to get on a list".

If I could go back and edit I would -- but it has been too long.

------
throw982734
Given Steve Klabnik's recent actions to suppress people who hold political
opinions he does not like, I have a considerable amount of trepidation knowing
he has a leadership position in the community sub-team.

~~~
kibwen
Would you like to cite a source?

~~~
throw982734
[https://gist.github.com/steveklabnik/7cd3267a631c4847c34d](https://gist.github.com/steveklabnik/7cd3267a631c4847c34d)

amongst more

It is especially troubling to have a community leader who equates speech with
violence, even "hate" speech, which in that gist is clearly demonstrated to be
completely subjective.

~~~
kinghajj
That is troubling, but I don't see how that equates to him "suppressing"
anyone, if all he's done is voice his own opinions about those people. I
haven't really followed the story, but was Steve part of the group that
demanded Curtis be removed from StrageLoop?

~~~
hates_shrooms
Worse even.

[https://archive.is/BtDaA](https://archive.is/BtDaA)

~~~
steveklabnik
I wasn't going to respond to this thread at all, but since you went to the
trouble of using 100% of your comments on this account to post in this thread,
and you're spreading this shenanigans, I'll copy what I said over at
Lobste.rs:

\--------------

[This link] takes a thing I said on Twitter and uses it to say something I
don’t mean.

My twitter reply re: violence is based on the tweet it’s replying to: general
activity by groups who call themselves ‘antifa’. I thought my parent was
making a false equivalence, but rather than arguing with them about this false
equivalence, I decided to just say ‘cool’ and bow out, hence my response. I
believe “antifa are just as violent as the fascists” is wrong on multiple
levels, but I don’t really care to get into it here, to be honest.

\--------------

... and I still don't. That's all I'll be saying here about this.

~~~
puredemo
Dude, you explicitly said you're "100% okay with [violence] personally"

You then said, "the only things fascists respond to is violence. Ignoring them
or letting them attack you doesn't help."

You then linked to a Woody Allen video where he confidentially states a Nazi
march in NYC should be attacked with "bricks and bats" rather than taking a
civilized approach against them.

You explicitly endorsed violence against political groups you dislike several
times, don't try to pretend like you didn't now..

~~~
kungfooguru
I'd be suspcious of anyone who wasn't ok with violence against Nazis...

~~~
hates_shrooms
Of course "Nazi" being anyone who doesn't go along with your bullshit.

------
JeffKilborn
While I find Rust interesting, how exactly will Rust deal with a 900lb gorilla
that's about to get released from a cage?

Opensource Swift is only few months away and it already has a much bigger user
base and is backed by the biggest company in tech. Rust & Swift share many
common traits and kinda look alike as well.

Why should anyone pick Rust over Swift when Swift will be able to do
everything Rust can do and is also positioned as a systems programming
language? And Swift will also be a full-stack programming language and you
will be able to program apps and backends with it.

I feel like Rust is about to get killed. And killed quickly.

~~~
kibwen
Swift is an applications programming language where the runtime is non-
optional (at least AFAICT) and memory is managed dynamically. It will be
competing with .Net and Java, not with C and C++ (though, as ever, there are
surely plenty of C++ projects that don't actually need C++'s level of control
and could benefit from a rewrite in Swift).

Swift isn't going to penetrate to the bottom of the stack with pervasive
reference counting. You'd either have to start managing memory manually (as
per C) or implement a borrow checker (as per Rust), and even then your entire
ecosystem is still going to use reference counting pervasively due to the
language's defaults. One of the benefits of Rust defaulting to linear types
and borrowed references is that it creates an entire package ecosystem where
dynamic memory management is the exception, not the rule.

For the record, I think Swift is super fantastic as a language and I'm
thrilled that it's going open-source. I think the two languages will work
swimmingly together. :)

~~~
JeffKilborn
>Swift is an applications programming language where the runtime is non-
optional (at least AFAICT) and memory is managed dynamically.

No, it's optional if you don't need to interact with Obj-C frameworks (ie.
Cocoa). And memory is not managed dynamically. Swift uses ARC.

Like I said, I just don't see Rust sticking around for long. Swift will suck
all the developers out of it since you'll be able to actually get a job
programming in Swift.

~~~
kibwen
We'll need to see how useful Swift is without Cocoa (still waiting for details
on what's actually being open-sourced), but GCD is a runtime component as
well. And as Manish has said, ARC is dynamic memory management, just like
shared_ptr in C++ and Rc in Rust, though pervasive and implicit. If you'd like
to convince me that Swift is suitable as a systems programming language, then
you'll first have to show me an example of Swift code that can be compiled
into a standalone binary that can be called from C, and then describe how many
features of the language and standard library this disables. After that you
can demonstrate how to run Swift code on a memory-constrained platform that
doesn't allow dynamic memory allocation whatsoever.

If anything, Rust is the only modern language that's _not_ threatened by
Swift, by virtue of existing at a level of the stack that's so low as to be
out of Swift's reach. I agree that Swift is going to be huge, but you're
mistaken as to who its competitors are. :P

~~~
Manishearth
C++14 _isn 't_ a modern language? Aw, you killed a dream there :P

