1. 45
  1.  

  2. 14

    Hey, I’m touched that Possible Rust is included in this list! It’s been a lot of fun writing it so far, and I definitely have plans to continue growing it in this year and beyond.

    1. 7

      Please keep updating it! I really love that website :)

    2. 10

      What I want to know is if I start learning Rust now, how confident can I be that my knowledge is applicable in a few years, or if the best practices will be deprecated until then. The impression I always get from listening into Rust conversations is that there is a lot of change going on, old compilers (such as those usually distributed by system package managers) are easily outdated making me feel like it might be better to wait a bit for the language to stabilize. Is that mistaken or is it true that Rust isn’t a stable language to learn, like C or Lisp?

      1. 21

        Mistaken. I started learning Rust in 2013 (pre-1.0), and most things I learned about Rust then is still applicable now and I am confident it will continue to be applicable in 5 years. Rust is a stable language that has been stable since 2015. I actually don’t recall any best practices that has been deprecated.

        Hope this helped.

        1. 3

          I am probably not the most qualified person to answer this (i.e. i am not a rust expert), but, as i understand, rust has actually been a quite stable language since v 1.0, so i wouldn’t worry too much about stability.

          I’d add to that, that in general in the software industry technologies and best practices change all the time (within reason), so I’d keep an open mind and give it a shot. If you end up liking it, I am sure you’d find ways to stay up to date with any evolution of the ecosystem without even noticing.

          My 2 cents…

          1. 2

            old compilers are easily outdated

            Rust has a rare approach to version management: they guarantee backwards compatibility of ‘stable’ features across upgrades, but expect you to always use a very recent version of the compiler (and provide automatic updates).

            I’m not sold on it, personally:

            • I don’t trust anyone not to introduce regressions via automatic updates. In fairness to the rust team, I’m not aware of any regressions that made it out, and they have very good automatic testing to ensure they don’t introduce any.
            • If you use a library that requires ‘nightly’ (non-stable) features, your code will most likely be broken when those features change in an update.

            If you want stability, install a ‘stable’ release; your code will continue to compile without modification for the foreseeable future, thanks to the ‘editions’ approach to backwards compatibility.

            It’s true that there are many changes to the language in each (frequent) release, but the vast majority are “something that you would expect to work was broken, has now been fixed”.

            1. 8

              I used Rust in production for algorithmic trading for a year. (I have since moved on to other jobs and I no longer use Rust in production.) I was responsible for technical decisions, and I insta-updated Rust compiler as soon as releases were out. I had no problems. It does work as advertised.

              1. 1

                I insta-updated Rust compiler as soon as releases were out. I had no problems. It does work as advertised.

                But this is what annoys me. I run apt upgrade maybe once every week or two, and would like everything to be done, having to pay attention to compiler updates because a library depends on it not something I want to see.

                1. 6

                  The apt-provided compiler is the compiler used by Debian/Ubuntu for building their system and their packages. It is not meant for general development - especially if it involves e.g. cross-compilation - unless you target Debian/Ubuntu. If you would like that policy to be different, I recommend giving feedback to the packager team, they are a great bunch :). FWIW: This notion is far more pronounced when talking about Rust then about C, but it is also present there - the C compiler in “build-essentials” is the one used by the system. C just happens to be way more settled.

                  I also want to add that libraries switching to higher minimum versions is becoming rarer and rarer, I often find myself lagging the stable compiler by at least 2 versions (and that as a Rust project member!).

                  1. 1

                    If you would like that policy to be different, I recommend giving feedback to the packager team, they are a great bunch :).

                    Can you tell me where I can do this?

              2. 7

                In maintaining ggez for about four years, I’ve had compiler updates break the build twice that I can recall. Both times the breakage was in a dependency. Once it was a small but for realsies regression, once it was tightening the rules around unsafe code a little. In both cases it was a bit of a nuisance but that’s all.

                IMO this is acceptable. It’s kinda hateful, but dependencies break sometimes; this is not a Rust-specific thing. If you don’t want to put up with it, don’t use them. A lot of the more stable crates outright say what the oldest version of rustc they support is, which is nice, but for something like ggez that has a huge transitive dependency tree you’re basically stuck using the most recent one.

                1. 3

                  Using a library on nightly has been, in my experience, problematic with updating compiler versions. That’s exactly how it’s supposed to be, though.

                  Libraries on stable, however, have never once broken for me on a compiler upgrade, and it’s something I’ve done fairly often over the last two years using Rust in production.

                  1. 3

                    The (valid!) problem most people highlight is that if e.g. the stdlib adds a function in 1.51 and a dependency starts using it, you have to update your compiler. Given that Rust just added const generics and a lot of common libraries like heapless and bitvec have been waiting for it for a while, 1.51 is also a release that will most likely be a release where that is more pronounced.

                  2. 2

                    Rust has a rare approach to version management: they guarantee backwards compatibility of ‘stable’ features across upgrades, but expect you to always use a very recent version of the compiler (and provide automatic updates).

                    I’m not sure why you consider this rare. “Automated upgrades, declaring the version of the API that you want in a manifest file, and a fanatical approach to backwards compatibility” sounds like Windows 10, which might be one of the single most widely-used pieces of software in existence.

                    1. 1

                      Rust has a rare approach to version management: they guarantee backwards compatibility of ‘stable’ features across upgrades, but expect you to always use a very recent version of the compiler (and provide automatic updates).

                      I want to push back here slightly: it’s true, but this is the status quo. Currently, we support the current compiler only and rarely backport fixes. We have a lot of change control going on and ensuring the backwards compatibility here is already a task we spend much time on. But that does not mean that this policy is set in stone, but supporting older compilers requires resources and we (still) are a young language. In general, we prefer to either do things proper or not at all and currently, the needle is still on “not at all”. For that reason, I wouldn’t call it “an approach”, only “the current approach”.

                      We make the approach easy by releasing often and predictably (we never missed a release date), which ensures small deltas. Plus above mentioned change control mechanism (CI, Code Review and the big hammer: crater).

                      https://github.com/rust-lang/crater

                  3. 7

                    Thanks for the kind shout-out :] There are two resources I tend to point newcomers to more than any others. They are especially useful for people who get bored of books (or don’t have time to read one) and want to quickly zero-in on how things actually work so that they can be put to use immediately:

                    1. Rust: A unique perspective covers some of the deep symmetries and philosophies that cut to the core of a few of the most prominent mechanical aspects of the language, which are the same things that tend to hang people up regardless of their previous language experience. This is a great medium-sized post to read every few months, as it can be a clarifying reminder of how much symmetry there really is despite Rust sometimes feeling like a million random ideas crammed together.
                    2. Cheats.rs is so much more than a cheatsheet. Every time I skim this I am reminded of something about the language that I’ve forgotten or was unaware of. It’s really helpful for not only offering a shotgun-blast of nearly every feature of rust, but also a lot of x-ray perspectives on how the features you use are implemented under the hood.

                    These two resources quickly get to the nuts-and-bolts of the why and the what of the language.

                    1. 2

                      The shout-out was very well deserved! Please keep up with the good stuff :)

                      Thanks a lot for these additional resources, I’m looking forward to checking them out!