3 ms·

cargo, at least, does this for the reason Fellshard gives - the Rust team essentially commissioned a copy of Ruby's bundler, without considering whether there w

by twic 7y ago

cargo, at least, does this for the reason Fellshard gives - the Rust team essentially commissioned a copy of Ruby's bundler, without considering whether there was anything to learn from any other language's ecosystem.

geofft 7y ago
Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages and reinventing the wheel, I'm not sure what words mean anymore.
- twic 7y ago
  > Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages If you've only looked at two or three languages that not coincidentally happen to do things pretty much the same as each other, and not looked elsewhere, then you are indeed disregarding other languages. > and reinventing the wheel I didn't mention reinventing the wheel. > I'm not sure what words mean anymore. Agreed, but i'm not sure i can help you with that.
kibwen 7y ago
Namespaces would be a feature of Crates.io, not Cargo (and Crates.io was not contracted to Yehuda Katz, as Cargo was).
- twic 7y ago
  How so? Do you mean that Cargo would support crates with names like "example/foo" or "org.example/foo", but that's just not how Crates.io works? If so, that's interesting, but then my question is why we didn't make use of that.
  - steveklabnik 7y ago
    There's a few different elements of the design space. But, while Cargo can use crates.io, it's distinct from it, so on first principle, this would be a crates.io feature. That being said, Cargo would also have to understand it, because the Rust language does not understand namespaced external packages, so you'd either have to change the language, or change Cargo to do something to paper over that somehow. As for "why didn't we do this in the first place with crates.io", https://internals.rust-lang.org/t/crates-io-package-policies/1041 https://internals.rust-lang.org/t/crates-io-package-policies... lays out some of this background, though not all of it.
    - twic 7y ago
      Thanks for the reference! > When we looked at package ecosystems without namespacing, we found that people tended to go with more creative names (like nokogiri instead of “tenderlove’s libxml2”). These creative names tend to be short and memorable, in part because of the lack of any hierarchy. They make it easier to communicate concisely and unambiguously about packages. They create exciting brands. I will never stop admiring your ability to see the bright side of things.
steveklabnik 7y ago
Cargo is more like npm than Bundler in this regard, as Bundler does not let you have multiple versions of a package at the same time. That lesson was learned from npm, though implemented in a different way.

by twic 7y ago

geofft 7y ago

Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages and reinventing the wheel, I'm not sure what words mean anymore.

twic 7y ago
> Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages If you've only looked at two or three languages that not coincidentally happen to do things pretty much the same as each other, and not looked elsewhere, then you are indeed disregarding other languages. > and reinventing the wheel I didn't mention reinventing the wheel. > I'm not sure what words mean anymore. Agreed, but i'm not sure i can help you with that.

kibwen 7y ago

Namespaces would be a feature of Crates.io, not Cargo (and Crates.io was not contracted to Yehuda Katz, as Cargo was).

twic 7y ago
How so? Do you mean that Cargo would support crates with names like "example/foo" or "org.example/foo", but that's just not how Crates.io works? If so, that's interesting, but then my question is why we didn't make use of that.
- steveklabnik 7y ago
  There's a few different elements of the design space. But, while Cargo can use crates.io, it's distinct from it, so on first principle, this would be a crates.io feature. That being said, Cargo would also have to understand it, because the Rust language does not understand namespaced external packages, so you'd either have to change the language, or change Cargo to do something to paper over that somehow. As for "why didn't we do this in the first place with crates.io", https://internals.rust-lang.org/t/crates-io-package-policies/1041 https://internals.rust-lang.org/t/crates-io-package-policies... lays out some of this background, though not all of it.
  - twic 7y ago
    Thanks for the reference! > When we looked at package ecosystems without namespacing, we found that people tended to go with more creative names (like nokogiri instead of “tenderlove’s libxml2”). These creative names tend to be short and memorable, in part because of the lack of any hierarchy. They make it easier to communicate concisely and unambiguously about packages. They create exciting brands. I will never stop admiring your ability to see the bright side of things.

steveklabnik 7y ago

Cargo is more like npm than Bundler in this regard, as Bundler does not let you have multiple versions of a package at the same time. That lesson was learned from npm, though implemented in a different way.