Hacker News Reader

Comment by kjuulh | Hacker News Reader

It is super easy to do. Cargo init --lib crates/something, done.. xD it is pretty much identical to go.

I've got other gripes with cargo.

- A go mod download equivalent would be nice so that we can actually reliably cache dependencies in ci. - More sane linking tooling when statically compiling, eg. Openssl. - Build.rs magic at compile time. - No good way to publish a workspace of crates without actually having to publish everything. - General workspace versioning unfriendliness. It is tricky to bump versions correctly in a workspace.

Probably some more. Most of these already have upstream issues but most have been stale for a while

View on HN

To be fair, it seems Cargo team has been understaffed for a long time. So developement has been kinda stalling. They are trying to fix it.

Yeah, it maybe wasn't the greatest to throw blame at them, I really enjoy using rust and cargo. So I just want it to be the best it can be. Maybe I should look into what I can do to help them solve some of these issues =D

> A go mod download equivalent would be nice so that we can actually reliably cache dependencies in ci.

What does go mod download do? cargo fetch/cargo vendor don't do the trick?

cargo fetch gets most of the way there. But you would need to build them as well to actually get good performance.

This is the upstream issue in question: https://github.com/rust-lang/cargo/issues/2644

Cargo fetch and/or cargo-chef kind of does these things, but not in a super intuitive and easy to use way.

  A go mod download equivalent would be nice so that we can actually reliably
  cache dependencies in ci.

What's wrong with caching the target and ~/.cargo directories?

you have to include your source to be able to build your dependencies, this is not great for Docker builds, or just hashing in general. Cargo-chef tries to solve this, by only Including Cargo.toml and .lock, and creating main.rs and lib.rs files when it runs, it is a bit clunky though.

Basically you don't want a source change to invalidate your dependency fetching, which can occur if you use cargo fetch and just caching the target, especially with docker, as it doesn't have granular enough caching mechanisms.

Caching ~/.cargo is great tho =D

> it is pretty much identical to go.

Its not.

with Go you have ONE go.mod file, at the module root. you may have 100 sub packages or sub sub sub packages, but still only ONE go.mod file. then any time you need to add a new import at ANY level, you just go "go mod tidy", and DONE. please dont try to compares apple and orange and say they are both apples.

Go has workspaces now. IMO they kind of suck to use, but they do exist. https://go.dev/doc/tutorial/workspaces

This is far from the only way to work with Go, and is one of the worst, as it leads to uncontrolled dependency sprawl.

There really isn't a huge difference, both have workspaces, and both allows you to add arbitrary go.mod or Cargo files where you want. The biggest difference is that go defines a module as a folder, where rust does it pr file. That said I don't know how that plays into how it is compiled.

Any of these subpackages, if they don't have a go.mod file, would require defining their dependencies top level as well, and when you go get the package you would need to pull everything, even if you only need a subpackage. Which usually isn't a problem, because golang is super fast to compile.

I get that they aren't identical, but tbh they are pretty close

Additionally Go requires search and replace all over the place, if a module ever changes it SCM location, and having internal build caches for the company, not even bother.

Reply on news.ycombinator.com