Hacker News new | ask | show | jobs
by delta_p_delta_x 115 days ago
> terrible ecosystem

.NET is a fantastic ecosystem. Has a decent build and dependency system (NuGet, dotnet run/build, declarative builds in XML). Massive standard library, with a consistent and wide focus on correctness, ergonomics, and performance across the board.

You can write everything in many languages, all on the same runtime: business logic in C#; hot paths interfacing with native libraries in C++/CLI; shell wrappers in PowerShell, document attachments with VB, data pipelines in F#.

I feel more people should use it, or at least try it, but sadly it is saddled with the perception that it is Windows-only, which hasn't been true for a decade (also, IMO, not necessarily a negative, because Windows is a decent OS, sue me).

2 comments

> but sadly it is saddled with the perception that it is Windows-only, which hasn't been true for a decade

In my experience it does not work very well outside of the sanctioned Linux distributions. Quirky heisenbugs and nonsensical crashes made it virtually unusable for me on Void. I doubt that's changed in the years that have since passed.

> not necessarily a negative, because Windows is a decent OS

Is a language runtime worth an operating system? I think that's a paradigm we left behind in the 1970s when the two were effectively inseperable (and interwoven with hardware!) I wouldn't expect someone to swap to using a Unix system because they really want a better Haskell experience.

I just don't see any actual interesting or meaningful reasons to care about .NET, I effectively feel the same way about it that I do about Go. Just not something that solves any problem I have, and doesn't have anything that interests me. Although effectively I did try it, so it's a moot point considering that's one of the outcomes you're wishing for.

> In my experience it does not work very well outside of the sanctioned Linux distributions. Quirky heisenbugs and nonsensical crashes made it virtually unusable for me on Void. I doubt that's changed in the years that have since passed.

It's open source. Did you follow the spirit of Linux to file a bug report of as much sense of the crashes as you could make? Most OSS only supports as many distros as people are willing to test and file accurate bug reports (and/or scratch the itch themselves and solve it). It seems a bit unfair to expect .NET to magically have a test matrix including every possible distro when almost nothing else does. (It's what keeps distro maintainers employed, testing other people's apps, too.)

It probably has gotten better since then, for what it is worth. .NET has gotten a lot of hardening on Linux and a lot of companies are relying on Linux servers for .NET apps now.

At the very least there are very tiny Alpine-based containers that run .NET considerably well and are very well tested, so Docker is always a strong option for .NET today no matter what Linux distro you want on the "bare metal" running Docker.

> Most OSS only supports as many distros as people are willing to test

Linux distros don't differ too significantly from each other nowadays (systemd plus a different package manager most of the time), so I'm almost sure this is not the source of problems.

Nonetheless, I can only add that we have ridiculous slowdowns in some standard library network calls on Linux, and at that point it is just not true that it will "seamlessly run on Linux", unfortunately.

> Did you follow the spirit of Linux to file a bug report of as much sense of the crashes as you could make?

No, because the only reason I needed C#/.NET to work was to use an internal tool someone before me had written in C#/.NET. It was not really to explore C# or make it usable. I just threw out the old tool, wrote a new one in scheme so I could do my job, and moved on with my life. I don't particularly care about this spirit of Linux, and Microsoft's tooling being weirdly fragile isn't my problem. I assume they already know this is an architectural issue, hence why they specify supported distributions. On principle I believe solving the architectural issue is what they should be concerned about, rather than making new bandaids.

> Most OSS only supports as many distros as people are willing to test and file accurate bug reports

The problem is that most runtimes and standard libraries don't need to specify a notion of a "supported" distribution. At best, they just refer to platforms with pre-made packages while happily pointing other distributions to the git repo. Even complicated, highly abstract and weird ones don't make this kind of distinction. SWI-Prolog and its myriad of frameworks (which includes a full blown GNU Emacs clone) work out of the box anywhere. GHC and the RTS work flawlessly out of the box.

I understand (even if I don't feel the same way) why a comprehensive abstraction layer like .NET is evangelized. All the same I have to consider that it's a product of a multi-trillion dollar corporation, made to compete with the thing whose marketing tagline is "write once, run anywhere". That only makes the distro dependency stand in an even harsher relief, frankly.

You like .NET? Perfectly fine and valid, and I assume it actually works for you. Just indicating that "cross platform" is contingent on more than kernel and cpu architecture here, which is fairly unusual for this type of software. That's before we get into things like comparisons with ocaml, which I know is miserable on Windows and thus is often considered not really something you'd seriously consider using there. The .NET ecosystem essentially has the same problem outside of Windows where the grain and expectations of the tooling are counter-intuitive to the operating system and usual modus operandi of its users.

I think there is an architectural problem, but not where you seem to be expecting it to be. I got caught up in some low level distro nonsense+drama from smashing my head against horrors deep in autoconf in automake and got a deep look into the realm of the Distribution Maintainer lifestyle and how much Linux distributions are individual snowflakes despite presumably all being the same OS. As the old joke goes "the only stable ABI on Linux is Win32".

.NET has a huge kitchen sink standard library. Maybe the closer parallel is Python and Python has had periods where it only supported a few named distributions, too. That's not currently the case, but "how the sausage is made" is still a lot grosser than you might expect, with some Distribution Maintainers maintaining entire forks and a lot of the work not done by Python directly. Python is everywhere because it became one of the favorite shell scripting languages of Distribution Maintainers. (Which also exacerbated the Python 2 to 3 migration because entire distros got stuck on 2 while all their shell scripts got rewritten.) (But also if you want to compare Java's cross platform to .NET's I think we need a long digression into how many Java runtimes there are and the strange and subtle incompatibilities of different distro's affiliations to one or another. I also made the mistake of trying to use a Java application as a regular application in my youth of accidentally dealing with deep distro incompatibilities. That was also not fun.)

I get it, you don't have to like .NET. I just think you have an inflated view of what "cross platform" means when it comes to Linux. Linux isn't just one platform. Most things are rebuilt from source constantly because the binary interfaces especially libc's/glibc's under them are constantly shifting like quicksand. See also the messes that are Flatpak and Snap and how much work they've done to try to build around distro incompatibilities (by building increasingly more complex wish-it-were-VMs).

I work with C#/NuGet on windows every day and my experience is entirely the opposite.

The build and dependency systems are an abysmal esoteric, poorly documented mix between csproj files, sln files, random scattered json files, etc.

The standard library in my experience sucks and has all sorts of issues, especially around Uris, DateTimes, etc.

And the ecosystem itself has such a low quality bar, ironically _especially_ with anything made by microsoft. For every nuget package that's well-designed, well-documented, and easy-to-use, there's five which have bugs and undocumented exceptions and poorly-designed APIs.

If you work with old .NET Framework, then maybe I would agree. What kind of issues do you have in standard library or how they are only biting you? Nothing is perfect, but compared to other (popular) alternatives, C#/.NET is the best you can get today.