5 ms·

No linters in C#? That’s a good one. C# as a language has always been cross-platform. Though the last few versions have made incredible gains in performance o

No linters in C#? That’s a good one. C# as a language has always been cross-platform. Though the last few versions have made incredible gains in performance optimizations. You won’t get the flexibility of C++ but the performance comes close to it in most cases, when written optimally. And you don’t have to deal with arcane, bullshit build systems with a learning curve that is worse than the language, and breaks down on every OS major version update (or its own version updates).

lmm 2y ago
> C# as a language has always been cross-platform. Not really. Like, it notionally ran on FreeBSD, but nontrivial programs never actually worked until recently, and even now they mostly still don't.
- celdon25 2y ago
  The lack of an available runtime implementation, or the transitive dependencies of the dynamically linked reference assemblies, does not preclude the compiled assembly from being cross-platform. The assembly within the file built by a C# compiler contains IL code that can be extracted by cross-platform tooling. There’s nothing OS-specific at that layer. We are talking about the language, not the runtime implementation.
  - lmm 2y ago
    We're talking about what language people use and why. How well it runs on their platform in practice is a much more relevant factor for that than how cross-platform it is in theory.
- neonsunset 2y ago
  https://www.freshports.org/lang/dotnet https://www.freshports.org/lang/dotnet pkg install lang/dotnet Not everything works, and support is community-maintained, but “mostly doesn’t run” does not reflect actual state of affairs.
  - lmm 2y ago
    "Nontrivial programs mostly don't run" is my real experience. I was quite hopeful at first but the culture is very much to use windows libraries even when you don't really need them, and not really care about anything that isn't windows.
    - neonsunset 2y ago
      Do you have a specific scenario and a package name in mind when you say "Nontrivial programs mostly don't run"? This is the only way for this statement to be true. If it's something niche, the question is to the package maintainers, as usual, if it's actively maintained that is. As a sibling comment pointed out, .NET assemblies within Nuget packages are by-definition portable, unless they use platform intrinsics without a fallback and or without using newer crossplat APIs, but this is predominantly specific to SIMD code and a rather niche case that concerns my work. There are some Nuget packages which come packaged with native dependencies, and some of the ancient and unmaintained ones do come with like a single win-x86 .dll inside, but this is a "things you sometimes encounter with C/C++" and in general is a rare occurrence. Nowadays, the packages that have native dependencies either simply expect the host to have them installed (like you install, say, gstreamer), or come with dependent packages per-platform (and the matrix gets quite big: [x86, x64, arm64] x [linux, osx, win]). Like https://github.com/sandrohanea/whisper.net https://github.com/sandrohanea/whisper.net But then again, this has to do with a specific package and its owner, if that's what you meant. Note that there is no culture issue, there is poor framing and a strawman one. "I had issues on a niche target" is not mutually exclusive with cross-platform. Would you say lack of support for SunOS is a damning evidence of "pro-windows agenda"? (whatever it is, I use macOS and Linux hosts mainly and surprisingly and funnily enough, there is work to support SunOS as well) The thinly veiled "but linux/unix!" low effort replies are unfortunate and tiresome. They don't strike me as a productive attitude that seeks to make things work.
      - lmm 2y ago
        > Do you have a specific scenario and a package name in mind when you say "Nontrivial programs mostly don't run"? Not a specific single program (not package) just my general experience of how "find useful-sounding program written in C#" -> "download it, try to run it" usually goes. I could probably dig up the name of the most recent thing I tried it with if you really want (I think it was a video renaming tool) but there's no useful discussion to be had about what a random 1-person project happens to support or not. > But then again, this has to do with specific package and its owner. > Note that there is no culture issue, there is poor framing and a strawman one. If most package owners act a certain way that's what culture is. I doubt either of us has the time to do a statistically valid survey of what's out there. Maybe your experience is different, but let me ask: are you actually using C# programs on non-Windows, and e.g. reporting bugs in them? And finding maintainers take them seriously when you do? > Would you say lack of support for SunOS is a damning evidence of an anti-OSS culture? I think projects that assume the whole-world is Linux and don't support e.g. FreeBSD or Illumos (I assume that's what you meant by SunOS?) are very much anti-OSS, and complain loudly about them when I encounter them, yes. Obviously there are levels of "not supported" here, but "well, your patch sounds ok so I'll merge it, can't promise we won't break FreeBSD again in the future since we don't have the resources to test it" is still better than I've gotten from most C# projects when I've tried.

lmm 2y ago

> C# as a language has always been cross-platform. Not really. Like, it notionally ran on FreeBSD, but nontrivial programs never actually worked until recently, and even now they mostly still don't.

celdon25 2y ago
The lack of an available runtime implementation, or the transitive dependencies of the dynamically linked reference assemblies, does not preclude the compiled assembly from being cross-platform. The assembly within the file built by a C# compiler contains IL code that can be extracted by cross-platform tooling. There’s nothing OS-specific at that layer. We are talking about the language, not the runtime implementation.
- lmm 2y ago
  We're talking about what language people use and why. How well it runs on their platform in practice is a much more relevant factor for that than how cross-platform it is in theory.
neonsunset 2y ago
https://www.freshports.org/lang/dotnet https://www.freshports.org/lang/dotnet pkg install lang/dotnet Not everything works, and support is community-maintained, but “mostly doesn’t run” does not reflect actual state of affairs.
- lmm 2y ago
  "Nontrivial programs mostly don't run" is my real experience. I was quite hopeful at first but the culture is very much to use windows libraries even when you don't really need them, and not really care about anything that isn't windows.
  - neonsunset 2y ago
    Do you have a specific scenario and a package name in mind when you say "Nontrivial programs mostly don't run"? This is the only way for this statement to be true. If it's something niche, the question is to the package maintainers, as usual, if it's actively maintained that is. As a sibling comment pointed out, .NET assemblies within Nuget packages are by-definition portable, unless they use platform intrinsics without a fallback and or without using newer crossplat APIs, but this is predominantly specific to SIMD code and a rather niche case that concerns my work. There are some Nuget packages which come packaged with native dependencies, and some of the ancient and unmaintained ones do come with like a single win-x86 .dll inside, but this is a "things you sometimes encounter with C/C++" and in general is a rare occurrence. Nowadays, the packages that have native dependencies either simply expect the host to have them installed (like you install, say, gstreamer), or come with dependent packages per-platform (and the matrix gets quite big: [x86, x64, arm64] x [linux, osx, win]). Like https://github.com/sandrohanea/whisper.net https://github.com/sandrohanea/whisper.net But then again, this has to do with a specific package and its owner, if that's what you meant. Note that there is no culture issue, there is poor framing and a strawman one. "I had issues on a niche target" is not mutually exclusive with cross-platform. Would you say lack of support for SunOS is a damning evidence of "pro-windows agenda"? (whatever it is, I use macOS and Linux hosts mainly and surprisingly and funnily enough, there is work to support SunOS as well) The thinly veiled "but linux/unix!" low effort replies are unfortunate and tiresome. They don't strike me as a productive attitude that seeks to make things work.
    - lmm 2y ago
      > Do you have a specific scenario and a package name in mind when you say "Nontrivial programs mostly don't run"? Not a specific single program (not package) just my general experience of how "find useful-sounding program written in C#" -> "download it, try to run it" usually goes. I could probably dig up the name of the most recent thing I tried it with if you really want (I think it was a video renaming tool) but there's no useful discussion to be had about what a random 1-person project happens to support or not. > But then again, this has to do with specific package and its owner. > Note that there is no culture issue, there is poor framing and a strawman one. If most package owners act a certain way that's what culture is. I doubt either of us has the time to do a statistically valid survey of what's out there. Maybe your experience is different, but let me ask: are you actually using C# programs on non-Windows, and e.g. reporting bugs in them? And finding maintainers take them seriously when you do? > Would you say lack of support for SunOS is a damning evidence of an anti-OSS culture? I think projects that assume the whole-world is Linux and don't support e.g. FreeBSD or Illumos (I assume that's what you meant by SunOS?) are very much anti-OSS, and complain loudly about them when I encounter them, yes. Obviously there are levels of "not supported" here, but "well, your patch sounds ok so I'll merge it, can't promise we won't break FreeBSD again in the future since we don't have the resources to test it" is still better than I've gotten from most C# projects when I've tried.