8 ms·

It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility

It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility from one distro to the next with your target program. My opinion is the opposite: I think the old paradigm of distros managing a giant set of system libraries is a bad one, and is how we ended up in the land of docker. Go and Rust made the right decisions here: vendor all the dependencies, and distros can't mess with them. Makes it easier for upstream and the distro. Modern languages are not like C/C++: a single non-trivial rust program can easily depend on 100+ crates, and re-creating crates.io in your package manager is just a bad idea, even putting aside that there's probably major version incompatibilities the moment you go beyond a handful of programs. Look at the disaster that's python package management, that's not where you want to end up.

School-Cotton 2y ago
Some distros do actually break out rust dependencies into separate packages (e.g. Guix does this). It's just that a lot of rust software isn't distributed primarily by distros.
- frankjr 2y ago
  Fedora and Debian do this too. That's why it sometimes takes longer for a project to be packaged - you literally have to recursively package all of the dependencies first.
  - palata 2y ago
    Which is a feature, and not a bug: some of us want our distro maintainers to actually have a look at what they distribute.
    - prmoustache 2y ago
      Yes and it doesn't prevent anyone to build software separately, being written in rust or any other language.
  - NekkoDroid 2y ago
    > Fedora and Debian do this too. IIRC Arch does as well (or at least tries to).
    - frankjr 2y ago
      Arch does for quite a few ecosystems (Python, Ruby, Haskell, ...) but currently not for Rust.
frankjr 2y ago
> Makes it easier for upstream and the distro. Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Specifically for Rust, there's also the fact that most projects use a lock file and if your build process respects it, you now have to wait for the upstream to update it and release a new version (or update it yourself). And if your build process doesn't respect the lock file (or the project doesn't use it) and you just fetch the latest compatible dependencies at the time of build, you now have no idea if you're affected or not by the vulnerability because you don't have the exact resolved versions stored anywhere (https://github.com/rust-lang/rfcs/pull/2801 https://github.com/rust-lang/rfcs/pull/2801).
- palata 2y ago
  I totally agree. Static linking is essentially easier for people who don't want to care. But ignoring security does not mean it solves it, on the contrary. Static linking comes with a lot of issues, just like dynamic linking is not perfect. I really think it depends on the use-case, and that's why I want to have the choice.
- josephg 2y ago
  > Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Packages get rebuilt all the time. This is fine. As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.
  - palata 2y ago
    > It would make this sort of vulnerability scanning much easier to do. Scanning, sure. Fixing... surely much harder than with shared libraries.
    - josephg 2y ago
      Only because the build tooling is less mature. It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. For rust crates that are compiled and packaged straight from git, you could probably automate that today.
palata 2y ago
As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.
- akira2501 2y ago
  You're not forced to with Go. CGO exists and requires dynamic linking.
  - deleted 2y ago
    [deleted]
- newZWhoDis 2y ago
  More software should “enforce” their preferences, many decisions are objectively superior and this “anything goes” attitude has done nothing but hurt OSS/Linux adoption. Everything about the shared lib model is stupid, and has contributed to poor Linux market share to date.
  - palata 2y ago
    I couldn't disagree more. > Everything about the shared lib model is stupid I don't think we can discuss if that's you're stance. But also I don't think you understand the shared lib model if you think like that.
  - lmz 2y ago
    Dynamic linking seems to work fine for Windows or OSX. Maybe it's open source + dynamic linking that's the problem.
    - palata 2y ago
      Honestly a problem is that most developers just don't understand how it works. Docker / static linking solves a lack of understanding, mostly. That's why they are popular.
lynndotpy 2y ago
I feel the same. A huge part of the pleasure of Go and Rust are that I never run into dependency problems. I'm happy to pay the "Hello World is 4MB" tax.
- LtWorf 2y ago
  And the "I now have to evaluate thousands of libraries instead of 10 well established framework" tax? I've seen plenty of bad go libraries. For example their authors will be unaware of isatty() so they will output control codes when piped. If you factor in the time to find a competently written library (and quite possibly write one yourself) it starts to be less convenient.
LtWorf 2y ago
> the disaster that's python package management, that's not where you want to end up The one where the only sane option is using distribution packages or conda and ignoring anything that the python community comes up with?
- j1elo 2y ago
  I had my Python and pip installed from distribution packages. One day I needed to build something from source, but it needed Meson... Ok installed Meson also from my distro packages! But no, the project required a newer Meson version. Ok let's install Meson with pip! But no, it turns out pip packages themselves can require a minimum pip version!! Go figure. So I couldn't build that program without first pip-installing Meson, and I couldn't pip-install Meson without first pip-installing a more modern version of pip itself. Guess how well it worked when I upgraded pip. Spoiler: not a smooth way to discover that Python packaging is a joke.
  - icedchai 2y ago
    Were you using a virtualenv? Or were you pip installing into your distro / system python, like a true savage?
    - j1elo 2y ago
      I just knew the basics. So I was just following commands from stack overflow or similar. Silly me, thinking that it would work logically like other languages do! Later I ended up learning about all that stuff with venvs and whatnot, not to mention it's not even a unified solution but there are multiple alternatives, adding to the confusion... All this, no doubt, is a consequence of how terrible the Python packaging story is. Rust, Go, Ruby, Node, and more, I had used without remotely similar hassles.
      - icedchai 2y ago
        You are right. It's not a good experience for new developers, especially given how long Python has been around.
OKThatWillDo 2y ago
"vendor all the dependencies" What does that mean?
- PaulDavisThe1st 2y ago
  It means "add the source for your dependencies to your own codebase and build them with your build system".
  - OKThatWillDo 2y ago
    Thanks. Not an appropriate use of the noun "vendor," so I would never have guessed that.
    - mkl 2y ago
      It's the verb vendor: https://en.wiktionary.org/wiki/vendor#Verb https://en.wiktionary.org/wiki/vendor#Verb
      - deleted 2y ago
        [deleted]
      - OKThatWillDo 2y ago
        "Vendor" isn't the verb. The verb is "vend."
        mkl 2y ago
        That's a different verb, with a different meaning.
        spacechild1 2y ago
        Did you read the link?
PaulDavisThe1st 2y ago
> Modern languages are not like C/C++ I think there's a bit of a misconception here. Ardour is written in C++ and depends on 80+ other libraries. The dependency situation may be exacerbated by packaging culture that encourages the use of lots of relatively small dependencies, but it is by no means determined by language or even context.
- palata 2y ago
  I started a small project both in C++ and Rust. When in C++ I had 2 direct dependencies it resulted in 6 total dependencies (direct + transitive). In Rust I had 5 direct dependencies (because some standard stuff is not in the standard lib) and it resulted in... 300 total dependencies. > but it is by no means determined by language or even context. Not sure what you mean there. My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help. If you have to manually handle every single dependency, first it forces you to look at them (that's a good thing), and second it encourages you to minimize them.
  - PaulDavisThe1st 2y ago
    > My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help What is it that makes you think that C/C++ does not do this also? [ EDIT: this also has something to do with the typical size and scope of C/C++ libraries ]
    - palata 2y ago
      > What is it that makes you think that C/C++ does not do this also? My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.
      - PaulDavisThe1st 2y ago
        I would suggest that this caused more by ideas about the appropriate scope and scale of libraries in the 2020s than anything specifically connected to the language in use.

School-Cotton 2y ago

Some distros do actually break out rust dependencies into separate packages (e.g. Guix does this). It's just that a lot of rust software isn't distributed primarily by distros.

frankjr 2y ago
Fedora and Debian do this too. That's why it sometimes takes longer for a project to be packaged - you literally have to recursively package all of the dependencies first.
- palata 2y ago
  Which is a feature, and not a bug: some of us want our distro maintainers to actually have a look at what they distribute.
  - prmoustache 2y ago
    Yes and it doesn't prevent anyone to build software separately, being written in rust or any other language.
- NekkoDroid 2y ago
  > Fedora and Debian do this too. IIRC Arch does as well (or at least tries to).
  - frankjr 2y ago
    Arch does for quite a few ecosystems (Python, Ruby, Haskell, ...) but currently not for Rust.

frankjr 2y ago

> Makes it easier for upstream and the distro. Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Specifically for Rust, there's also the fact that most projects use a lock file and if your build process respects it, you now have to wait for the upstream to update it and release a new version (or update it yourself). And if your build process doesn't respect the lock file (or the project doesn't use it) and you just fetch the latest compatible dependencies at the time of build, you now have no idea if you're affected or not by the vulnerability because you don't have the exact resolved versions stored anywhere (https://github.com/rust-lang/rfcs/pull/2801 https://github.com/rust-lang/rfcs/pull/2801).

palata 2y ago
I totally agree. Static linking is essentially easier for people who don't want to care. But ignoring security does not mean it solves it, on the contrary. Static linking comes with a lot of issues, just like dynamic linking is not perfect. I really think it depends on the use-case, and that's why I want to have the choice.
josephg 2y ago
> Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Packages get rebuilt all the time. This is fine. As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.
- palata 2y ago
  > It would make this sort of vulnerability scanning much easier to do. Scanning, sure. Fixing... surely much harder than with shared libraries.
  - josephg 2y ago
    Only because the build tooling is less mature. It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. For rust crates that are compiled and packaged straight from git, you could probably automate that today.

palata 2y ago

As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.

akira2501 2y ago
You're not forced to with Go. CGO exists and requires dynamic linking.
- deleted 2y ago
  [deleted]
newZWhoDis 2y ago
More software should “enforce” their preferences, many decisions are objectively superior and this “anything goes” attitude has done nothing but hurt OSS/Linux adoption. Everything about the shared lib model is stupid, and has contributed to poor Linux market share to date.
- palata 2y ago
  I couldn't disagree more. > Everything about the shared lib model is stupid I don't think we can discuss if that's you're stance. But also I don't think you understand the shared lib model if you think like that.
- lmz 2y ago
  Dynamic linking seems to work fine for Windows or OSX. Maybe it's open source + dynamic linking that's the problem.
  - palata 2y ago
    Honestly a problem is that most developers just don't understand how it works. Docker / static linking solves a lack of understanding, mostly. That's why they are popular.

lynndotpy 2y ago

I feel the same. A huge part of the pleasure of Go and Rust are that I never run into dependency problems. I'm happy to pay the "Hello World is 4MB" tax.

LtWorf 2y ago
And the "I now have to evaluate thousands of libraries instead of 10 well established framework" tax? I've seen plenty of bad go libraries. For example their authors will be unaware of isatty() so they will output control codes when piped. If you factor in the time to find a competently written library (and quite possibly write one yourself) it starts to be less convenient.

LtWorf 2y ago

> the disaster that's python package management, that's not where you want to end up The one where the only sane option is using distribution packages or conda and ignoring anything that the python community comes up with?

j1elo 2y ago
I had my Python and pip installed from distribution packages. One day I needed to build something from source, but it needed Meson... Ok installed Meson also from my distro packages! But no, the project required a newer Meson version. Ok let's install Meson with pip! But no, it turns out pip packages themselves can require a minimum pip version!! Go figure. So I couldn't build that program without first pip-installing Meson, and I couldn't pip-install Meson without first pip-installing a more modern version of pip itself. Guess how well it worked when I upgraded pip. Spoiler: not a smooth way to discover that Python packaging is a joke.
- icedchai 2y ago
  Were you using a virtualenv? Or were you pip installing into your distro / system python, like a true savage?
  - j1elo 2y ago
    I just knew the basics. So I was just following commands from stack overflow or similar. Silly me, thinking that it would work logically like other languages do! Later I ended up learning about all that stuff with venvs and whatnot, not to mention it's not even a unified solution but there are multiple alternatives, adding to the confusion... All this, no doubt, is a consequence of how terrible the Python packaging story is. Rust, Go, Ruby, Node, and more, I had used without remotely similar hassles.
    - icedchai 2y ago
      You are right. It's not a good experience for new developers, especially given how long Python has been around.

OKThatWillDo 2y ago

"vendor all the dependencies" What does that mean?

PaulDavisThe1st 2y ago
It means "add the source for your dependencies to your own codebase and build them with your build system".
- OKThatWillDo 2y ago
  Thanks. Not an appropriate use of the noun "vendor," so I would never have guessed that.
  - mkl 2y ago
    It's the verb vendor: https://en.wiktionary.org/wiki/vendor#Verb https://en.wiktionary.org/wiki/vendor#Verb
    - deleted 2y ago
      [deleted]
    - OKThatWillDo 2y ago
      "Vendor" isn't the verb. The verb is "vend."
      - mkl 2y ago
        That's a different verb, with a different meaning.
      - spacechild1 2y ago
        Did you read the link?

PaulDavisThe1st 2y ago

> Modern languages are not like C/C++ I think there's a bit of a misconception here. Ardour is written in C++ and depends on 80+ other libraries. The dependency situation may be exacerbated by packaging culture that encourages the use of lots of relatively small dependencies, but it is by no means determined by language or even context.

palata 2y ago
I started a small project both in C++ and Rust. When in C++ I had 2 direct dependencies it resulted in 6 total dependencies (direct + transitive). In Rust I had 5 direct dependencies (because some standard stuff is not in the standard lib) and it resulted in... 300 total dependencies. > but it is by no means determined by language or even context. Not sure what you mean there. My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help. If you have to manually handle every single dependency, first it forces you to look at them (that's a good thing), and second it encourages you to minimize them.
- PaulDavisThe1st 2y ago
  > My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help What is it that makes you think that C/C++ does not do this also? [ EDIT: this also has something to do with the typical size and scope of C/C++ libraries ]
  - palata 2y ago
    > What is it that makes you think that C/C++ does not do this also? My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.
    - PaulDavisThe1st 2y ago
      I would suggest that this caused more by ideas about the appropriate scope and scale of libraries in the 2020s than anything specifically connected to the language in use.