4 ms·

So, dependencies in, say, cabal or go or CL are unpredictable? The trend to put meaningless but catchy adjectives, like "safe" and "predictable", as if everyth

So, dependencies in, say, cabal or go or CL are unpredictable? The trend to put meaningless but catchy adjectives, like "safe" and "predictable", as if everything else is opposite, is misleading. Designers of classic languages were not some arrogant punks (they were brilliant, like David Moon and other guys of his generation), and the most of findamental problems were well understood in times of Standard ML or Common Lisp. So, in comparison to C or C++ it might be "predictable" and even more "safe", but in comparison with well-researched classic languages, these mere redundant adjectives.

dikaiosune 10y ago
Rust isn't targeting all of the same use areas as the other languages you mentioned (and FWIW I've heard not great things about go dependency mgt). Many, if not most, of the rust materials in the wild are pitching it as an alternative to C and C++, because that's where the language has the clearest competitive advantage.
dbaupp 10y ago
By all reports ("cabal hell"), Cabal is unpredictable, and Go's dependency management problems prompted countless external tools until the recent vendoring work: with the default `go get`, there is no guarantee that a build will be the same from day to day, as the best one can do is point at a given branch of a repository (a moving target), not tags or commits. (I have no idea on CL's dependency management situation, maybe it is even better than Rust's, in which case it would be amazing.)
- f2f 10y ago
  minor factual adjustment: "go get" doesn't update a package once it's been downloaded. you need to force it. "there is no guarantee that a build will be the same from day to day" is simply not true.
  - dbaupp 10y ago
    Oh, indeed. I must've got mixed up: it doesn't guarantee that builds will the same from machine to machine (unless you run go get at the exact same instant).
    - dschiptsov 10y ago
      So, in Golang there is no concept of package version? For them different location (to import from) for an incompatible version is good-enough.
      - f2f 10y ago
        go get is just a mechanism, not the tool. there are other tools build on top of go get that ensure proper versioning.

dikaiosune 10y ago

Rust isn't targeting all of the same use areas as the other languages you mentioned (and FWIW I've heard not great things about go dependency mgt). Many, if not most, of the rust materials in the wild are pitching it as an alternative to C and C++, because that's where the language has the clearest competitive advantage.

dbaupp 10y ago

By all reports ("cabal hell"), Cabal is unpredictable, and Go's dependency management problems prompted countless external tools until the recent vendoring work: with the default `go get`, there is no guarantee that a build will be the same from day to day, as the best one can do is point at a given branch of a repository (a moving target), not tags or commits. (I have no idea on CL's dependency management situation, maybe it is even better than Rust's, in which case it would be amazing.)

f2f 10y ago
minor factual adjustment: "go get" doesn't update a package once it's been downloaded. you need to force it. "there is no guarantee that a build will be the same from day to day" is simply not true.
- dbaupp 10y ago
  Oh, indeed. I must've got mixed up: it doesn't guarantee that builds will the same from machine to machine (unless you run go get at the exact same instant).
  - dschiptsov 10y ago
    So, in Golang there is no concept of package version? For them different location (to import from) for an incompatible version is good-enough.
    - f2f 10y ago
      go get is just a mechanism, not the tool. there are other tools build on top of go get that ensure proper versioning.