9 ms·

What's the status of Rust these days? I can see it's hit 1.x, but in practice is it ready for production use? How comprehensive is the standard library, depende

by estefan 11y ago

What's the status of Rust these days? I can see it's hit 1.x, but in practice is it ready for production use? How comprehensive is the standard library, dependency management, etc.? From a brief glance through the examples it looks pretty functional... is it basically a systems-ish scala?

nbaksalyar 11y ago
It's pretty stable at this point (1.x means that no backwards compatibility will be lost as in the past), and it's already used in production (e.g. Skylight [0] is written in Rust, as far as I know, and don't forget about Servo). Dependency management with Cargo is hands down one of the best out there, it just works. The standard library continues to expand, but there are also many other external libraries you can find on crates.io. > it looks pretty functional... is it basically a systems-ish scala? I think it's better to compare Rust to ML languages family (OCaml, F#, and so on), as it was clearly influenced by it. It has many features you can find in ML languages - pattern matching, ADTs (algebraic types that are enums in Rust), and many other similarities. Overall, the language feels very robust now, and I enjoy it much - it's a very decent replacement for C++, basically "C/C++ done right". [0] https://www.skylight.io/ https://www.skylight.io/
- estefan 11y ago
  Oh cool, thanks for the summary. Maybe it's time I start to dabble... It'd be good to be able to deploy binaries without VMs/requiring a ton of dependencies to be preinstalled.
  - nbaksalyar 11y ago
    Rust doesn't require a VM or any prerequisites installed on a target system. In this regard it's comparable to Go (though I'm not sure that it's viable to statically compile everything into one binary, but technically it should be possible). Anyway, it compiles down to the machine code, so at most you'll need to have a bunch of libraries along with your executable file. Hopefully you'll have a lot of fun with learning! :) Oh, and almost forgot: Rust community is one of the best that I've seen, so feel free to ask any questions on http://users.rust-lang.org http://users.rust-lang.org - I'm sure there's a lot of people who'll be glad to help you.
    - steveklabnik 11y ago
      Small detail: most Rust programs do need glibc installed. Unless you've built with MUSL specifically.
      - kibwen 11y ago
        To elaborate, by default Rust programs are entirely statically linked (dynamic linking is available with a compiler flag), though with a single dynamic dependency on libc. This means you can compile ordinary Rust code into a single executable and run that executable on any machine with a compatible version of libc (which is fairly universally available, so not a problem in practice). If you want no dynamic dependencies whatsoever, then Rust supports linking to musl, which is an implementation of libc that's designed for static linking.
  - MrBuddyCasino 11y ago
    In case your're into Linux systems programming, we had a talk recently that we filmed. Youtube & Github links here: http://www.meetup.com/rust-munich/events/224140986/?comment_table_id=456845889&comment_table_name=event_comment#comments-tab http://www.meetup.com/rust-munich/events/224140986/?comment_...
- lmm 11y ago
  Scala was also heavily ML influenced and is sometimes considered part of that family, so I think it's fair to relate the two.
  - kibwen 11y ago
    Rust and Scala may be cousins due to their ML influence, but Rust itself isn't particularly influenced by Scala. In contrast, there are quite a few design decisions in Rust that were lifted directly from OCaml. Calling Rust "C++20 + OCaml" would be a decent categorical starting point. (Caveat: the lead designer of Rust's type system, Niko Matsakis, has done a fair bit of work with Scala, so there may be subtle influences.)
    - justthistime_ 11y ago
      > Rust itself isn't particularly influenced by Scala Agree! Sadly, they didn't use all the lessons Scala could offer them when designing their own language. :-( Painful to watch as they introduce stuff where Scala developers already know that it's completely broken.
      - steveklabnik 11y ago
        Would you mind expanding on what these things are?
        lmm 11y ago
        The cascade of efforts at error handling, which I think at one point involved a macro and a magic method name, rather than getting on with higher-kinded types to allow them to do it right. Allowing "return". Mandating braces for functions and control flow constructs. Rust iteration, which is both more limited and less safe (laziness) than the scala/ruby style of passing a closure.
        kibwen 11y ago
        > The cascade of efforts at error handling You must be referring to ancient Rust with its condition system and such. Modern Rust code just uses Result types. > rather than getting on with higher-kinded types to allow > them to do it right Er, no, you don't need HKTs to "do it right", you'd just need HKTs to do it generically. Rust's error handling works fine for specific types; you can even write macros to emulate do-notation (and people have). > Allowing "return" Welcome to the realities of imperative programming. :) Unlike Scala, Rust does not aspire to functional godhood. > Mandating braces for functions and control flow constructs Scope in Rust is very, very important for expressing when references go out of scope and when resources are freed. Leaving scope implicit would be massively frustrating. > the scala/ruby style of passing a closure Rust had internal iterators for years, and the entire `for` construct was based around them. They were removed because they were found wanting. As I've mentioned in a sibling comment, the lessons that Scala may have learned in its life do not necessarily apply to Rust. They are very, very different languages.
- cballard 11y ago
  > 1.x means that no backwards compatibility will be lost as in the past Why? They could easily go to 2.x, no?
  - ColinDabritz 11y ago
    I believe this refers to the difference between pre 1.0 churn as the language was being initially designed, and post 1.0 stability. Before, existing code was frequently broken by new changes as the language evolved. Now you should generally expect to see any current code run on any future 1.x versions without issue, and probably in all future versions. If any new language constructs are added in future, they should typically be backwards compatible, only extending the old system, rather than making changes. It's possible at some point they will be compelled to break something to fix a serious flaw or issue. For Rust, I'd have to imagine this would be safety based. As language designers they will try hard not to, and it would be a major version change, such as 2.0. Python has had a lot of challenges with their changes from 2.x to 3.x, even though the language seems clearly improved. Much of the problem is converting popular existing libraries, which rely on a lot of donated time and effort. The Rust community is hoping to keep from being in a similar situation if at all possible. See "What does it mean for Rust to be 1.0" in the release announcement: http://blog.rust-lang.org/2015/05/15/Rust-1.0.html http://blog.rust-lang.org/2015/05/15/Rust-1.0.html Stability Guarantee: http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html
    - Tyr42 11y ago
      Though, I want to make clear that it is permissible for some theoretical code to stop compiling when going from 1.4 to 1.5, for example. Check out https://github.com/nikomatsakis/rfcs/blob/projection-and-lifetimes/text/0000-projections-lifetimes-and-wf.md https://github.com/nikomatsakis/rfcs/blob/projection-and-lif..., for an example of this. This is because the compiler wasn't checking some cases strictly enough, and you could "hide" constraints from the compiler, causing them to fail to be enforced. They checked against crates.io when raising this RFC, and found that there were 35 crates (packages) that would be able to keep compiling if this turned into a future-compat warning, to become an error in the release afterwards. The example trait Test { fn test(&self) -> Option<Self>; // ~~~~~~~~~~~~ // Incorrectly permitted before. } Should be trait Test: Sized { fn test(&self) -> Option<Self>; } Because `Option<T>` requires that `T` be `Sized`. Poking around on 1.3, I think that it would be an error to instantiate this trait with a [i8] or something that was not sized anyways, so you're not losing much by needing to declare the trait properly.

by estefan 11y ago

nbaksalyar 11y ago

It's pretty stable at this point (1.x means that no backwards compatibility will be lost as in the past), and it's already used in production (e.g. Skylight [0] is written in Rust, as far as I know, and don't forget about Servo). Dependency management with Cargo is hands down one of the best out there, it just works. The standard library continues to expand, but there are also many other external libraries you can find on crates.io. > it looks pretty functional... is it basically a systems-ish scala? I think it's better to compare Rust to ML languages family (OCaml, F#, and so on), as it was clearly influenced by it. It has many features you can find in ML languages - pattern matching, ADTs (algebraic types that are enums in Rust), and many other similarities. Overall, the language feels very robust now, and I enjoy it much - it's a very decent replacement for C++, basically "C/C++ done right". [0] https://www.skylight.io/ https://www.skylight.io/

estefan 11y ago
Oh cool, thanks for the summary. Maybe it's time I start to dabble... It'd be good to be able to deploy binaries without VMs/requiring a ton of dependencies to be preinstalled.
- nbaksalyar 11y ago
  Rust doesn't require a VM or any prerequisites installed on a target system. In this regard it's comparable to Go (though I'm not sure that it's viable to statically compile everything into one binary, but technically it should be possible). Anyway, it compiles down to the machine code, so at most you'll need to have a bunch of libraries along with your executable file. Hopefully you'll have a lot of fun with learning! :) Oh, and almost forgot: Rust community is one of the best that I've seen, so feel free to ask any questions on http://users.rust-lang.org http://users.rust-lang.org - I'm sure there's a lot of people who'll be glad to help you.
  - steveklabnik 11y ago
    Small detail: most Rust programs do need glibc installed. Unless you've built with MUSL specifically.
    - kibwen 11y ago
      To elaborate, by default Rust programs are entirely statically linked (dynamic linking is available with a compiler flag), though with a single dynamic dependency on libc. This means you can compile ordinary Rust code into a single executable and run that executable on any machine with a compatible version of libc (which is fairly universally available, so not a problem in practice). If you want no dynamic dependencies whatsoever, then Rust supports linking to musl, which is an implementation of libc that's designed for static linking.
- MrBuddyCasino 11y ago
  In case your're into Linux systems programming, we had a talk recently that we filmed. Youtube & Github links here: http://www.meetup.com/rust-munich/events/224140986/?comment_table_id=456845889&comment_table_name=event_comment#comments-tab http://www.meetup.com/rust-munich/events/224140986/?comment_...
lmm 11y ago
Scala was also heavily ML influenced and is sometimes considered part of that family, so I think it's fair to relate the two.
- kibwen 11y ago
  Rust and Scala may be cousins due to their ML influence, but Rust itself isn't particularly influenced by Scala. In contrast, there are quite a few design decisions in Rust that were lifted directly from OCaml. Calling Rust "C++20 + OCaml" would be a decent categorical starting point. (Caveat: the lead designer of Rust's type system, Niko Matsakis, has done a fair bit of work with Scala, so there may be subtle influences.)
  - justthistime_ 11y ago
    > Rust itself isn't particularly influenced by Scala Agree! Sadly, they didn't use all the lessons Scala could offer them when designing their own language. :-( Painful to watch as they introduce stuff where Scala developers already know that it's completely broken.
    - steveklabnik 11y ago
      Would you mind expanding on what these things are?
      - lmm 11y ago
        The cascade of efforts at error handling, which I think at one point involved a macro and a magic method name, rather than getting on with higher-kinded types to allow them to do it right. Allowing "return". Mandating braces for functions and control flow constructs. Rust iteration, which is both more limited and less safe (laziness) than the scala/ruby style of passing a closure.
        kibwen 11y ago
        > The cascade of efforts at error handling You must be referring to ancient Rust with its condition system and such. Modern Rust code just uses Result types. > rather than getting on with higher-kinded types to allow > them to do it right Er, no, you don't need HKTs to "do it right", you'd just need HKTs to do it generically. Rust's error handling works fine for specific types; you can even write macros to emulate do-notation (and people have). > Allowing "return" Welcome to the realities of imperative programming. :) Unlike Scala, Rust does not aspire to functional godhood. > Mandating braces for functions and control flow constructs Scope in Rust is very, very important for expressing when references go out of scope and when resources are freed. Leaving scope implicit would be massively frustrating. > the scala/ruby style of passing a closure Rust had internal iterators for years, and the entire `for` construct was based around them. They were removed because they were found wanting. As I've mentioned in a sibling comment, the lessons that Scala may have learned in its life do not necessarily apply to Rust. They are very, very different languages.
cballard 11y ago
> 1.x means that no backwards compatibility will be lost as in the past Why? They could easily go to 2.x, no?
- ColinDabritz 11y ago
  I believe this refers to the difference between pre 1.0 churn as the language was being initially designed, and post 1.0 stability. Before, existing code was frequently broken by new changes as the language evolved. Now you should generally expect to see any current code run on any future 1.x versions without issue, and probably in all future versions. If any new language constructs are added in future, they should typically be backwards compatible, only extending the old system, rather than making changes. It's possible at some point they will be compelled to break something to fix a serious flaw or issue. For Rust, I'd have to imagine this would be safety based. As language designers they will try hard not to, and it would be a major version change, such as 2.0. Python has had a lot of challenges with their changes from 2.x to 3.x, even though the language seems clearly improved. Much of the problem is converting popular existing libraries, which rely on a lot of donated time and effort. The Rust community is hoping to keep from being in a similar situation if at all possible. See "What does it mean for Rust to be 1.0" in the release announcement: http://blog.rust-lang.org/2015/05/15/Rust-1.0.html http://blog.rust-lang.org/2015/05/15/Rust-1.0.html Stability Guarantee: http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html
  - Tyr42 11y ago
    Though, I want to make clear that it is permissible for some theoretical code to stop compiling when going from 1.4 to 1.5, for example. Check out https://github.com/nikomatsakis/rfcs/blob/projection-and-lifetimes/text/0000-projections-lifetimes-and-wf.md https://github.com/nikomatsakis/rfcs/blob/projection-and-lif..., for an example of this. This is because the compiler wasn't checking some cases strictly enough, and you could "hide" constraints from the compiler, causing them to fail to be enforced. They checked against crates.io when raising this RFC, and found that there were 35 crates (packages) that would be able to keep compiling if this turned into a future-compat warning, to become an error in the release afterwards. The example trait Test { fn test(&self) -> Option<Self>; // ~~~~~~~~~~~~ // Incorrectly permitted before. } Should be trait Test: Sized { fn test(&self) -> Option<Self>; } Because `Option<T>` requires that `T` be `Sized`. Poking around on 1.3, I think that it would be an error to instantiate this trait with a [i8] or something that was not sized anyways, so you're not losing much by needing to declare the trait properly.