Rust 0.5 released
mail.mozilla.org
mail.mozilla.org
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...
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.
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. :-)
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.
>First, how did you get started?
I always find a project I kinda want to do, and apply the language to it, not the other way around. In my case, I need to read JVM .class files [1]
>Second, how did you come to understand the memory model?
The compiler is really strict and won't let you do certain things without explicitly stating (copying, changing pointer types, etc). Basically you have to ask yourself what you're doing w/ the data, then apply the box you want.
>Finally, how do you find the libraries in different areas?
Cargo is all there is [2]. Obviously the ecosystem is thin right now, but it's really easy to wrap C libs. As for what's easiest, not exactly sure, it's a pretty general purpose language, but pretty low level.
[1] - https://github.com/cretz/patina [2] - https://github.com/mozilla/cargo-central
http://tomlee.co/2012/12/managed-and-owned-boxes-in-the-rust...
I'd recommend reading Tom Lee's post (linked previously) on the subject of pointers.
On the subject of libraries, there is a lot of work yet. The plan has been to get the language stabilized then start focusing on libraries and tooling.
The core and standard libraries are not very consistent, either in style or quality. The I/O modules (both file and network) are particularly problematic at the moment, so even a simple networking application will be difficult. Some folks have had success though by writing their own bindings to BSD sockets, ZeroMQ, mongrel, etc. (bindings for which are in cargo).
Outside of core and standard there have been a lot of graphics- and math-oriented libraries. Multimedia, particularly games, seems to be a very promising domain for Rust. There are a number of useful libraries that are not in cargo because cargo is not yet powerful enough to deal with their build requirements.
Some of the easiest, and potentially most useful, code to write when getting started are re-implementations of popular libraries, protocols, etc. in Rust. For example, I really wanted to implement mustache templates in Rust but somebody beat me to it.
Where 2012 was the year of stabilizing the language, 2013 will be for cleaning up and redesigning the libraries, and hopefully making all the tooling more usable and featureful.
- 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.
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.
I think that if you understand the smart pointers in C++ (especially C++11) you basically understand the Rust memory model. In C++ terms, Rust has stack-allocated data, std::unique_ptr, and (non-thread-safe) std::shared_ptr built into the language. (There's a thread-safe std::shared_ptr in the library.) We also have a bunch of safety checks to make sure you use the smart pointers correctly, so you can't use non-thread-safe pointers in threaded code, you don't have iterator or reference invalidation, etc.
The tricky part is making it accessible to folks not coming from C++, which is an important goal. Any ideas would be much appreciated :)
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.
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.
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.
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....
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.
Also the repl is nice. I think having this and having Rust bootstrapped give it a leg up on Go.
Sorry, I'm afraid I'm confessing my affair with Emacs but I swore I'd leave her behind...
"[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.
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
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.orgIf there's room for more than one of them in this town, in which part of town would each reside?
From what I've seen Go is designed with emphasis on ease of programming, performance, and concurrency; Rust is designed with emphasis on safety, performance, and concurrency. (Of course these are broad generalizations, and neither language is limited to only these concerns.)
Go is a simpler language in various ways. Rust provides more control over things like memory management but at the cost of some added complexity (e.g. multiple pointer types). Rust provides some abstraction/expressivity features that Go lacks (like parametric/generic types, macros, and algebraic datatypes), again at the cost of some added complexity. Rust makes more static safety guarantees (for example, no null or "nil" pointers). While the compiler provides many of these guarantees without creating extra work for the programmer, sometimes you do have to structure or annotate your code in a particular way so the compiler can prove its safety.
Of course the two languages are also similar in many ways. For example their syntaxes are in the C family; they compile to native code; they provide CSP-style concurrency; they have some amount of local type inference; and they do not use inheritance as the main style of composition.
Rust's safety features should make it ideal for writing security- or stability-critical code. Go's simplicity probably makes it faster to learn and better for rapid development, especially for programmers used to dynamic languages like Python or JavaScript. Rust's expressive power might provide more options for abstracting common patterns out of large codebases, or to provide libraries that extend the language in different ways (e.g. using macros). Go is more mature than Rust at the moment and has more libraries and a larger community. Rust has first-class support for code that does not use garbage collection, which can make it more suitable for certain types of systems programming.
One way to think about this is that if you want to implement GitHub, use Go; if you want to implement git, use Rust.
Go may not have the most efficient stdlib, but it covers _such a wide breadth_ of features, and the code is all very readable, well documented, and idiomatic. This is my current pain point in Rust, however I'm confident it will get better with time, and the language itself is _really_ exciting to me.
The two can certainly coexist, they're not exactly sharing the same space IMO. Most importantly, Rust seems to have a much more complex type system, in addition to some very interesting concepts on memory management. Go on the other hand is pretty tightly coupled to its garbage collector, and while it is slowly improving, the current collector leaves a lot to be desired.
Go is great for writing "programs in the large", things like highly scalable servers; it also has a huge focus on concurrency with goroutines [functions multiplexed onto threads by the runtime for concurrent execution] and channels [ability to share data amongst routines in a typesafe way]. In a lot of ways its like a statically typed, compiled Python, rather than a C/C++/"systems" language. The language feels very "light" and it's a very readable language.
Rust seems to be a much more modern, more orthogonal, more comprehensible "C/C++"/systems programming alternative.
While there is definitely some overlap, I don't think the two languages are really targeting the same niche, and there is certainly room for both of them to continue evolving.
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!
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.
The Windows builds are very finicky, I'd be quite surprised if they worked under Wine.
I don't know if that's helpful for you. I'll look into packaging stuff too.