2 ms·

That is not C/C++ specific, from what I saw, most "dynamic" languages picked it up rather more enthusiastically. Resolving the conflict of different library dep

by yokaze 6y ago

That is not C/C++ specific, from what I saw, most "dynamic" languages picked it up rather more enthusiastically. Resolving the conflict of different library dependencies that arises in almost all languages. And with docker I can solve it in a uniform way. If you install something in the system, it will mess it up for others. Some languages do have "native" ways to avoid that, e.g. python has virtualenv, ruby has bundler, java classpaths?... but I still can mess up the system. And it isn't like there are different ways how it is then solved. But with docker, I package and isolate the whole OS. So, as a consumer, I do not have to know how to do that for each language, and as a producer, I can do (almost) whatever I want within the container without fearing to mess up other containers or the hosting OS. Yes, this whole approach has its own downsides. But those things are a plus, I would say.

doliveira 6y ago
Honestly that all seems to mostly derive from C/C++ issues, doesn't it? Managing Python and Ruby is pretty easy until you hit a library with OS dependencies. But I'm there with you, I love Docker. But it is a solution to problems we should not be having after 30-ish years.
- yokaze 6y ago
  > Managing Python and Ruby is pretty easy until you hit a library with OS dependencies. And that's why there is practically only one solution to solve it in either language (/sarcasm off). Docker in my mind wasn't a sensible choice for compiled languages prior multi-stage builds, or better buildkit. > Honestly that all seems to mostly derive from C/C++ issues, doesn't it? It derives from having binary libraries, and a plethora of ABIs. And contrary to Go advocats and docker fans, I do believe they have their place. There is no perfect technical solution, there is always a trade-off. With compiled languages you deliver binaries. A development / delivery split is expected. The intermediate data (object files + debug data) often need a lot of storage, and are not supposed to be shipped directly. With a binary interface (ABI), you simply can ship your shared object or executable individually. With statically linked/compiled binaries, you have to ship every binary using the fixed library. Or in case of docker, it will likely affect a lower layer which will invalidate all the upper layers of each docker image using said library. So a couple of bytes delta in a couple of KB library can mean a couple of KB binary package, or a couple of multi-mb binaries or layers containing all the upper parts. Your OS is most likely working with shared objects/DLLs and their ABIs, and there is a reason for that. Your use-case might not demand that, and that is okay, but it doesn't invalidate that there is a sensible reason for doing it the way it is done.
- barumi 6y ago
  > Honestly that all seems to mostly derive from C/C++ issues, doesn't it? No, it's not. It's exclusively derived from the fact that there is no package manager. Python has a few package managers. Node.js also has package managers, and Rust has too. In C or C++ the only package manager there is is a linux distro's own generic package manager, which isn't exactly designed to handle independent projects. There is no coincidence in the fact that node.js's npm and conan are services offered by private for-profit companies which have a free tier and paid tier targeting enterprise customers. It's no coincidence because packaging and distribution is a generic software engineering need that is not tied to a specific programming language, and is value-added that, done right, is worth paying for.

by yokaze 6y ago

doliveira 6y ago

Honestly that all seems to mostly derive from C/C++ issues, doesn't it? Managing Python and Ruby is pretty easy until you hit a library with OS dependencies. But I'm there with you, I love Docker. But it is a solution to problems we should not be having after 30-ish years.

yokaze 6y ago
> Managing Python and Ruby is pretty easy until you hit a library with OS dependencies. And that's why there is practically only one solution to solve it in either language (/sarcasm off). Docker in my mind wasn't a sensible choice for compiled languages prior multi-stage builds, or better buildkit. > Honestly that all seems to mostly derive from C/C++ issues, doesn't it? It derives from having binary libraries, and a plethora of ABIs. And contrary to Go advocats and docker fans, I do believe they have their place. There is no perfect technical solution, there is always a trade-off. With compiled languages you deliver binaries. A development / delivery split is expected. The intermediate data (object files + debug data) often need a lot of storage, and are not supposed to be shipped directly. With a binary interface (ABI), you simply can ship your shared object or executable individually. With statically linked/compiled binaries, you have to ship every binary using the fixed library. Or in case of docker, it will likely affect a lower layer which will invalidate all the upper layers of each docker image using said library. So a couple of bytes delta in a couple of KB library can mean a couple of KB binary package, or a couple of multi-mb binaries or layers containing all the upper parts. Your OS is most likely working with shared objects/DLLs and their ABIs, and there is a reason for that. Your use-case might not demand that, and that is okay, but it doesn't invalidate that there is a sensible reason for doing it the way it is done.
barumi 6y ago
> Honestly that all seems to mostly derive from C/C++ issues, doesn't it? No, it's not. It's exclusively derived from the fact that there is no package manager. Python has a few package managers. Node.js also has package managers, and Rust has too. In C or C++ the only package manager there is is a linux distro's own generic package manager, which isn't exactly designed to handle independent projects. There is no coincidence in the fact that node.js's npm and conan are services offered by private for-profit companies which have a free tier and paid tier targeting enterprise customers. It's no coincidence because packaging and distribution is a generic software engineering need that is not tied to a specific programming language, and is value-added that, done right, is worth paying for.