1. 62

  2. 24

    Usability of Rust has improved greatly. The rust team has been great responding to user feedback and fixing places where users were getting stuck.

    Especially the borrow checker was initially very picky. You just had to know where to strategically place extra curly braces or as_ref() calls. Now it rarely gets in the way, and auto-suggests fixes when needed.

    It’s also an interesting case study where very simple rules of the old borrow checker created a lot of complexity for programmers. OTOH the new borrow checker is internally very advanced (seems like rustc has its own prolog), but thanks to the complexity sitting in the compiler, it’s much simpler for users.

    1. 7

      Dang, has it been five years? It was only four years just last year!

      It’s very interesting to be reminded just how much the language has evolved… things that now seem fundamental like libcore, rustup and incremental compilation were heavily experimental and wished-for features not so long ago! It’s also nice to see how much the language itself has not changed since the 2018 edition – async/await is the biggie, of course, but it’s nice to see that the big push to 2018 seems to have gotten in a lot of the language changes people hotly wanted.

      It’s also cool to hear a bit from each of the language/tooling teams. Rust’s build system and other tooling really is light-years ahead of almost every other language in terms of usability, in my experience, and most of it is because people looked at the pre-2015 state of the art, decided what they wanted the workflow to look like from the beginning, and tried to build things that learned from the mistakes of their predecessors. It’s certainly not perfect, and a lot of the good design is choosing what things they are deliberately not going to support, but dealing with cargo vs. cmake is night and day.

      1. 2

        I’ve only just started playing with rust but I wish all programming languages/frameworks compiled a compact list like this. It’s a nice reference when I’m trying to figure out why some old documentation references some new feature.

        1. 1

          1.14 — Rustup 1.0

          I’ve never really liked it. The fact that the official website still tells me to use curl ... | sh to install yet another tool still makes rust seem unprofessional, at least in this regard. And of course I could install it from my package manager’s repositories, building relatively simple tools like a linter or a completion engine fail because they depend on some nightly features.

          I guess it’s my problem that I expect these things, but either way those have been the things that have been keeping me away from the language.

          1. 14

            We’ve had many dicussions on the topic of whether you should let people pipe your malware(tm) directly into their shell or not. Every time with varying arguments of

            • but I want signatures
            • nobody checks signatures
            • you have to trust those signatures at one point also
            • which is like the first rustup installation, you don’t pipe into shell afterwards anyway
            • but I want my malware(tm) downloaded to HDD before piping it into shellexecuting the installer blindly
            • but I always inspect the malware(tm) I download, before executing it anyway
            • you can always build rustc by yourself, enough about that in the readme
            • but you can’t verify the correctness of every line in the compiler anway
            • you can’t verify the integrity of the binary, as you can’t verify the code and thus not create a clean build to compare with anyway
            • you can just use your package manager

            Pick your poison..

            1. 3

              My issue isn’t even security, I just want to centrally manage all software on my system.

              1. 7

                Then… install rustup or rust through your package manager not from the official website? Just like every other piece of software you want managed centrally?

                1. 0

                  I use Debain, and as far as I see, no version packages rustup. And the versions of Rust that are packaged appear to lack something that nightly versions have. And that’s what annoys me, that if you want tooling you need to use nightly (whatever the technical or political reason for this may be). Imagine having to use the dev-build for Java to get autocompletion or track the master branch for Go if you want static analysis.

                  1. 1

                    I dunno, I’ve never really used nightly but the tooling works just fine in my experience. What features do you want that are nightly-only? rust-analyzer builds just fine on stable.

                    As an outside observer, I’m given to understand that Rust is a tricky thing to package for the Debian crew, since they want to be able to package Rust libraries but the Rust ABI is only stable within a particular compiler version. So, not packaging Rustup is kinda the best of bad options there: either you use Debian’s rustc (1.34 on current Stable which seems to be a sorta informal “if you want to use a stable version this is a good one”, 1.42 on Testing which is pretty close to the current most-recent) and can use the libs that Debian distributes, or you use rustup and it’s up to you to provide the libs you want that are built with the compiler you want.

                    1. 1

                      For example, just yesterday

                      • I used miri (which requires nightly) to help decide if I had any faith in some unsafe code being correct.
                      • I used -Z macro-backtrace to help debug some macros I was using (only available on nightly as a unstable compiler flag). Using the flag was suggested by the compiler.
                      1. 1

                        rust-analyzer needs the latest stable though, I think this might be where the confusion about nightly features comes from (ra uses “nightly” features from the perspective of 1.34). If folks want to build rust-analyzer from source with old compilers, they have to stick to old versions of rust-analyzer as well.

                        1. 1

                          Is there a way to tell cargo what version to use? If yes, that should be better documented.

                          1. 1

                            Yes, I think cargo install can accept tags/commits when building from a git repo. When building from source, it’s possible to check out the required commit.

                        2. 1

                          I tried to install racer a while ago, and it failed because of missing nightly features. Because of your comment, I tried again, but it still seems to fail, citing a lot of “unstable” or “experimental features. This all just aggregates to a very bad introductory experience.

                          1. 4

                            The README for racer tells you that it requires nightly Rust. Its dependencies tell the story: it depends on a bunch of rustc specific crates.

                            racer bootstrapped the IDE experience for Rust using what I’m guessing was the quickest possible method: using the compiler directly. The future of IDE for Rust is being concentrated in rust-analyzer, which I guess does compile with Rust stable. But probably not the version of Rust in Debian, because Debian packages an older version of Rust, as I’m sure you’re aware. The simplest way to build an older version of rust-analyzer is to clone its repository and checkout an older version. But at that point, you’re now faced with the research task of figuring out which version is compatible with your Rust compiler, if such a version even exists.

                            In general, if you’re writing Rust code, the Rust ecosystem generally assumes that you’re not only using rustup, but are using the latest version of the compiler. Archlinux, for example, has no problems packaging rustup. I don’t know why, off hand, Debian doesn’t. There isn’t a lot of flexibility built in for folks using a compiler older than, say, two releases. That work flow is not well supported, but is possible. It is certainly not a good way to introduce yourself to the language, and I don’t really see that changing any time soon. There has been talk about LTS releases, but it’s not particularly popular. There’s also been some effort toward making the minimum supported Rust version (“MSRV”) an officially supported concept by Cargo, which I think would, at minimum, give you better error messages.

                            It’s a sad hill to die on in my opinion, but I guess you have your requirements. Personally, if I were stuck using Debian, I’d be thankful for the easy curl ... | sh command I could run to liberate myself and use the latest version of the Rust compiler. Not even necessarily because I have to, if only to get the latest compilation time improvements, which are happening pretty frequently.

                            1. 1

                              There’s also been some effort toward making the minimum supported Rust version (“MSRV”) an officially supported concept by Cargo, which I think would, at minimum, give you better error messages.

                              That sounds great, thanks for the insight!

                              It’s a sad hill to die on in my opinion …

                              I don’t have to use Rust, I just want to explore and play with it. That’s why I’d want things like completion and static analysis (preferably without LSP, but that’s getting harder and harder). If I had to use it, then all these things wouldn’t be requirements or I would use rustup.

                              1. 2

                                Gotya. Yeah, LSP appears to be the future. In a couple years time, I’d be surprised if there were any actively maintained non-LSP solution for Rust.

                                I’ve made my peace with LSP. I used to use ctags for goto-definition, but it was just plain wrong a noticeable number of times. The only way to fix that AFAIK, for Rust at least, is to use one of the smarter tools which are all LSP based.

                                LSP stuff outside of VS Code still appears to be early days. The user experience has overall just not been great from my perspective, and that’s coming from someone using vim (well, now neovim) which actually enjoys a wide variety of LSP client implementations to choose from. I shutter to think what it’s like for folks using less supported editors. Hopefully it will get better though.

                        3. 1

                          I’m not 100% clear on what the debian packing story is in general these days, but google suggests this?

                      2. 1

                        If you need nightly and your distribution doesn’t package it, it sounds like that the instructions telling you to use your distribution’s package manager wouldn’t help anyway. Certainly you could package rust-nightly yourself. Or, install rustup and manage toolchains that way.

                        1. 1

                          If your distro doesn’t package rustup (which is reasonably common to package) or nightly (which would be really weird to directly package), then ya, you’re out of luck and need to install it by hand. So… use a distro that packages a wide variety of things if you care about a wide availability of packages.

                          Here is a arch package in the official repos, here is a void linux package in the official repos. I’m not 100% clear on how it fits in the packaging story, but ubuntu seems to be moving towards “snaps” and here is a rustup snap for ubuntu and a rustup snap for debian.

                    2. 11

                      At least it’s not asking you to pipe it as root, and I really appreciate the one solution for most *nix-y systems, at least after dealing with Python’s installation and package ecosystems. I’m pretty confident I won’t break my rust install and be stuck wondering which environmental variable should point where.