[simoncion]

I don't see how Microsoft's and Sun's/Oracle's decision to encourage bundling all dependent software (including what would ordinarily be considered to be system libraries) with your program has to do with long-established practices in the *nix world.

I do agree that the world becomes much easier for a language/runtime maintainer if you get to ignore backwards-compatibility concerns because you've convinced your users to just pack in the entire system they built against with their program.

[ivan_gammel]

First of all, *nix is not synonymous with C++ programming, so focusing on it specifically is bringing apples to discussion about oranges. When Java is brought to the discussion about C++ I do expect that variety of platforms is taken into account.

Second, you can have shared libraries/runtimes on Windows or in Java world. There exists versioning and *nix is not unique in that. Both are rather agnostic to the way you ship your app. In server Java unless you ship a container, you usually do not ship the JRE. On a desktop - it depends, shared JREs were always possible.

Third, DLL hell does exist in *nix environments too. The versioning mechanism you mention is a technical solution to a people problem and it doesn't work perfectly. Things do break if you relax your dependency constraints too much. How much - it depends on developers and the amount of trust they put in maintainers. So you inevitably end up with multiple versions of the same library or runtime on the same machine, no matter what OS or cross-platform solution do you use. It is not much different from shipping a bundle.

[simoncion]

> First of all, *nix is not synonymous with C++ programming...

Agreed. This is obvious. You even mention it below:

> Second, you can have shared libraries/runtimes on Windows or in Java world. There exists versioning and *nix is not unique in that.

As you said, Windows has the same issue (because it's a fundamental problem of using libraries).

> Third, DLL hell does exist in *nix environments too.

IFF the publisher of the library fails to follow the decades-old convention that works really well.

> Te versioning mechanism you mention is a technical solution to a people problem and it doesn't work perfectly.

Sure. Few things do. That's what pre-release testing is for.

> Things do break if you relax your dependency constraints too much.

Yep. That's why we test.

> So you inevitably end up with multiple versions of the same library ... on the same machine...

Sure. But they're not copies of the same version. That's the entire point of the symlink-based shared object naming scheme (and the equivalent in Windows (IIRC, it used to be called SxS, but consult the second bullet point in [0])).

[0] <https://learn.microsoft.com/en-us/previous-versions/visualst...>