3 ms·

Rust is not the single language implementation that wants to avoid the "conventional" shared library systems. Python did so, Node did so and probably many other

Rust is not the single language implementation that wants to avoid the "conventional" shared library systems. Python did so, Node did so and probably many other did or plan to do so. The conventional systems are most suitable for end-user applications, while they are annoying at the best for many other use cases.

mid-kid 3y ago
> Python did so Nah, python is one of the few languages with an ecosystem that can still be properly packaged, even after pep517. All libraries are scripts that are installed (and bytecode-compiled) globally. Node is a pain in the ass due to the granularity of libraries, how frequently they update and how developers expect a specific pinned version (and vendors are flaky about backwards-compat), but nothing stopping it from having the same treatment as python. Dynamic linking isn't really an end-user feature, but rather a system integrator's. It makes it easier to make sure everything behaves the same, and can share the same resources, which is why Apple particularly wanted an ABI for Swift[1] [1]: https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/ - How Swift Achieved Dynamic Linking Where Rust Couldn't
- lifthrasiir 3y ago
  > Nah, python is one of the few languages with an ecosystem that can still be properly packaged, even after pep517. All libraries are scripts that are installed (and bytecode-compiled) globally. Virtually every Python programmer now uses some sort of virtual environments, because a single Python environment cannot have multiple versions of the same package installed, and those "proper" packages are pain in the ass for that reason. If I install a `python3-pil` package in Ubuntu jammy today, it will be 9.0.1 instead of 10.2.0 and I cannot install 10.2.0 into the global environment without risking some breakage. Yes, there would be some backport packages and then PPAs, but they will again be non-cooperative in the same way and I just want to use `pip`. What if each leaf package making use of `python3-pil` had their own virtual environment instead? That would solve most problems, but doesn't that sound like rustup? In fact, `dist-packages` was born exactly due to the stubbornness of those distro packages... > Dynamic linking isn't really an end-user feature, but rather a system integrator's. Any system integrator that strictly insists on dynamic linking is missing the whole point of building systems in the first place.
  - mid-kid 3y ago
    My point was that it does both. It didn't ditch dynamic system libraries, and it's better off for it than the rest of 'em. The fun thing about the python ecosystem, is that even if you write an application for the latest version of Pillow, its API is stable, and you're unlikely to actually use anything introduced only in the newest version, so switching between versions is largely free (though you should definitely specify a minimum version reflecting the functionalities you actually use). In the worst case, the distro will eventually catch up with the library version your software needs, and then it can be packaged. Unlike with the node ecosystem, in python land code can easily survive years without upstream maintenance! > Any system integrator that strictly insists on dynamic linking is missing the whole point of building systems in the first place. You can't really say things like this without elaborating.
weinzierl 3y ago
A couple of weeks ago I was curious how many binaries on my system did not link glibc. On my pretty standard Unbuntu it were exactly ten and they were 100% Go binaries.

mid-kid 3y ago

> Python did so Nah, python is one of the few languages with an ecosystem that can still be properly packaged, even after pep517. All libraries are scripts that are installed (and bytecode-compiled) globally. Node is a pain in the ass due to the granularity of libraries, how frequently they update and how developers expect a specific pinned version (and vendors are flaky about backwards-compat), but nothing stopping it from having the same treatment as python. Dynamic linking isn't really an end-user feature, but rather a system integrator's. It makes it easier to make sure everything behaves the same, and can share the same resources, which is why Apple particularly wanted an ABI for Swift[1] [1]: https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/ - How Swift Achieved Dynamic Linking Where Rust Couldn't

lifthrasiir 3y ago
> Nah, python is one of the few languages with an ecosystem that can still be properly packaged, even after pep517. All libraries are scripts that are installed (and bytecode-compiled) globally. Virtually every Python programmer now uses some sort of virtual environments, because a single Python environment cannot have multiple versions of the same package installed, and those "proper" packages are pain in the ass for that reason. If I install a `python3-pil` package in Ubuntu jammy today, it will be 9.0.1 instead of 10.2.0 and I cannot install 10.2.0 into the global environment without risking some breakage. Yes, there would be some backport packages and then PPAs, but they will again be non-cooperative in the same way and I just want to use `pip`. What if each leaf package making use of `python3-pil` had their own virtual environment instead? That would solve most problems, but doesn't that sound like rustup? In fact, `dist-packages` was born exactly due to the stubbornness of those distro packages... > Dynamic linking isn't really an end-user feature, but rather a system integrator's. Any system integrator that strictly insists on dynamic linking is missing the whole point of building systems in the first place.
- mid-kid 3y ago
  My point was that it does both. It didn't ditch dynamic system libraries, and it's better off for it than the rest of 'em. The fun thing about the python ecosystem, is that even if you write an application for the latest version of Pillow, its API is stable, and you're unlikely to actually use anything introduced only in the newest version, so switching between versions is largely free (though you should definitely specify a minimum version reflecting the functionalities you actually use). In the worst case, the distro will eventually catch up with the library version your software needs, and then it can be packaged. Unlike with the node ecosystem, in python land code can easily survive years without upstream maintenance! > Any system integrator that strictly insists on dynamic linking is missing the whole point of building systems in the first place. You can't really say things like this without elaborating.

weinzierl 3y ago

A couple of weeks ago I was curious how many binaries on my system did not link glibc. On my pretty standard Unbuntu it were exactly ten and they were 100% Go binaries.