4 ms·

I haven't looked into CLR in a long time, but it feels like it has a fraction of JVM's adoption and community size. Microsoft also seems to be prioritizing Type

I haven't looked into CLR in a long time, but it feels like it has a fraction of JVM's adoption and community size. Microsoft also seems to be prioritizing Typescript and Node internally with its recent moves.

useerup 4y ago
> Microsoft also seems to be prioritizing Typescript and Node internally with its recent moves. You may want to look at Blazor Webassembly (https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...) and Blazor United (https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-1/ https://devblogs.microsoft.com/dotnet/asp-net-core-updates-i...) They scrapped the old CLR and started over with a new "CLR Core". Then they ported the new CLR Core along with the framework BCL to webassembly and has the CLR running in the browser, upon which they built Blazor Webassembly. So you can now target the CLR and have your code run in the browser. And now they are making progress on Blazor Unified where components can start of as server-side rendered exclusively and transparently and automatically move to webassembly rendering within the same application or page. It really is crazy stuff. Typescript is not the only thing going on in MS Engineering.
- oaiey 4y ago
  To be exact, they have three active CLRs: CoreCLR, (Framework) CLR and MonoVM. WebAssembly, Android and iOS apps use the MonoVM because it is optimized on AOT.
- deleted 4y ago
  [deleted]
soulbadguy 4y ago
At the risk of starting a flame war, the CLI and the coreCLR are fare superior VM and platform from a technical stand point. A lot of the features schedule for jave 21 / project Valhalla are just basically catching up to modern VM design. Of course there is more to the choice of a platform than just the technical differences.
- grumpyprole 4y ago
  The Java JVM was originally designed with a very dynamic language in mind, e.g. Java's support for dynamic loading, dynamic binding, reflection etc. The influences at the time were Smalltalk and ObjectiveC. As Java has evolved to be a much more statically typed language (especially Java 5), the JVM has somewhat struggled to exploit this while maintaining backwards compatibility. It's nowhere near as bad as the Python situation though. I believe the CLR was built with things like parametric specialisation in mind from the beginning.
  - soulbadguy 4y ago
    I agree with all of this. I am not sure if you meant this as a opposition to my comment.
    - grumpyprole 4y ago
      Not opposition, I was just trying to adding some historical context to your comment. I agree the JVM is poorly suited for modern Java and Oracle know this too, hence they are developing GraalVM.
- kaba0 4y ago
  Im what aspect is the VM “far superior”? Where are CLR’s state-of-the-art GC or low-level GC? Or does it have observability tools like JFR?
  - koito17 4y ago
    I do not use C# (in fact, I do my best to avoid Microsoft products). But I can tell you that there are obvious workarounds C# employs to work around its lackluster GC. Stack allocation and spans immediately come to mind. As far as I know, Java offers no way to mark objects as stack-allocated, but C# does. Spans in C# allow programmers to produce subarrays without copying. Enums in C# are stack-allocated, unlike Java. So on, so forth. None of this is a huge deal for Java since some of the best GCs in the world are implemented atop the JVM. But I do think C# offers its workarounds when GC performance gets in the way.

useerup 4y ago

> Microsoft also seems to be prioritizing Typescript and Node internally with its recent moves. You may want to look at Blazor Webassembly (https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...) and Blazor United (https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-1/ https://devblogs.microsoft.com/dotnet/asp-net-core-updates-i...) They scrapped the old CLR and started over with a new "CLR Core". Then they ported the new CLR Core along with the framework BCL to webassembly and has the CLR running in the browser, upon which they built Blazor Webassembly. So you can now target the CLR and have your code run in the browser. And now they are making progress on Blazor Unified where components can start of as server-side rendered exclusively and transparently and automatically move to webassembly rendering within the same application or page. It really is crazy stuff. Typescript is not the only thing going on in MS Engineering.

oaiey 4y ago
To be exact, they have three active CLRs: CoreCLR, (Framework) CLR and MonoVM. WebAssembly, Android and iOS apps use the MonoVM because it is optimized on AOT.
deleted 4y ago
[deleted]

soulbadguy 4y ago

At the risk of starting a flame war, the CLI and the coreCLR are fare superior VM and platform from a technical stand point. A lot of the features schedule for jave 21 / project Valhalla are just basically catching up to modern VM design. Of course there is more to the choice of a platform than just the technical differences.

grumpyprole 4y ago
The Java JVM was originally designed with a very dynamic language in mind, e.g. Java's support for dynamic loading, dynamic binding, reflection etc. The influences at the time were Smalltalk and ObjectiveC. As Java has evolved to be a much more statically typed language (especially Java 5), the JVM has somewhat struggled to exploit this while maintaining backwards compatibility. It's nowhere near as bad as the Python situation though. I believe the CLR was built with things like parametric specialisation in mind from the beginning.
- soulbadguy 4y ago
  I agree with all of this. I am not sure if you meant this as a opposition to my comment.
  - grumpyprole 4y ago
    Not opposition, I was just trying to adding some historical context to your comment. I agree the JVM is poorly suited for modern Java and Oracle know this too, hence they are developing GraalVM.
kaba0 4y ago
Im what aspect is the VM “far superior”? Where are CLR’s state-of-the-art GC or low-level GC? Or does it have observability tools like JFR?
- koito17 4y ago
  I do not use C# (in fact, I do my best to avoid Microsoft products). But I can tell you that there are obvious workarounds C# employs to work around its lackluster GC. Stack allocation and spans immediately come to mind. As far as I know, Java offers no way to mark objects as stack-allocated, but C# does. Spans in C# allow programmers to produce subarrays without copying. Enums in C# are stack-allocated, unlike Java. So on, so forth. None of this is a huge deal for Java since some of the best GCs in the world are implemented atop the JVM. But I do think C# offers its workarounds when GC performance gets in the way.