top | item 5486433

Rust 0.6 Released

186 points| metajack | 13 years ago |mail.mozilla.org

115 comments

order
[+] steveklabnik|13 years ago|reply
From the release notes[1]:

    > While we cannot promise that this is the last time there will be incompatible
    > changes, the great majority of anticipated language-level changes are
    > complete in this version
I'm quite excited about this.

1: https://github.com/mozilla/rust/wiki/Doc-detailed-release-no...

[+] PommeDeTerre|13 years ago|reply
The most exciting thing about Rust is that we keep seeing something that's already pretty good continually getting better and better.

This is much different than what we're seeing with the evolution of, say, JavaScript or PHP. There, the languages are pretty horrific to begin with. Any "improvements" tend to be yet another hack layered upon one or more earlier hacks. Even in the best cases, these "improvements" are merely bringing JavaScript and PHP to where many other languages were 10 or 20 years ago (if not going back much earlier).

I think the fact that Rust is already so coherent makes these improvements and refinements much more impressive. It's much harder, and requires more real innovation, to improve something that's already great to begin with. Yet that's exactly what we're seeing with Rust.

[+] mhartl|13 years ago|reply
Mozilla and the Rust community are pleased to announce version 0.6 of the Rust compiler and associated tools. Rust is a systems programming language with a focus on safety, performance and concurrency.

This is how you do an announcement right: you include a short description of the product along with the announcement. This way people who don't know WTF Rust is are immediately brought up to speed.

[+] film42|13 years ago|reply
Call me a noob, but I have never been properly introduced to Rust. Does anyone know of a good article or walk through with pros, cons, and examples?
[+] drbawb|13 years ago|reply
This isn't a tutorial, but I found pcwalton's explanation of memory management in rust[0] to be an excellent primer for the different allocation techniques in rust.

Learning the different types of pointers was a real pain point for me; so I'm very thankful for this post. Maybe it will help you out while you're learning!

[0]: http://pcwalton.github.com/blog/2013/03/18/an-overview-of-me...

[+] kibwen|13 years ago|reply
The language is still changing so fast that nearly every resource that you'll find will be outdated. Your best bet is likely the official tutorial,[1] which probably doesn't contain too many references to deprecated features.

[1] http://static.rust-lang.org/doc/tutorial.html

[+] steveklabnik|13 years ago|reply
I wrote a 'book' (it's about 50 pages) you can read online called "Rust for Rubyists".

Two things: It's for 0.5 (I'll be updating it to 0.6 later today/tomorrow) and 'for Rubyists' means I assume you don't know anything about systems programming, there's very little that's Ruby-specific.

http://www.rustforrubyists.com/

[+] terhechte|13 years ago|reply
It is interesting how many of these newer languages clearly try to improve upon a specific older, established language (at least imho) (take with a grain of salt).

C++ -> Rust

C -> Go

Java -> Scala

Lisp -> Closure

Erlang -> (Go or Scala)

Javascript -> (Too Many; Dart, et al)

(Edit: Formatting)

[+] masklinn|13 years ago|reply
> C -> Go

Most of C's use cases, Go can't even remotely be used for. It's basically limited to the "network server" use case. It's not portable, it's not a linga franca (via FFI for non-C languages), it's not low-overhead, it's not runtime-less, ...

> Erlang -> (Go or Scala)

Yeah... no, especially not Go. In Erlang's inception, concurrency was first and foremost a tool for reliability (from its telecom roots where 1 = 0, so 1 server means the same as not having a server). Just about none of Erlang's reliability mechanisms are present in Go.

[+] old-gregg|13 years ago|reply
As much as I like Golang, it is not a replacement for C. The major reason C is so popular because it's the only portable medium for performant code which can be shared across many languages because it doesn't impose any runtime on you.

Go comes with a VM. It lives in its own world, it cannot live in the worlds of other VMs like C can. It's more like high-performance Python (or simpler+slower C++) optimized for concurrent network services.

I'd say that Rust and probably D are good candidates for replacing C.

[+] steveklabnik|13 years ago|reply
To be fair, with Rust it's more like

    C++ -----
             \
    OCaml ------> Rust
             /
    Erlang --
[+] rdtsc|13 years ago|reply
As someone already mentioned, -1 on Erlang-> (Go or Scala)

They didn't try to improve they removed features such as error handling, distribution, all which are very important for building fault tolerant system.

Paradoxically perhaps, I see it inverted:

(Go + Scala) -> Erlang

Temporal sequencing doesn't necessarily imply strict improvement.

[+] kenko|13 years ago|reply
Go or Scala attempt to improve on Erlang? Elixir attempts to improve on Erlang---that I can see.
[+] Kototama|13 years ago|reply
It's Clojure, not Closure. Google Closure is an optimizing JavaScript to JavaScript compiler.

I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations.

[+] epsylon|13 years ago|reply
> Lisp -> Closure

There is no single "Lisp", but many dialects including Common Lisp, Scheme (and its bazillion variants), Clojure, Emacs Lisp, Arc...

> Java -> Scala

Except for the fact that Scala is based on the JVM and partly reuses the Java standard library (for interoperability reasons), the language is the product of many influences, including ML, Haskell, Java, Scheme, Eiffel... The syntax and the "feel" of the language is actually quite far from Java thanks to its functional side.

[+] wrl|13 years ago|reply
`Static methods no longer require the `static` keyword and instead are distinguished by the lack of a `self` parameter`

Man, am I the only one who really doesn't like implicit things like this?

[+] pcwalton|13 years ago|reply
This change improves consistency between implementations and modules. `impl MyType { … }` is now just like `mod my_module { … }`, except that you can define methods inside `impl` declarations by including a self parameter.

For example:

    struct MyType { … }
    impl MyType { pub fn foo() { … } }
    mod my_module { pub fn foo() { … } }
    fn main() {
        MyType::foo(); // works
        my_module::foo(); // works too
    }
[+] efuquen|13 years ago|reply
Well, it does kind of make sense. If you never access anything from self then for all intent and purposes there is no reason the function shouldn't be static. That's just my initial perspective reading your comment, not knowing much about the language, so I might be missing some possible scenario this would actually result in a runtime error.
[+] jeremyjh|13 years ago|reply
Actually I think its much more explicit that self is ALWAYS passed as a parameter, or it doesn't exist.
[+] kzrdude|13 years ago|reply
Your comment is funny since the other part of the change you cited is the introduction of explicit self.
[+] drbawb|13 years ago|reply
Awesome! I'm going to compile `release-0.6` right now, because I've been having some issues w/ trunk these past few days.

Simple things like declaring fixed vectors won't compile for me: `let numbers: ~[int, ..3] = [1,2,3];` fails to compile saying it expected `~[int * 3] and got ~[<VI2>]`. That's an example straight from the tutorial.

I'm getting segfaults when iterating over a non-fixed vector of owned elements casted to a trait. (This works fine if I access the elements directly; or use managed pointers. With owned pointers my `len()` method returns the wrong number of elements, which I suspect is breaking the iterators.)

[+] pcwalton|13 years ago|reply
The tutorial examples are run as part of the test suite. The tutorial example in question is `let numbers: [int, ..3] = [1, 2, 3];`, which should work.

There are several known compiler bugs with any trait types other than `@Trait`. Please do continue to file any bugs you find, though—all crash bugs are bugs that need to be fixed :)

[+] pjmlp|13 years ago|reply
Great!

Time to upgrade.

Just as a side note, I am looking forward to the day I won't need to recompile LLVM as well.

[+] ksec|13 years ago|reply
Slightly Off Topic: Wasn't Rust suppose to be the codename or working name of the languages. Or Has Mozilla decide to simply use Rust as its official name?
[+] icambron|13 years ago|reply
I don't know the answer to that, but the problem may be that Rust is decent enough name to overcome any proposed name changes. I've always thought you should use implausible codenames for just this reason. It forces you to change it instead of just letting the codename establish itself by momentum. I've always assumed that's why Microsoft uses terrible codenames like "Longhorn".
[+] nnethercote|13 years ago|reply
I'm pretty sure Graydon always intended Rust to be the final name.
[+] coldtea|13 years ago|reply
Never heard something about it being just a codename. Why would it be? Rust is quite nice itself and has already 1-2 years of being established.

It even makes sense as an faux-etymology.

Rust: because it's close to the metal and brings some breathing oxygen to the stale system's language arena...