5 ms·

Visual Studio is not open source and neither is .NET tooling for VS Code. https://isdotnetopen.com/ https://isdotnetopen.com/ explains a lot of this and has ma

by bbkane 2y ago

Visual Studio is not open source and neither is .NET tooling for VS Code. https://isdotnetopen.com/ https://isdotnetopen.com/ explains a lot of this and has made me avoid .NET as well. Competing languages are pretty good these days and a lot more open.

cess11 2y ago
OK, that looks pretty dire, especially the corporate bullying. Recently I tried running some .NET-stuff under Linux but it was a mess, Wine choked on stuff and even figuring out .NET versions seemed like it would have taken so much of my time that it could easily have bought a MICROS~1 machine. So we just dug out an old one for running that software instead. I've also tried to build some applications under Linux that were supposedly supported, a year or so back, it was also messy. In my dayjob I've built stuff in Java and Racket and when I've built it on the target platform it just runs, it seems like a much nicer experience. I'm sure the Mono folks are doing a great thing and some people say that the Steam compatibility layer is something of a miracle, but it's not like I can shove in the enterprise tools I had to use in a gaming framework. For one GDPR doesn't allow me to load the data if I did.
- neonsunset 2y ago
  Statements from Miguel De Icaza on .NET in the last three or so years are mostly useful if you would like to baselessly bash the technology and look for anything that can confirm your bias (nowadays he advocates for Swift which is way less FOSS). Of course if you put a stick in the wheel it won't turn. Engineers who are unburdened by prejudice and are up-to-date with industry advances simply do `sudo dnf install dotnet-sdk-8.0` and get on with their life while accounts like in this discussion keep posting how it is """unusable""" on Linux (it runs better, and is more portable for deployment targets (self-contained JIT and AOT) than Python or JVM). Also, Mono (not the Unity fork one) is now just a part of https://github.com/dotnet/runtime https://github.com/dotnet/runtime like CoreCLR and is used for targets which CoreCLR is not suitable for or does not support yet like WASM (NativeAOT-LLVM is in the experimental stage).
  - bbkane 2y ago
    I suppose you didn't read the link. It's not complaining about usability of deployed .NET apps on Linux, it's complaining about the openness of the tooling and community of the .NET ecosystem.
    - neonsunset 2y ago
      I'm very well aware of it. It's mostly attention-seeking bait taking Miguel de Icaza's already critical posts (the only kind shared by his twitter/mastodon persona) even further out of context. You are not arguing this from PoV of evaluating .NET as a technology or seeking to better the software ecosystem, you just found a convenient content for the arguments of your messages. It's known, solved, not new, and people carry on using Rider and VSC as usual.
      - bbkane 2y ago
        > You are not arguing this from PoV of evaluating .NET as a technology or seeking to better the software ecosystem I am evaluating .NET from exactly this perspective, and I heavily consider ecosystem openness in that evaluation. .NET has an undeniably more closed-source ecosystem than competitors like Go or Rust or Python. It's fine if you don't think ecosystem openness is as important as I do, that's a totally valid perspective. I'm sorry if my post comes across as implying the way I think is "the only valid perspective" on how to choose a tech stack. My intent was just to answer the OP's question about the openness of the IDE.
        neonsunset 2y ago
        Except the response ignores the fact that the posted links have little to do with the openness of the ecosystem. .NET does not restrict who can use which APIs nor they are designed in a way to prevent the use of "third-parties". e.g. VS and VSC debugger implementations are not the only one that exist, Rider uses its own, there is a Samsung-maintained open debugger and likely a few more specialized ones I'm unaware of. There also exists Unity which is moving over to CoreCLR, it is certain they have fully custom tooling. There are also areas that may not be as open as they could be, which yet simply do not exist in other languages - for example Go and GUI frameworks (.NET's AvaloniaUI works well on Linux, while MAUI doesn't at all even though there seems to be now work done in that area, you can also use Gir.Core to write GTK4 applications). Hot reload drama is uncharacteristically bad, that is true, but it's a minor feature that happens to be a convenient scapegoat repeated ad nauseam. If anything, your comments only support my argument that C# receives criticism regardless of improvements that it gets, while Swift and Go receive undeserved good will regardless of the actions conducted by companies investing in them. I should probably learn my lesson and stop arguing with engineers engaged in this kind of double-standards thinking repeating the same old statements that lost relevance.

by bbkane 2y ago

cess11 2y ago

OK, that looks pretty dire, especially the corporate bullying. Recently I tried running some .NET-stuff under Linux but it was a mess, Wine choked on stuff and even figuring out .NET versions seemed like it would have taken so much of my time that it could easily have bought a MICROS~1 machine. So we just dug out an old one for running that software instead. I've also tried to build some applications under Linux that were supposedly supported, a year or so back, it was also messy. In my dayjob I've built stuff in Java and Racket and when I've built it on the target platform it just runs, it seems like a much nicer experience. I'm sure the Mono folks are doing a great thing and some people say that the Steam compatibility layer is something of a miracle, but it's not like I can shove in the enterprise tools I had to use in a gaming framework. For one GDPR doesn't allow me to load the data if I did.

neonsunset 2y ago
Statements from Miguel De Icaza on .NET in the last three or so years are mostly useful if you would like to baselessly bash the technology and look for anything that can confirm your bias (nowadays he advocates for Swift which is way less FOSS). Of course if you put a stick in the wheel it won't turn. Engineers who are unburdened by prejudice and are up-to-date with industry advances simply do `sudo dnf install dotnet-sdk-8.0` and get on with their life while accounts like in this discussion keep posting how it is """unusable""" on Linux (it runs better, and is more portable for deployment targets (self-contained JIT and AOT) than Python or JVM). Also, Mono (not the Unity fork one) is now just a part of https://github.com/dotnet/runtime https://github.com/dotnet/runtime like CoreCLR and is used for targets which CoreCLR is not suitable for or does not support yet like WASM (NativeAOT-LLVM is in the experimental stage).
- bbkane 2y ago
  I suppose you didn't read the link. It's not complaining about usability of deployed .NET apps on Linux, it's complaining about the openness of the tooling and community of the .NET ecosystem.
  - neonsunset 2y ago
    I'm very well aware of it. It's mostly attention-seeking bait taking Miguel de Icaza's already critical posts (the only kind shared by his twitter/mastodon persona) even further out of context. You are not arguing this from PoV of evaluating .NET as a technology or seeking to better the software ecosystem, you just found a convenient content for the arguments of your messages. It's known, solved, not new, and people carry on using Rider and VSC as usual.
    - bbkane 2y ago
      > You are not arguing this from PoV of evaluating .NET as a technology or seeking to better the software ecosystem I am evaluating .NET from exactly this perspective, and I heavily consider ecosystem openness in that evaluation. .NET has an undeniably more closed-source ecosystem than competitors like Go or Rust or Python. It's fine if you don't think ecosystem openness is as important as I do, that's a totally valid perspective. I'm sorry if my post comes across as implying the way I think is "the only valid perspective" on how to choose a tech stack. My intent was just to answer the OP's question about the openness of the IDE.
      - neonsunset 2y ago
        Except the response ignores the fact that the posted links have little to do with the openness of the ecosystem. .NET does not restrict who can use which APIs nor they are designed in a way to prevent the use of "third-parties". e.g. VS and VSC debugger implementations are not the only one that exist, Rider uses its own, there is a Samsung-maintained open debugger and likely a few more specialized ones I'm unaware of. There also exists Unity which is moving over to CoreCLR, it is certain they have fully custom tooling. There are also areas that may not be as open as they could be, which yet simply do not exist in other languages - for example Go and GUI frameworks (.NET's AvaloniaUI works well on Linux, while MAUI doesn't at all even though there seems to be now work done in that area, you can also use Gir.Core to write GTK4 applications). Hot reload drama is uncharacteristically bad, that is true, but it's a minor feature that happens to be a convenient scapegoat repeated ad nauseam. If anything, your comments only support my argument that C# receives criticism regardless of improvements that it gets, while Swift and Go receive undeserved good will regardless of the actions conducted by companies investing in them. I should probably learn my lesson and stop arguing with engineers engaged in this kind of double-standards thinking repeating the same old statements that lost relevance.