← Back to context

Comment by cmrdporcupine

1 day ago

I'm not OP but here's my disadvantages. Rust is the way I earn my living, and also my open source tool of choice. And my background is 25 years of SWE career:

1. build / compile times can be atrocious

2. crates.io inherits the npm philosophy, which means fairly unmoderated space of third party deps and because the Rust stdlib doesn't have a lot in it, extensive third party crate (lib) usage is strong in Rust. As a result most Rust projects have rather sprawling dependency trees, often with duplicated functionality (multiple Base64, rand, sha256, etc crates). I personally have a problem with this (auditability, accountability, security, complexity etc). Others don't.

3. Despite being nominally runtime agnostic, Rust async basically is tokio and it's almost impossible to use another runtime once you factor in third party deps. In many ways Rust is the language that tokio ate. In fact even if you opt out of async entirely, you often end up with tokio as a dependency simply because the community just seems to expect it.

4. Despite advertising itself as a "systems" language, some basic systems programming facilities I expect from my C++ background are still fundamentally not there. In particular, per-container/struct pluggable allocators still isn't a thing and the feature to add it (allocator-api) has sat unmerged in nightly for almost ten years at this point and it doesn't look good for it landing any time soon.

5. If you're working in the embedded space, there's still plenty of devices that will not have a workable Rust toolchain option yet.

I still choose it for new projects instead of its competitors C++ or Zig. But I think it's important to recognize there are compromises like any other tool.

As much as people might insist otherwise, there will in fact come a day when there are "multiple Rusts" by which I mean multiple styles and ways of doing things -- just like C++. For myself, for example... if it were my repository and my team and my hiring, and I was starting from scratch... I'd be extremely careful about third party crate adoption and have an extremely minimalistic approach there. And I don't use tokio. Though my paying jobs do.

First 2 are very legit, as a rust dev myself. I wish Rust had a larger stdlib and every argument against it leaves me pretty unconvinced/ feeling like the arguments could just as easily leave us to believe that "HashMap" should not be included (some people believe this), or even "time" should not be, etc.

The compile times are easily the worst part though. They couple poorly with (2).

I feel fine personally without (3), and (4)/(5) don't come up for me.

> For myself, for example... if it were my repository and my team and my hiring, and I was starting from scratch... I'd be extremely careful about third party crate adoption and have an extremely minimalistic approach there.

Same. I basically stick to a minimal `cargo-vet` and avoid new crates. I review new ones. I've chosen to take on a new crate when it's something like "the author literally wrote the spec for this format", but otherwise I'm reluctant.

> often with duplicated functionality (multiple Base64, rand, sha256, etc crates)

I don’t think this is true unless they differ in major versions no? Cargo will apply semantic versioning and pick the best available given the cargo.toml version constraints.

  • I don't think they mean multiple versions of the same crate (although can certainly happen too), but rather multiple different crates that cover the same functionality.