> 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
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.
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.
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!
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.
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.
The tutorial is also pretty good (as are the supplemental tutorials), but they don't yet give you the full picture. For that you'll have to play and experiment and read some code.
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).
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.
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.
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.
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.
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
}
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.
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.)
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 :)
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?
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".
Just glanced at the discussion on LtU http://lambda-the-ultimate.org/node/4009, I wonder if the C++ hackers have swallowed, and if they are hearding them onto Haskell?
[+] [-] steveklabnik|13 years ago|reply
1: https://github.com/mozilla/rust/wiki/Doc-detailed-release-no...
[+] [-] PommeDeTerre|13 years ago|reply
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
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
[+] [-] drbawb|13 years ago|reply
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
[1] http://static.rust-lang.org/doc/tutorial.html
[+] [-] steveklabnik|13 years ago|reply
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/
[+] [-] metajack|13 years ago|reply
http://www.infoq.com/presentations/Rust
The tutorial is also pretty good (as are the supplemental tutorials), but they don't yet give you the full picture. For that you'll have to play and experiment and read some code.
You might start here for some code to read:
https://github.com/pcwalton/sprocketnes
[+] [-] terhechte|13 years ago|reply
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
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
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
[+] [-] rdtsc|13 years ago|reply
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
[+] [-] Kototama|13 years ago|reply
I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations.
[+] [-] epsylon|13 years ago|reply
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.
[+] [-] pjscott|13 years ago|reply
http://www.paulgraham.com/fix.html
[+] [-] wrl|13 years ago|reply
Man, am I the only one who really doesn't like implicit things like this?
[+] [-] pcwalton|13 years ago|reply
For example:
[+] [-] efuquen|13 years ago|reply
[+] [-] jeremyjh|13 years ago|reply
[+] [-] kzrdude|13 years ago|reply
[+] [-] shared4you|13 years ago|reply
[This was for RC though]
[+] [-] drbawb|13 years ago|reply
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
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
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
[+] [-] icambron|13 years ago|reply
[+] [-] nnethercote|13 years ago|reply
[+] [-] coldtea|13 years ago|reply
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...
[+] [-] charlescearl|13 years ago|reply
[+] [-] steveklabnik|13 years ago|reply