Rust 0.5 released(mail.mozilla.org)
mail.mozilla.org
Rust 0.5 released
https://mail.mozilla.org/pipermail/rust-dev/2012-December/002787.html
13 comments
"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.
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.
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. :-)
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. :-)
> 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.
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.
I'm very curious about better ways to explain not just Rust pointers, but also other features that contribute to Rust's unique feel, like inherited mutability and linear types. These things are all interrelated and there are some emerging best practices, but they are still unfolding as the language evolves and people gain experience with it.
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'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.
"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."
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 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 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.
- 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.
How is D or OCaml more Rust-like than Go? Can you explain?
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.
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'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++".
RE: the memory model, I wrote a blog post on it because I had the same trouble. Folks seem to have found it pretty helpful!
http://tomlee.co/2012/12/managed-and-owned-boxes-in-the-rust...
http://tomlee.co/2012/12/managed-and-owned-boxes-in-the-rust...
Not the person you replied to, but I can give some idea...
>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
>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
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.
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.
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.
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.
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.
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.
Probably the best place to look at the moment is this presentation: https://air.mozilla.org/intern-presentation-message-passing-...
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.
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.
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....
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....
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.
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.
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?
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.
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.
Also the repl is nice. I think having this and having Rust bootstrapped give it a leg up on Go.
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...
Sorry, I'm afraid I'm confessing my affair with Emacs but I swore I'd leave her behind...
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.
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.
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.
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.
"[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.
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.
Really glad to see the REPL!
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
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
Just fixed this. I'll see if we can push out a Rust 0.5.1.
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/
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.orgIncidentally 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
https://github.com/mozilla/rust/issues/2235
How is rust compared to Go?
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!
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!
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.
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.
Thanks, that's very helpful, and good comments about the standard library. Tons of library support is what accounts for the "stickiness" of Java in the enterprise domain.
great summary :) You're absolutely right about the stdlibs, Go has a great library, which you quickly start missing when you're using Rust which otherwise is a great language. I'm looking forward to what I think is the next stage for Rust, the stdlibs.
At least for me: the major difference between the two [implementation wise] is currently the core and standard libraries.
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 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.
Rust and Go may be superficially similar, but they are night and day semantically. They're also aimed at different niches and have wildly different goals. So though it may be tempting to compare the two, it's not an especially productive exercise. :) This town is more than big enough for the two of them.
It seems to me that any answer that stated specifically what those different niches and wildly different goals actually were would be a more productive exercise.
If there's room for more than one of them in this town, in which part of town would each reside?
If there's room for more than one of them in this town, in which part of town would each reside?
[Disclaimer: I've written only a tiny amount of Rust code, and no real Go code. I work for Mozilla but not on the Rust team.]
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.
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.
Thanks.
Disclaimer: I'm not a Rust developer.
One way to think about this is that if you want to implement GitHub, use Go; if you want to implement git, use Rust.
One way to think about this is that if you want to implement GitHub, use Go; if you want to implement git, use Rust.
[deleted]
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.)
Github still seems to show tags on the releases: https://github.com/mozilla/rust/tags
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. :)
Where can I find binaries for 32-bit Ubuntu 12.10? Or a VM image? Will the Windows binary work in Wine?
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.
I don't know if that's helpful for you. I'll look into packaging stuff too.
A volunteer usually comes along with PPAs within a week or so, though with the new buildbot it might be feasible to have official nightly binaries built for every platform.
The Windows builds are very finicky, I'd be quite surprised if they worked under Wine.
The Windows builds are very finicky, I'd be quite surprised if they worked under Wine.
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...
[3] http://thread.gmane.org/gmane.comp.lang.rust.devel/2593
[4] http://www.brinckerhoff.org/clements/