Well, I haven't seen those commenters before, and I'm still not excited about using .NET, (and I'm the type of person who you'd expect to be getting excited about a strongly-typed shell) so either that's not the driving factor here, or...

> Azure, for one. Azure's primary and preferred method of interaction instead of it's UI is with it's API, which is also available fully wrapped up as Powershell cmdlets which again run on all three OS's.

I have been getting into Azure, and I've found the `az cli` somewhat lacking, for example "why is the default 'get' behavior emitting a huge blob of JSON instead of printing a table that humans can read?" and I thought, maybe this is a reflection of the fact that they'd prefer you write an API client and build it into a portal for your customers rather than asking people on your team to use the CLI directly?

Seems you've confirmed this for me here. It would be nice to use a strongly typed interface rather than parsing JSON blobs, maybe I will end up checking that out!

Thanks :)

> > make my customers install the .NET runtime at the proper version and fiddle with .exe files > > You don't, you either get them to install it's APT .deb file or <insert distro packaging format here> or wget the dotnet-install script. OR, you just build your app with .NET runtime packaged in .so file alongside your app.

My point was, they do need to have or obtain the correct version of the runtime to go with your app, and if there are different apps with different maintenance cycles, that might mean you need multiple runtimes installed and a way of switching between them. That's a big deal!

If I want to adopt a runtime, I hope I'm adopting it for more than just one app. Now all of these apps need to be on the treadmill, actively maintained, or some upgrade might break, pinning me to a particular version, and then I'm stuck.

If there was ever a compelling problem to solve, it's here, although based on the breadth of languages and frameworks that still experience this problem in one way or another, I think it's likely unsolvable. You either need someone (a distro) running the compilers and checking that things still work together in concert with the maintainers of the upstream software, or you need to be statically linking, or get yourself something like venv/rvm that makes managing multiple versions of a runtime a low-overhead activity (so you can have 4 versions if that is what is required for your different maintenance cycles across different services, without needing to break those services out onto four separate servers just to accommodate the language runtime differences.)

Not to rule it out, does the .NET ecosystem have a great answer to this already?

(Edit: I guess "the web application" is the answer, broadly speaking! "Users" don't have to install anything besides a browser.)

> Running the applications involves typing ./my-application which then runs the ELF binary. There is no .exe unless it's on Windows. It's the same install and run story that any of the other languages listed mentioned.

So I'm assuming you can also statically link your .NET binaries and emit a fat binary that will work anywhere, but at tremendous cost in terms of disk usage, (but you makes your choices and you takes your chances) – like I was saying, this is not a problem unique to .NET either, Go binaries from the likes of GCloud and Azure for interacting with their APIs are all enormous, because they want to avoid this problem with their users and they have lots of libraries to pull in.

For me, the killer feature that makes Ruby ecosystem "worth adopting" is open source. You know how rare it is to encounter some Ruby gem which is not open to changes and inspection? I can think of exactly one time I found this, it did block me from using some software (AppDynamics bundled a native ext. with their Rubygem, it had wicked thread safety issues if you upgraded Ruby past a certain version... they did not provide the source, so enterprising customers couldn't fix the problem for themselves and contribute it upstream...) I've been using Ruby professionally for about 14 years, and I saw this issue exactly once.

And that was a choice that one vendor made, and such a rare event that I would never think to let it reflect badly on the language. Go does not seem to have these issues as commonly (where somebody distributes a go package as binary-only) even though the language is not interpreted so it can happen and it wouldn't be unusual or even "against the grain."

This is why I thought of Ruby being primarily executable as an interpreted language as "the guard" against this sort of thing happening in Ruby ecosystem.