1. 43
  1. 7

    Rather than lazy_static, I think the “good” crate for this now is once_cell, but otherwise this list is a great resource I’ll be sure to keep around.

    1. 1

      Please expand. Why?

      1. 4

        See this pull request by JohnTitor https://github.com/actix/actix/pull/366 and this issue https://github.com/async-rs/async-std/issues/406. In short, macro-free, faster, “community prefers”, more flexible, and maybe will be in the standard library in the future

    2. 4

      Plus, for technical reasons, you can’t have multiple versions of ring linked into a single crate like you can with most crates – there’s some asm embedded in there, and the symbols in the asm code don’t get mangled by rustc and so can clash.

      This is also a problem for portability, because Ring is extremely anal about correctness (for good reason, it’s a crypto library), so they’re hesitant about merging support for other platforms. Combined with no Rust-only fallback, and you have a disaster for any platform that doesn’t have an assembly implementation in Ring.

      1. 2

        Maybe the Ring authors could manually implement symbol mangling on their asm symbols with a build script.

        1. 2

          From the Ring authors:

          Further, for some obscure technical reasons it’s currently not possible to link two different versions of ring into the same program; for policy reasons we don’t bother to try to work around that.

      2. 4

        Great list overall! The only thing I’d caveat is saying structopt is slow to compile and then offering an alternative that also uses procedural macros (argh) doesn’t help as much. Tangentially related, I’m also on record about it being a pet peeve of mine to recommend crates which achieve faster compile times or smaller binaries by sacrificing core end user features (sacrificing developer niceties/features such as procedural macros doesn’t bother me at all as its only the developers affected).

        (full disclosure I’m the original clap developer)

        1. 2

          Yeah, command line parsers seems to be one of those things where everyone has a sweet spot they prefer and they’re all in slightly different places. For me, giving up the convenience of procedural macros is unnecessarily painful, which rules out clap, getopts, and things like that. But I demand that it auto-generates help text in a standard format and respond to help flags by giving it, because doing anything besides that is just wasting my time, which rules out gumdrop. So as far as I know that basically leaves structopt and argh, and in my non-scientific tests, argh is a fair bit faster to build and equivalent in terms of the features I care about (so far). So, those are what’s on my list.

          So, the hard question is of course, which features are “core end user” things unable to be sacrificed, and which are not? The art of making those decisions is called “design”, and it’s hard as shit to do well. Everyone is going to have different opinions on what the sweet spot is, and that’s fine. I spent a lot of my life making problems far too complicated for myself and never making anything useful because of it, so these days I personally try very hard to aim for the 90% solutions, the tools that solve a common set of features really well rather than solve every problem in a very complicated way. That’s the software I like writing, and that’s the software I like using, and about 90% of the time it works just fine. ;-)

          Thank you for clap, though. No matter what else happens, we’re standing on the shoulders of giants by having it.

        2. 3

          Hm, I like reqwest, but if you recommend it you should mention it uses tokio internally as well.

          1. 1

            An alternative to reqwest is ureq. It is mostly (all?) written in safe rust. Unlike reqwest, ureq is not asynchronous, however.

          2. 1

            How does sccache work? It’s tempting to just plug it in (ok I’ll admit I already did), but not knowing how or when it would benefit is a little unsettling 🤔

            1. 3

              The project’s README gives a brief introduction and has additional links. It boils down to putting more things in cache.

              1. 2

                There’s a variety of possible setups. E.g., we have a server in the office and about 120 cores worth of personal desktop workstation connected, which helps us compile Firefox very fast. For us, besides caching and distributing it’s also making it less painful that most of our rust compilation is very serial in nature.

                1. 1

                  As sccache requires absolute paths to match, how did you manage to get everyone to build at the same location?

                  We have a couple of beefy build machines, where people login and build Rust, but sadly, due to this limitation we can’t us sccache :(

                  1. 1

                    Would a shared chroot do it?

                    1. 1

                      Perhaps they implemented some sort of Remote build execution and remote build cache.

                      Very similar techniques used by Bazel

                      1. 1

                        You can just configure this variable

                        export RUSTC_WRAPPER=sccache
                        1. 1

                          I’m merely a user, I’d have to defer you to our sccache experts in our #build:mozilla.org matrix channel