6 ms·

Why are there so few new languages built on the .NET platform ? This is a genuine question - is there something about the JVM that gives rise to such vibrant ec

Why are there so few new languages built on the .NET platform ? This is a genuine question - is there something about the JVM that gives rise to such vibrant ecosystems. Clojure, Scala, Kotlin, Groovy, JRuby : Most importantly, every one of them is in production use - not just as toy/experimental languages. And we havent even opened the Pandora's box that is Java 9+Truffle. There's a lot of broscience that .NET is superior to the JVM - is that on sheer performance only ?

hacker_9 9y ago
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.
Scarbutt 9y ago
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.
jahewson 9y ago
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 https://en.m.wikipedia.org/wiki/List_of_CLI_languages
- GordonS 9y ago
  Don't forget F#!
  - pjmlp 9y ago
    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.
    - GordonS 9y ago
      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.
      - pjmlp 9y ago
        Check the newly released Visual Studio 15.3. https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net-core-roadmap-update/ 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.
        GordonS 9y ago
        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
        TensorMetric 9y ago
        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_net_core_roadmap_update/ https://www.reddit.com/r/programming/comments/6tppt4/f_and_n... https://twitter.com/k_cieslak/status/896658073338695680 https://twitter.com/k_cieslak/status/896658073338695680 https://twitter.com/k_cieslak/status/896847612766289921 https://twitter.com/k_cieslak/status/896847612766289921 https://twitter.com/k_cieslak/status/897036090489671680 https://twitter.com/k_cieslak/status/897036090489671680
Const-me 9y ago
> 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.
- merb 9y ago
  that might be true for kotlin, but probably not for Clojure, Scala, Groovy and JRuby
  - jdc0589 9y ago
    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...?
    - vorg 9y ago
      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.
      - jdc0589 9y ago
        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); }
mike_hearn 9y ago
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.
- pjmlp 9y ago
  .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.
- JamesBarney 9y ago
  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?
ledgerdev 9y ago
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.
TensorMetric 9y ago
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 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.
xemdetia 9y ago
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++.
revelation 9y ago
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.
- sandGorgon 9y ago
  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 https://clojure.org/community/companies ?

hacker_9 9y ago

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.

Scarbutt 9y ago

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.

jahewson 9y ago

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 https://en.m.wikipedia.org/wiki/List_of_CLI_languages

GordonS 9y ago
Don't forget F#!
- pjmlp 9y ago
  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.
  - GordonS 9y ago
    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.
    - pjmlp 9y ago
      Check the newly released Visual Studio 15.3. https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net-core-roadmap-update/ 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.
      - GordonS 9y ago
        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
      - TensorMetric 9y ago
        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_net_core_roadmap_update/ https://www.reddit.com/r/programming/comments/6tppt4/f_and_n... https://twitter.com/k_cieslak/status/896658073338695680 https://twitter.com/k_cieslak/status/896658073338695680 https://twitter.com/k_cieslak/status/896847612766289921 https://twitter.com/k_cieslak/status/896847612766289921 https://twitter.com/k_cieslak/status/897036090489671680 https://twitter.com/k_cieslak/status/897036090489671680

Const-me 9y ago

> 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.

merb 9y ago
that might be true for kotlin, but probably not for Clojure, Scala, Groovy and JRuby
- jdc0589 9y ago
  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...?
  - vorg 9y ago
    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.
    - jdc0589 9y ago
      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); }

mike_hearn 9y ago

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.

pjmlp 9y ago
.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.
JamesBarney 9y ago
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?

ledgerdev 9y ago

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.

TensorMetric 9y ago

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 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.

xemdetia 9y ago

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++.

revelation 9y ago

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.

sandGorgon 9y ago
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 https://clojure.org/community/companies ?