To me, the one thing I'd like to change about Cargo is that required initial clone of a 100MB+ git repository before you can even install something.

IIRC this was because a libgit2 issue preventing them from doing a shallow clone though, so there's no way around it for now.

Disclaimer: I use both Go and Rust on a daily basis and think both are nice in their own way.

That’s more of an implementation detail though. The design does not demand that. I assume that no concern initially when the ecosystem was tiny.

I agree, but it's not a detail in practice. My feeling is that Rust is very attentive to theoretical details, and Go to practical details. Of course it's an over-simplification, and both approaches are pertinent and complementary ;-)

That's the exact opposite of what the grandparent is talking about, though. Cargo was the one saying "this works for now, we'll fix libgit2 later", which is firmly in the practical camp. vgo is the one saying "we can't emulate other package managers because SAT solvers are slow", which ignores that in practice they're not, valuing strictly theoretical considerations instead (and, in practice, Cargo doesn't even use a SAT solver anyway, so they didn't do their homework).

I meant that Go usually focuses more on solving practical issues than theoretical issues. But I have to agree that it is the exact opposite in the example I replied to ;-)

Yes, Cargo doesn't use a SAT solver, but Cargo' source code acknowledges that "solving a constraint graph is an NP-hard problem" and uses "nice heuristic to make sure we get roughly the best answer most of the time". [1]

It's not just a theoretical consideration. It can create real problems. See for example "Abort crate resolution if too many candidates have been tried" at https://github.com/rust-lang/cargo/issues/4066. I'm not saying it's big issue, but it's something to consider in the design space and this is why the Go team is considering other options.

[1] https://github.com/rust-lang/cargo/blob/master/src/cargo/cor...

Again, in practice, this has not created real problems, which Russ Cox seems to fail to appreciate. I've been using Cargo for years, working with other programmers for years (including programmers using large Rust codebases in production at large companies), and teaching programmers new to Rust (both online and off) for even longer. The number of times I have had crate resolution abort, or found the heuristic-chosen dependencies undesirable, or seen any other person ever complain about either of the former: zero. My sample size is not small.

I respect Russ Cox's decision to favor different considerations for Go's versioning story. The approach of constraining to minimal versions is not bad, merely different (especially since the -u flag exists). But the framing of this as solving some problem with existing package managers is simply mistaken, as Russ would know if he had used these tools in practice, rather than instinctively reeling at the theoretical implications.

> in practice, Cargo doesn't even use a SAT solver anyway, so they didn't do their homework

It's not fair to accuse people of not doing their homework when they actually are...

Russ Cox published "Version SAT" in December 2016. [1] The article specifically mentions "Rust's Cargo" which "uses a basic backtracking solver".

[1] https://research.swtch.com/version-sat

Rust might have theoretical problems but it doesn’t matter in practice. That’s all that matters to the Rust community.

See https://news.ycombinator.com/item?id=16423049 for a discussion between rsc and Rust developers.

Quoting the article:

> […] the import uniqueness rule: different packages must have different import paths. […] Cargo allows partial code upgrades by giving up import uniqueness.

> The constraints of Cargo and Dep make version selection equivalent to solving Boolean satisfiability, meaning it can be very expensive to determine whether a valid version configuration even exists.

> eliminates the need for separate lock and manifest files.

Note that Cargo is seen as a "gold standard" approach here, upon which rsc is trying to improve.