> I assume you haven't had the opportunity to use .NET tooling yet.
I've used it some, not to the same extent, and generally at work - another one of those cultural differences I've found is that most JVM/etc. companies are at least theoretically on-board with open-sourcing their non-core libraries, whereas in .NET land there's much less willingness to do that. The actual tooling is good (the best I've used in some ways), but that's only one piece of the puzzle.
> Are you interested in getting .NET SDK to run on FreeBSD?
The SDK itself runs great. I'm more interested in being able to drop in a small program that solves a problem for me - like, that's the way I started with Ruby or OCaml or Go or Erlang, there was a standalone thing that I could pick up and use as part of my system, I didn't have to rearchitect everything or buy into the whole ecosystem or change my workflow. I don't even know Erlang at all, but it's running in my stack in that I'm running Riak (with the Java driver), and that gives me a place where it's already adding value and I could dip my toe further into it if I wanted. That's the thing I've never found from the .NET world - a reason to run it in my system that doesn't require me to fully buy into it to get started. (I guess in theory SQL server could be that, but it's non-opensource and doesn't have any compelling selling point over the substitutes. Part of it's honestly probably just marketing, but that goes for any new language/tool - the most persuasive thing is hearing other people having success with it in a similar situation)
> Was "the evil" software just an ancient WinForms application?
Quite possibly, but I remember command-line tools also not working - just these random one-developer tools have no reason to publish versions for other platforms, and it's not the natural workflow, so they don't. Probably the issues are minor (like, I remember one that was using some windows-only part of the standard library to do something incredibly basic like base64 decoding - I'm sure someone who uses .NET every day would take 30 seconds to swap that out with using the right part of the .NET core standard library instead. But it doesn't make for an easy onramp)
I've used it some, not to the same extent, and generally at work - another one of those cultural differences I've found is that most JVM/etc. companies are at least theoretically on-board with open-sourcing their non-core libraries, whereas in .NET land there's much less willingness to do that. The actual tooling is good (the best I've used in some ways), but that's only one piece of the puzzle.
> Are you interested in getting .NET SDK to run on FreeBSD?
The SDK itself runs great. I'm more interested in being able to drop in a small program that solves a problem for me - like, that's the way I started with Ruby or OCaml or Go or Erlang, there was a standalone thing that I could pick up and use as part of my system, I didn't have to rearchitect everything or buy into the whole ecosystem or change my workflow. I don't even know Erlang at all, but it's running in my stack in that I'm running Riak (with the Java driver), and that gives me a place where it's already adding value and I could dip my toe further into it if I wanted. That's the thing I've never found from the .NET world - a reason to run it in my system that doesn't require me to fully buy into it to get started. (I guess in theory SQL server could be that, but it's non-opensource and doesn't have any compelling selling point over the substitutes. Part of it's honestly probably just marketing, but that goes for any new language/tool - the most persuasive thing is hearing other people having success with it in a similar situation)
> Was "the evil" software just an ancient WinForms application?
Quite possibly, but I remember command-line tools also not working - just these random one-developer tools have no reason to publish versions for other platforms, and it's not the natural workflow, so they don't. Probably the issues are minor (like, I remember one that was using some windows-only part of the standard library to do something incredibly basic like base64 decoding - I'm sure someone who uses .NET every day would take 30 seconds to swap that out with using the right part of the .NET core standard library instead. But it doesn't make for an easy onramp)