Yes, the problem can be solved by using a different language. I'm pretty sure that was the point.

It's choosing a different language, versus choosing a different VM, different libraries, a whole different ecosystem, plus it happens to be quite expensive. The JVM is not home only to Java.

One PITA for me is that whenever talks about various technologies happen on HN, I tend to comment on disadvantages, because it's the disadvantages that dictate the best use cases for that particular technology.

But whenever I do that for .NET / C#, there's like a circle of jerks on HN that down-vote everything that sounds bad about .NET.

That's fine, I had some hopes for Microsoft's .NET, now that it is finally being open-sourced and made multi platform, but when choosing a language, you're also choosing the ecosystem around it and this instance, amongst other interactions I've had, confirms that .NET is not for me and probably never will be.

Cheers,

I just don't see the relevance of your comment. Nobody had indicated any need to use JVM, as far as I'm aware. So you seemed to be addressing "what's the best language for JVM" rather than "what's the best way to solve this problem."

This just isn't a JVM vs .NET competition. If Prolog were the best answer, you could port it to JVM or .NET to your heart's content.

Switching to Scala would mean learning all the Scala baggage (which has good intentions - granted). C# is much more accessible, while still being elegant - hence the ever-rising popularity.

I'm a Scala developer, I love Scala (which is why I keep mentioning it) and would be interested to know what baggage you're referring to.

For me Scala is more accessible and elegant than both C# and F# and in my opinion has less baggage.