There are plenty of languages built on the CLR [1], including variants of Clojure, Python, and Ruby. Then there's the "official" languages: C#, C++/CLI, VB.NET, JScript.net.

I suspect what's going on is that 1) unlike Java C# has actually evolved so the need for "escape hatch" languages is lesser, and 2) .NET developers want to use languages with rich Visual Studio tooling.

https://en.m.wikipedia.org/wiki/List_of_CLI_languages

Don't forget F#!

Its future is uncertain with lack of UWP support, the way things are going expect Microsoft to offer it to the community.

I hope being proven wrong though.

With the exception of UWP support (which I'm sure will come), F#'s future seems pretty certain to me. There seems to have been a lot of interest in it lately, probably fueled by the current hype over functional programming.

Check the newly released Visual Studio 15.3.

https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net...

Apparently lack of support wasn't enough to delay Visual Studio 15.3's release, just let the community deal with it.

It also doesn't help when prominent members of that that community keep spreading FUD about UWP, driving more Windows developers away from F#.

https://www.reddit.com/r/programming/comments/6tppt4/f_and_n...

https://twitter.com/k_cieslak/status/896658073338695680

https://twitter.com/k_cieslak/status/896847612766289921

https://twitter.com/k_cieslak/status/897036090489671680

Fully agree with you regarding that prominent member.

Of course he doesn't care about UWP support, as he wants to promote his own VSCode plugin.

Also sad to see those members who liked his tweets.

We can forget about UWP support, it isn't going to happen in the near future, who knows if it ever will.

"The F# team is currently focused on .NET Core tooling in Visual Studio and further support for .NET Core as it evolves. There is no ETA for .NET Native/UWP support at this time."

-- Phillip Carter [MSFT]

https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net...

Better focus on C# and C++ and call it a day.

I really can't stand C#. F# is what drove me to .NET in the first place.

And I don't like going back to C++, is there any GUI/XAML tooling for it? If not, I'd rather use something like Rust.

With UWP, Visual C++ kind of finally caught up with C++ Builder, it even has support from Blend for UI design.

MFC is mostly on maintenance and new application should use XAML + C++/CX.

C++/CX makes use of the C++/CLI extensions but it targets AOT compilation to native code instead.

The alternatives are C++ with WRL (Windows Runtime Library), basically ATL replacement, and what most Microsoft teams actually use for the UWP kernel components.

https://docs.microsoft.com/en-us/cpp/windows/universal-windo...

Because most C++ devs would rather use something more standards friendly, there is work in progress to eventually replace C++/CX with C++/WinRT, taking advantage of C++17 features.

“Embracing Standard C++ for the Windows Runtime"

https://www.youtube.com/watch?v=lm4IwfiJ3EU

“Putting Coroutines to Work with the Windows Runtime"

https://www.youtube.com/watch?v=v0SjumbIips

Thanks this is great information. Have you looked into using Scala or Rust for UWP apps?

Not much, throughout my career I have learned that the best path is always to only use the officially supported SDK languages for production code.

All productivity or enjoyment using alternative languages gets lost in extra FFI layer, unavailable platform documentation, lack of support on the IDEs, poorer debugging, GUI tooling and code generation.

So I only use alternative languages to learn about new concepts and ways to improve my skillset, but in what concerns production code, the golden rule is 100% SDK languages.

Going back to your question, Java on UWP is only possible via the JVM provided by CodenameOne and I think it actually makes use of the Desktop Bridge, so that rules out Scala.

Rust still has a lot to catch up with C++ for using COM in a productive way, let alone .NET based languages.

UWP is basically what .NET should have been, if they had kept the original COM+ plans instead of going with the CLR. So any language targeting UWP needs to have seamless COM support, and ability to handle .NET metadata.

Point taken; it's obviously not a top priority for them, with C# remaining the primary focus. I guess that makes sense, since so many more devs use C#.

While dissapointing, I'm sure (well, I hope :) F# support will land in VS before too long. In the mean-time, VS Code really is a great alternative

> is there something about the JVM that gives rise to such vibrant ecosystems

Java.

It evolves too slowly, that’s why people try to fix it creating another languages on top of JVM. MS did much better developing C#, therefore less need for alternative languages.

that might be true for kotlin, but probably not for Clojure, Scala, Groovy and JRuby

I'd argue it still could be true. The CLR has variants of a lot of those too, but they are much less popular. All those alternative languages for the JVM probably still would have been born at some point even if Java adapted faster, but they are as popular as they are due to Java's slow adaptation.

This isn't a very good argument, but name recognition is on totally different level with alternative JVM languages too. Most people have heard of Groovy even if they don't use it. Boo on the other hand...?

Beanshell came before Apache Groovy and had many dynamic features useful in scripting for the JVM. Groovy essential copied many of those Beanshell features, then added closures, which was Groovy's real contribution to the JVM ecosystem. Soon after there was some disagreement among its leaders over the syntax when closures are used as Kotlin-style builders.

Huh, I did't know there was lineage there. Coincidentally, I've actually used Beanshell; integrating it in to a project was a SUPER pleasant experience.

It was some weird find/replace thing I contrived in college to let you do weird crap like define a bunch named regexes and use them to match and transform stuff. Contrived example that chops the "L" off long literals in files with the (optional) beanshell integration:

  integer {
        -?[0-9]+
  }

  really_bad_long_chopper {
    <integer>L
  } -> {
    String original = match.group(0);
    return original.substring(0, original.length() -1);
  }

The .NET runtime is not superior to the JVM and probably never has been. Certainly not in performance. The JVM stomps .NET CLR in performance.

C# has been superior to Java, as a language, for quite a long time (IMHO) and likely always will be. The libraries, well, I don't know. Pretty similar I guess.

The thing to consider about programming languages is there's no way to make money from them anymore. That means they're either loss leaders for some other product (Swift : iOS, C# : Windows), the result of academic research (Scala, Haskell, etc), one man's personal quest to redefine coding (Clojure, Groovy, Ruby), or the result of a company attempting to optimise its own processes or products (Go, JavaScript, Kotlin). Oh yes. And then there's C++ which defies categorisation :-)

So now you look at the categories above and what do you observe? That a lot of the developers will be essentially hobbyist in nature, or working on products that are often used on UNIX. These people will want to build on a cross platform runtime. Until recently .NET was not cross platform.

JVM bytecode is also a bit simpler than .NET bytecode and has better support for dynamic languages. Many languages are dynamic.

.NET always had AOT compilation from day 1, and now has .NET Native, which is the same backend as Visual C++.

It had forks being used to write Singularity and Midori, and official support for unsafe code if performance required it to, including ways to manually manage memory.

The CLR has native APIs for IL rewriting engines, via the profiler native API.

Supports value types, SIMD, and the roadmap to C# 8.0 will be adding more features bringing C# low level capabilities closer to C++.

Java will be getting some of these goodies as per Java Language Summit 2017, but they are all targeting Java 10 or later, while .NET is delivering them on 2017.

It was my understanding that it was hard to compare the JVM and the CLR in terms of performance. But I'd always heard that the CLR was faster because of support for true generics, unsafe code, and value types.

I'm really interested in this, mind going into a bit more details?

Wait, you believe outside of Hacker News (you know, "broscience") people use (or even know) any one of "Clojure, Scala, Kotlin, Groovy, JRuby"?

I think I have news for you. No company without a foosball table in the break room would remotely think of such a thing.

The users of VB.NET alone dwarf any of those languages. There is a reason Microsoft keeps updating that.

You do know that Google is backing Kotlin right ? And that Apache Spark that runs Facebook's ETL is in Scala. Or that Clojure is used at https://clojure.org/community/companies ?

My guess would be because Microsoft technologies were to tied to windows. If you, a non-corporate entity is creating a new programming language with aiming at being mainstream, why would you choose a closed non-multiplatorm ecosystem?

Also, the JVM is better suited (much better performance) for running dynamically typed code.

You also seem to be confirming .Net has "superior performance" over the JVM, from where do you get that? .Net still has a long way to go to in being as mature/battle-test as the JVM is in linux IMO.

It's because Microsoft's main client application platform's .NET runtime is not .NET compliant, resulting in their own language, F#, not be supported. See here https://news.ycombinator.com/item?id=15007166

They act as if C# is the only .NET language and nothing will change if we don't speak up about it.

If you think of the people that would naturally look to C# there are a lot of reasons why you might have an existing C++ codebase and migrate to a C#/C++ codebase. It's relatively straightforward to link the two languages where doing the same for Java is a lot more work. There are lots of legacy applications with decades-old business logic that can be glued into C# WinForms and work swimmingly. Java has this but the interop code is a lot of work.

Java applications also in my opinion struggle to feel 'native' especially on Windows to the same level of niceness as C#/C++.

I would say that the JVM has longer history of open source and a much larger ecosystem of libraries. If you're building a language on top of JVM you can take advantage of that.

Also pretty sure JVM has better performance because of better JIT and GC. The CLR had a second mover advantage to fix a lot of platform level things like utf8 strings, generics, tail calls, etc.

OK well .Net has Clojure, F#, C#, VB and Rosyln (compiler as a service). CLR vs JVM wise; both are highly optimized virtual machines with years of man hours behind each of them.