[tgtweak]

Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... python in another realm here as well. That shiny c++ project that needs a bleeding edge boost version that is about 6 months away from being included in your package manager. Remember patching openSSL when heartbleed came around (libssHELL).

Visual studio is a dog but at least it's one dog - the real hell on windows is .net framework. The sheer incongruency of what version of windows has which version of .net framework installed and which version of .net your app will run in when launched... the actual solution at scale for universal windows compatibility on your .net app is to build a c++ shim that checks for .net beforehand and executes it with the correct version in the event of multiple version conflict - you can literally have 5 fully unique runtimes sharing the same .net target.

[eqvinox]

> glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow...

If you somehow experience an actual dependency issue that involves glibc itself, I'd like to hear about it. Because I don't think you ever will. The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it: https://lwn.net/Articles/605607/

Now, if you're saying it's a dependency issue resulting from people specifying wrong glibc version constraints in their build… yeah, sure. I'm gonna say that happens because people are getting used to pinning dependency versions, which is so much the wrong thing to do with glibc it's not even funny anymore. Just remove the glibc pins if there are any.

As far as the toolchain as a whole is concerned… GCC broke compatibility a few times, mostily in C++ due to having to rework things to support newer C++ standards, but I vaguely remember there was a C ABI break somewhere on some architecture too.

[HexDecOctBin]

> The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it

What? There was a huge breakage literally last year: https://sourceware.org/bugzilla/show_bug.cgi?id=32653

Glibc has been a source of breakage for proprietary software ever since I started using Linux. How many codebases had to add this line around 2014 (the year I brought my first laptop)?

    __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5");

[nanoxide]

When was the last time you actually used. NET? Because that's absolutely not how it is. The. NET runtime is shipped by default with Windows and updated via WU. Let alone that you're talking about .NET Framework which has been outdated for years.

[p_ing]

.NET runtime is not shipped with Windows, but once installed can be updated by WU.

Only the latest .NET Framework 4.8 is shipped with Windows at this point.

[torginus]

.NET Framework is a Windows system component, but it's been deprecated and Microsoft is moving away from it. The modern .NET ships as either a downloadable runtime/SDK, or can be bundled with your application, meaning your app has no dependencies.

[tgtweak]

The issue is in supporting older windows versions - which sadly is still a reality for most large-scale app developers.

[croes]

.NET versions are faster outdated then .Net Framework 4.8

[TZubiri]

>Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath?

That seems more a property of npm dependency management than linux dependency management.

To play devil's advocate, the reason npm dependency management is so much worse than kernel/os management, is because their scope is much bigger, 100x more package, each package smaller, super deep dependency chains. OS package managers like apt/yum prioritize stability more and have a different process.

[pjmlp]

Which has been fixed on .NET 5 and later.

.NET Framework should only be used for legacy applications.

Unfortunately there are still many around that depend on .NET Framework.

[foepys]

Since .NET 10 still doesn't support Type Libraries quite a few new Windows projects must be written in .NET Framework.

Microsoft sadly doesn't prioritize this so this might still be the case for a couple of years.

One thing I credit MS for is that they make it very easy to use modern C# features in .NET Framework. You can easily write new Framework assemblies with a lot of C# 14 features. You can also add a few interfaces and get most of it working (although not optimized by the CLR, e.g. Span). For an example see this project: https://www.nuget.org/packages/PolySharp/

It's also easy to target multiple framework with the same code, so you can write libraries that work in .NET programs and .NET Framework programs.

[croes]

.Net Framework 4.8 has a longer life cycle as the current .NET version

[sippeangelo]

.NET Framework 5 or .NET Core 5?

[the__alchemist]

This is one of the things that tilts me about C and C++ that has nothing to do with mem safety: The compile/build UX is high friction. It's a mess for embedded (No GPOS) too in comparison to rust + probe-rs.

[Pay08]

That hasn't been my experience at all. Cross-compiling anything on Rust was an unimaginable pain (3 years or so ago). While GCCs approach of having different binaries with different targets does have its issues, cross compiling just works.

[giancarlostoro]

I went from POP OS (Ubuntu) to EndeavourOS (Arch) Linux because some random software with an appimage or whatever refused to run with Ubuntus “latest” GLIBC and it ticked me off, I just want to run more modern tooling, havent had any software I couldnt just run on Arch, going on over a year now.

[moogly]

Indeed. As late as 2 hours ago I had to change the way I build a private Tauri 2.0 app (bundled as .AppImage) because it wouldn't work on latest Kubuntu, but worked on Fedora and EndeavourOS. So now I have to build it on Ubuntu 22.04 via Docker. Fun fun.

Had fewer issues on EndeavourOS (Arch) compared to Fedora overall though... I will stay on Arch from now on.

[arendtio]

Well, traditionally, there was no Python/pip, JS/npm in Linux development, and for C/C++ development, the package manager approach worked surprisingly well for a long time.

However, there were version problems: some Linux distributions had only stable packages and therefore lacked the latest updates, and some had problems with multiple versions of the same library. This gave rise to the language-specific package managers. It solved one problem but created a ton of new ones.

Sometimes I wish we could just go back to system package managers, because at times, language-specific package managers do not even solve the version problem, which is their raison d'être.

[majoe]

Nix devShells works quite well for Python development (don't know about JS) Nixpkgs is also quite up to date. I haven't looked back, since adopting Nix for my dev environments.

[tomkarho]

.NET does have flags to include the necessary dependencies with the executable these days so you can just run the .exe and don't need to install .net on the host machine. Granted that does increase the size of the app (not to mention adding shitton of dll's if you don't build as single executable) but this at least is a solved problem.

[tgtweak]

They do now, after .net core and several other iterations. You'll also be shipping a huge executable compared to a clr linked .net app (which can be surprisingly small).

[IshKebab]

> python in another realm here as well

uv has more of less solved this (thank god). Night and day difference from Pip (or any of the other attempts to fix it honestly).

At this point they should just deprecate Pip.

[rbanffy]

I have never experienced issues with pip, and I’m not sure it’s whether I’m doing something that pip directly supports and avoiding things it doesn’t help with.

I’d really love to understand why people get so mad about pip they end up writing a new tool to do more or less the same thing.

[LtWorf]

Ah yes let's all depend on some startup that will surely change the license at some point.

[vips7L]

.net has been able to ship the runtime with your app for years.

[calvinmorrison]

> Toolchains on linux are not clear from dependency hell either - ever install an npm package.

That's where I stopped.

Toolchains on linux distributions with adults running packaging are just fine.

Toolchains for $hotlanguage where the project leaders insist on reinventing the packaging game, are not fine.

I once again state these languages need to give up the NIH and pay someone mature and responsible to maintain packaging.

[crote]

The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.

And when it inevitably leads to all kinds of weird issues the packagers of course can't be reached for support, so users end up harassing the upstream maintainer about their "shitty broken application" and demanding they fix it.

Sure, the various language toolchains suck, but so do those of Linux distros. There's a reason all-in-one packaging solutions like Docker, AppImage, Flatpak, and Snap have gotten so popular, you know?

[Pay08]

The real kicker is when old languages also fall for this trap. The latest I'm aware of is GHC, which decided to invent it's own build system and install script. I don't begrudge them from moving away from Make, but they could have used something already established.