
Rust 0.5 released - graue
https://mail.mozilla.org/pipermail/rust-dev/2012-December/002787.html
======
kibwen
0.5 was a rather smaller release than previous ones, due to Niko being
distracted by RiverTrail[1] and ParallelJS[2] and Graydon being distracted by
setting up the new Buildbot infrastructure as well as relicensing the
compiler.[3] There have been some big changes (most for the better, IMO), but
there's still a rather lot of half-finished things floating around. All the
same caveats of past releases apply: work in progress; use at your own risk;
the language _will_ continue to change; code that you write now _will_ break
in subsequent releases.

0.6 should be a rather exciting cycle though. I'm hopeful that a lot of the
semantic cleanup will be more-or-less complete. Also, they're getting a new
but temporary full-time developer in the form of John Clements,[4] who's
taking a sabbatical from his university position to work on Rust.

[1] <https://github.com/RiverTrail/RiverTrail/wiki>

[2]
[http://smallcultfollowing.com/babysteps/blog/2012/12/05/self...](http://smallcultfollowing.com/babysteps/blog/2012/12/05/self-
hosted-parallel-js/)

[3] <http://thread.gmane.org/gmane.comp.lang.rust.devel/2593>

[4] <http://www.brinckerhoff.org/clements/>

~~~
pcwalton
"code that you write now will break in subsequent releases."

It's not that bad; we're trying to be mostly backwards compatible from here on
out. I was hoping that 0.5 would be the backwards-compatible release; it's
not, mostly due to the name resolution changes that still aren't done, but
it's close. It should not be much work to upgrade your code from 0.5 to 0.6,
much less than 0.3 to 0.4 or 0.4 to 0.5.

------
pnathan
I've really become quite a Rust fanboy, although I haven't written tons of
code in it.

IMO, it's considerably more accessible than Haskell or a ML-family. I'm not
precisely sure why, but it seems to "make sense" in a very straightforward
way. Some of it I think is lessons-learned from older languages, some of it
might be the syntax, some of it just might be mental fit.

Certainly - and this is a _huge_ deal - I could realistically see using Rust
in an enterprise scenario where we don't null pointer exceptions but we do
want type safety yet we don't want to buy into Java or go full functional
programmer with Haskell. Of course that's a few years out, _but_ , but but!
That's cool!

I look forward to using this latest version and working away on writing Rust
at home. :-)

~~~
chimeracoder
> I've really become quite a Rust fanboy, although I haven't written tons of
> code in it.

As someone who's been meaning to try it out for a while, I have a couple of
questions for you.

First, how did you get started? I found the tutorial decent, but after reading
through it, I didn't feel like I could quite jump in and start writing code.
By contrast, I never actually read the Go spec/tutorials; I did a brief run
through the sample web application and was able to write everything else right
away (filling in from the documentation as needed, of course).

Second, how did you come to understand the memory model? I consider myself
more familiar in both functional programming and memory management than
average, but I found the memory model to be a bit of a conceptual hurdle (even
though I'm attracted to the approach on a philosophical level). Having such a
unique memory model makes it a little tough to simply get started writing code
right away.

Finally, how do you find the libraries in different areas? Web applications?
Scientific computation? This isn't really an across-the-board question, since
certain areas will probably be more complete than others, but what kind of
applications are currently easiest to write in Rust when getting started?

 __EDIT __: I understand they're different languages with different goals, but
I'm comparing everything to Go just because they're both emerging languages
that I started to try to pick up around the same time. I found Go much easier
to get going with (no pun intended), but I'm looking to catch up with Rust as
well.

~~~
pnathan
\- I don't have a good answer for you about how I started, I just got the
compiler running and started writing code. A BST, as it so happened.

\- I don't claim to understand the memory model entirely, but I think I have a
grasp on it. This is due to my knowing C++ and having a grasp of the lambda
calculus.

WRT libraries, it's not a mature language. It's not going to have the tens of
thousands of libraries like Perl. I would recommend writing applications that
fall into a functional programming/low level area, but that's just me. There's
Servo, a research web browser.

Finally, I don't recommend comparing Rust with Go. Two languages and two
different design goals. A better compare would be with D or OCaml.

~~~
dysoco
How is D or OCaml more Rust-like than Go? Can you explain?

~~~
pnathan
Rust is basically ML + C's lovechild. Sophisticated type inference, mostly
pure variables, pattern matching lambda functions, a few other FP goodies. But
it's also a fairly clean imperative language if you care to use it like that.
Generics, mutable variables, {}; syntax, pointers, etc. Also, more
fundamentally, I see D, OCaml, and Rust as occupying a "let's be clean" kind
of space.

I see Go as occupying a "let's be scruffy" space; not really pushing the
language state of the art, focused on industrial work; it's like a type-safer
& compiled python, afaict. It doesn't really strive to push the state of the
art, it seeks to solidify certain well-known taken ground in programming
language design, and to be really focused on that.

I'm not going to apply a "better" metric, I don't think that's appropriate
because they are occupying different areas in the design space with different
goals. If they were posed as straight-up competitors, then it'd be appropriate
to measure them against each other.

~~~
dysoco
I'll have to check Rust then, seems interesting. Although I see Go as a clean
language: A "better" C and D as a "cleaner C++".

------
nullc
I'd hoped that rust would have a lot of powerful tools for typing and exposing
invariants and contracts— tools to help create provably reliable software. As
sexy as new programming tools are, the big problem in software today is that
we simply can't manage the complexity of it and as a result _everything_ is
full of bugs and unintended behavior. Addon layers like ACSL are hard to use
and messy because they work at odds with the language, instead, e.g. of being
integrated with the typesystem.

I was hopeful that rust could really advance the art here in the context of
practically usable systems (vs academic toys) and I suppose it does, but it
also lost features for formal analysis between versions and as its now
becoming stable I suppose they won't return.

~~~
pcwalton
I assume you're referring to typestate. One of the reasons that typestate was
removed is that practically everything you can do with typestate can be done
with session types instead. Constraints can be modeled as unique types with a
trusted transition function from state to state. The unique type system used
for memory management in Rust nicely doubles as a session type system. This is
actually done today with the pipes compiler—it uses unique types to statically
ensure that you can't violate a communications protocol, just as typestate
can.

One of our focuses for 1.0 is on aggressively pruning features that overlap,
to reduce language complexity and to avoid committing ourselves to language
features we might not need. However, future versions of the language might add
more static analyses as they prove useful.

~~~
doublec
Do you have any code examples of where this is used that I can look at?

Like nullc my interest is in the area of types being used to enforce contracts
and safetly (hence my interest in the ATS language).

Typesafe was my initial interest in Rust and I'd love to see examples of how
this is being approached in Rust as it is now.

~~~
pcwalton
Probably the best place to look at the moment is this presentation:
[https://air.mozilla.org/intern-presentation-message-
passing-...](https://air.mozilla.org/intern-presentation-message-passing-in-
rust/)

~~~
nullc
Perhaps I missed where it was explained— but I don't see how rust enforces the
type predicates (e.g. acquire vs wait state) there without typestate.

~~~
pcwalton
Say I have a protocol that transitions from A -> B -> C. Since the pipes
compiler creates the only constructor for type B, there's no way for you to
construct a value of type B (in the safe language) without giving up your one
value of type A. The uniqueness typing system prevents you from copying your
single value of A, and you must surrender all your references to it at the
time you transition to state B.

------
Direct
I'm a little rusty but I did read the 0.4 docs before and gave the language a
try, I'll dive into 0.5 again this weekend, I am a little confused by
something however. What's going on with strings? When I last looked, a lot of
the string operations worked with a specific pointer sigil[1]. If I'm using
managed boxes, and the methods take and return unique boxes, is it because I'm
using the wrong sigil for the job or should I expect to be able to use managed
strings?

Is this just me misunderstanding the memory model or is this something that
just hasn't been straightened our yet? I'm pretty confused about this in
particular, as I thought I understood the point of the different sigils pretty
well, but the way the library is written makes me wonder. This applies to
things other than strings I guess, but strings seem like a good example.

[1]:
[https://github.com/mozilla/rust/blob/master/src/libcore/str....](https://github.com/mozilla/rust/blob/master/src/libcore/str.rs#L197)

~~~
brson
It's not your misunderstanding, there is just very little library suport for
managed vectors (and strings). For quite a while managed vectors did not
exist, so owned vectors are everywhere.

The semantics of managed vectors and owned vectors are quite different and
unifying the library code so that managed vectors are more accessible will be
a challenge. It is a widely-felt problem though and some folks have ideas for
solutions.

For now, it is best to use owned vectors, but there are two modules,
`core::at_vec` and `core::at_str` that can help you if you need them.

~~~
Direct
Ah ok, brilliant. This was my main reason for not trying to play with Rust a
little more. I thought it was something I just didn't understand. Just out of
interest, is there anywhere I can have a look to see what kind of solutions
have been suggested?

------
dkhenry
I think once rust stabilizes a little more, its going to be a excellent
language. The real big thing is going to be stand alone rust programs. I know
they have two tickets open ,but I would love to be able to write rust programs
that don't require the core library to run.

------
kodablah
Yay, item macros. Means top-level elements can now dynamically created. Also
another big change is "auto-move" where you don't have to write move
everywhere.

Also the repl is nice. I think having this and having Rust bootstrapped give
it a leg up on Go.

~~~
swah
I was not aware Rust had macros. Does that mean one can write lispy things
like the "with-*" macros ?

Sorry, I'm afraid I'm confessing my affair with Emacs but I swore I'd leave
her behind...

~~~
kibwen
Rust's macros are generally Scheme-like (macro-by-example), although it's not
exactly the same since Rust obviously doesn't use S-expressions. See
<http://static.rust-lang.org/doc/0.5/tutorial-macros.html> for a little more
info on Rust's macros system.

------
tree_of_item
Do you still need to compile all of LLVM? I tried to install Rust a few days
ago and came back to my computer using gigabytes of swap space, which I assume
is due to LLVM.

~~~
kibwen
Yeah, for the moment it still uses a custom LLVM, so the first compile is
still a pain (though LLVM does build in parallel really well with -j8). I
really hope that the Rust devs make it a priority to upstream their LLVM
customizations, especially if they hope to be pegged to a stable LLVM release
by Rust 1.0.

------
ExpiredLink
What is the intended audience for this language?

"[Rust] supports a mixture of imperative procedural, concurrent actor, object-
oriented and pure functional styles. Rust also supports generic programming
and metaprogramming, in both static and dynamic styles."

IMO, Rust tries too much (norrowed pointers, managed boxes, owned closures,
...). I am convinced that the language(s) of the future will be simple and
safe.

~~~
ufo
If I understand correctly, they are aiming at things that usualy get built
with C++ nowadays. Its hard to get a sinple and elegant language here because
a big part of the appeal is having very tight control over memory layout,
execution order, etc.

------
jeremyjh
Really glad to see the REPL!

~~~
espadrine
I wonder whether anyone here knows how it is meant to work.

All my inputs fail with the following message:

> rust: task failed at 'no mode for lval',
> /home/tyl/files/cloud/rust/rust-0.5/src/librustc/middle/liveness.rs:1573

~~~
pcwalton
Just fixed this. I'll see if we can push out a Rust 0.5.1.

~~~
espadrine
Yay! Thanks ☺

This can, incidentally, be a great start for a tool like Why the Lucky Stiff's
"Try Ruby in Your Browser" [1].

s/Ruby/Rust/

    
    
      [1]: http://tryruby.org

~~~
kibwen
Incidentally to your incidentalism, I'm looking forward to the day when we can
run Rust directly in a browser via Emscripten:

<https://github.com/mozilla/rust/issues/2235>

------
minhajuddin
How is rust compared to Go?

~~~
tav
I love both. If you are writing a production app today, I would strongly
recommend Go. However, if you want to write an app that you want to take over
the world with in a year or so, I would strongly recommend coding it in Rust.

Go is a beautifully minimal language and very easy to learn. Rust isn't quite
as productive, but it won't be too foreign for most coders either — unlike the
Erlangs and Haskells of this world. And whilst I've never missed generics in
Go, I've already found them useful in Rust.

Rust's memory model takes a bit of time to understand, but it provides a lot
more power and flexibility than Go is ever likely to. To get the same kind of
fine-grained memory management in Go, you have to manually allocate and manage
[]byte slices. Not only does this get tedious, but you end up losing most of
the benefits of static typing as well.

Rust is also exciting due to the lower-level nature of tasks (the unit of
concurrency in Rust). Goroutines are awesome, but you are at the mercy of Go's
runtime/scheduler. In Rust, the potential is there to even do interesting
things like dynamically load new tasks at runtime — opening up possibilities
like Erlang's hot swapping so that code can be changed without ever stopping
the system.

However, despite the awesomeness of the language, Rust suffers from a terrible
standard library at the moment. Even when Go was first released in 2009, it
had a really impressive standard library. And, today, thanks to having
superstar hackers like agl and bradfitz on its team, Go has some of the
highest quality libraries around — especially in crypto, networking, http,
etc. In comparison, Rust's standard library is rather poor with little
attention having been paid to API design.

Rust also suffers in comparison to Go with regards tooling support. The 'go'
command-line tool is awesome. I've not had a single dispute over style guides
due to 'go fmt' and 'go doc'. The 'go fix' command really helped in auto-
updating my Go code as the language evolved. The 'go build' tool saves me from
having to write build scripts and Makefiles. And Go's (non-existent) package
management system is absolutely brilliant — just 'go get
github.com/user/repo'!

But, neither problems — quality of the standard library or tooling — are
intractable in Rust. In fact, now that the language is starting to stabilise,
I am highly confident that a lot of love and attention will be given to both
of those issues. This is also an area where we, the community, can also help
out a lot. Myself, I've slowly started working on a port of the 'go' tool
called rusty:

* <https://github.com/tav/rusty>

And, having found the Rust developer community to be extremely friendly on
#rust on irc.mozilla.org, I'm pretty sure they would be happy to have other
interesting hackers join in too!

~~~
onetwothreefour
Go has a great standard library in terms of breadth. The quality of the
standard library varies between packages though.

I wouldn't say they're higher quality than comparable Scala/Java libraries,
but I guess that's subjective.

Still love Go though, but really looking forward to a production ready Rust.

------
espadrine
Have you stopped using git tags for releases? (I haven't updated the repo in
quite a while, and `git tag` gives me all releases up to 0.3.)

~~~
nightpool
Github still seems to show tags on the releases:
<https://github.com/mozilla/rust/tags>

------
thomaslee
Huge congrats guys! I admit I'm still trying to figure out the nuances, but I
really like a lot of the ideas in the language. :)

------
iso-8859-1
Where can I find binaries for 32-bit Ubuntu 12.10? Or a VM image? Will the
Windows binary work in Wine?

~~~
mcpherrinm
You can grab 64-bit linux binaries compiled on Debian from
<http://mcpherrin.ca/code/mozilla/rust-0.5-binary.tar.bz2>

I don't know if that's helpful for you. I'll look into packaging stuff too.

