Yes and no.

Yes, in that it's primarily a linux thing as MS has gone the route of saving off basically all dlls for all their OSes for backwards compatibility (though they still backpatch).

No, in that other than Rust and Go (and maybe a few others that emit single binaries, zig?) this is how it works with OS distributed programming language packages. Python, ruby, java, perl, C#, the OS will for all of them control distribute and update the libs independent of the apps that use them.

Also, C/C++ still make up a huge percentage of all apps in pretty much any OS.

▲

the8472 a day ago | parent | next [-]

> prerequisite for distributing libraries as anything other than source code.

> Python, ruby, java, perl, C#, the OS will for all of them control distribute and update the libs independent of the apps that use them.

Those are all JIT'ed languages, so they're distributed in source or intermediate form, not as fixed-ABI-shared-libraries.

It's really just C where shared libs really work. Even C++ has wrinkles.

	▲	cogman10 14 hours ago \| parent [-]
		> so they're distributed in source or intermediate form, not as fixed-ABI-shared-libraries. I agree. These languages all have the benefit of what an ABI provides due to their nature. Go and Rust are outliers because they don't send out intermediate versions. My point was more that the effect of being able to hot-patch applications on a system is what makes an ABI desirable, not that an ABI is necessary for that. For a language like rust, it's pretty necessary. Though it would be interesting if you could send out an intermediate compiled form of rust and do a JIT on that. WASM is pretty close to doing that, but rust doesn't support dynamic linking of modules (AFAIK). > Even C++ has wrinkles. Yeah, I somewhat hesitate to say C/C++ as being ABI stable as it's really just C and C++ uses that. Once you use any C++ features you quickly get into realms where things are ill defined. You end up needing gross things like COM in order to properly use C++ shared libs.

▲

afdbcreid a day ago | parent | prev [-]

> No, in that other than Rust and Go (and maybe a few others that emit single binaries, zig?) this is how it works with OS distributed programming language packages.

Uhmm... No? E.g.:

- Python has long strongly recommended virtual environments.

- Not to talk about JavaScript which of course manage things per project by default.

- I don't remember what was the state of things in .NET Framework, but in modern .NET NuGet packages are distributed as DLLs with your app.

I don't know other ecosystems well but I believe they aren't different.

▲

cogman10 a day ago | parent [-]

> Uhmm... No?

Ummm... yes.

How software is maintained by an OS is different from how software is maintained by 3rd party developers.

- Python has long strongly recommended virtual environments.

Yes, if you are developing a private application. But if that application gets adopted by the OS then you can expect all it's dependencies to be sent to a place like `/usr/lib/python3/dist-packages`.

> Not to talk about JavaScript which of course manage things per project by default.

I didn't bring it up because it's one I'm not familiar with. I expect OS maintainers will do similar things with it that they do with python but I'm not 100% on that.

> I don't remember what was the state of things in .NET Framework, but in modern .NET NuGet packages are distributed as DLLs with your app.

And if your .net application ends up installed as an OS package you can expect those dlls to be stored in /usr/lib.

If you are doing C/C++, as a 3rd party app, you aren't putting the .so files or the .dll files in /usr/lib or C:\Windows\System32. You are storing them in the same directory as your application. But if the OS decides to distribute your app, you can expect your .so files to get put into /usr/lib and even System32 (very very rare for MS to do that, but it does happen when, for example, we are talking about drivers).

Edit: Re: node. Here's the debian guidelines for how dependencies ultimately get shredded and distributed. https://wiki.debian.org/Javascript/Nodejs/Manual?pow_referer...

▲

afdbcreid a day ago | parent [-]

But that's the thing: almost nobody ships software via the OS today. Even on Linux software is often managed in other ways.

▲

cogman10 a day ago | parent [-]

Let me rewind this to the top of the thread.

> What is the advantage of doing so?

To which I responded

> Operating systems.

To which you said

> That's not how it works basically anywhere

I think we have reached the point in the thread where you concede that yes, there is somewhere where it's how it works and yes it does apply to languages that aren't C/C++.

So now you're shifting the goalposts and topic to

> almost nobody ships software via the OS today.

That was never something I was trying to debate. The topic was "why would you want ABI stability". And the answer is that if I wanted to rewrite coreutils in rust, then it'd be really useful to have synchronized crates with a stable ABI so I could potentially update those crates independent of the apps that depend on them.

	▲	afdbcreid a day ago \| parent [-]
		I agree that sometimes other languages are packaged this way as well, and maybe I was moving the goalposts. My original meaning was that only for C/C++ (on Linux) the recommended method of distribution is via the OS, while other languages have their own mediums (not requiring stable ABIs). So when they are packaged like that that's mostly because the OS itself or its services need them.