4 ms·

This is really neat, I always wanted to see other languages target .NET much like the JVM was a popular platform to target. Considering .NET is fully MIT licens

This is really neat, I always wanted to see other languages target .NET much like the JVM was a popular platform to target. Considering .NET is fully MIT licensed I am surprised we dont see more languages that target .NET

pjmlp 2y ago
That is why CLR used to mean Common Language Runtime, and there were so many languages on the launch event and .NET SDK bundled on computer magazines back in 2001. Then the Windows only focus (for a while there was Rotor), and Microsoft being Microsoft, all that interest faded away and people focused on the JVM, even though MSIL was designed for all kind of languages (well dynamic came later with Iron languages and DLR), including C and C++. Nowadays CLR almost feels to have changed into C# Language Runtime, given the C# centric decision on modern .NET design.
- neonsunset 2y ago
  While "C# Language Runtime" as a joke term certainly exists, most runtime improvements benefit all languages that target it, individual changes would have different impact on different languages but that's expected. It is likely further devirt and escape analysis work will have greater impact on F# for example.
  - pjmlp 2y ago
    As mentioned, I am waiting for .NET 9 final release notes in November. Also a solution for code generators, analysers, interceptors usage in .NET libraries and how to consume them from F#, some day, if ever.
  - debugnik 2y ago
    > most runtime improvements benefit all languages that target it And most CIL ABI additions to the CLR driven by C# totally break them, because the C# ecosystem adopts them immediately (recently even breaking changes in the shared framework!), and there's no modern equivalent to the Common Language Specification. Plus, no library writer would care if there was a CLS 2.0 because every CLR language other than C# and F# is in maintenance mode or simply abandoned.
- aninteger 2y ago
  > Nowadays CLR almost feels to have changed into C# Language Runtime, given the C# centric decision on modern .NET design. Definitely! VB.Net is basically "dead" and F# will never really reach critical mass.
  - jjtheblunt 2y ago
    F# features creep slowly into C#, though, I feel. (as those of Scala would creep into Java at a delay)
neonsunset 2y ago
Historical precedent and anti-.NET bias - CLI/CIL is a much more powerful and flexible bytecode target than JVM, but it is also not as well-documented with fewer guest languages and, as a result, community know-how. With that said, it really is a breath of fresh air to see projects like this one, alongside ongoing work on F#, the main "other" language of .NET, and a couple small toy-like languages like Draco. There are also IKVM and ClojureCLR/ClojureCLR.Next.
layer8 2y ago
Microsoft didn’t manage to have Visual Basic target .NET without turning its semantics into C# with different syntax, so this will be interesting to see.
- moomin 2y ago
  Anyone remember J#?
  - danielovichdk 2y ago
    IronRuby?
  - giancarlostoro 2y ago
    That was a in-between for J++ their Java hard fork.
- pjmlp 2y ago
  Yes it did, the complaints were mostly from VB 6 folks complaining about VB.NET 1.0, several VB features like Me objects, being again more dynamic, repl, were eventually added back for those that kept around in VB.NET land. Not that it matter much nowadays, given that its development has been placed on freeze mode.
aidenn0 2y ago
Before Rich made Clojure for the JVM, he wrote dotLisp[1] for the CLR. Not long after Clojure was JVM hosted, it was also CLR hosted[2]. One of my first experiences with ML was F#[3], a ML variant that targets the CLR. These all predate the MIT licensed .net, but prior to that there was mono, which was also MIT licensed. 1: https://dotlisp.sourceforge.net/dotlisp.htm https://dotlisp.sourceforge.net/dotlisp.htm 2: https://github.com/clojure/clojure-clr https://github.com/clojure/clojure-clr 3: https://fsharp.org/ https://fsharp.org/
deleted 2y ago
[deleted]
aninteger 2y ago
The lack of a debugger (except for Microsoft's propriety one in VS Code) probably limits the language a bit on open source operating systems.
- bangaladore 2y ago
  What does Rider use? I assume it's not a proprietary MS one? Or did they license it?
  - neonsunset 2y ago
    They use their own in-house implementation. There's an OSS alternative from Samsung https://github.com/Samsung/netcoredbg https://github.com/Samsung/netcoredbg but I haven't heard of anyone using it. In general, the debugger is not intentionally made unavailable but rather the "properietary" one is just the original Visual Studio debugger extracted into a standalone package adapted to cross-platform. Other than that, CoreCLR exposes rich debugger API, and debugger implementations just integrate with it, there are no "private bits" that would make this task insurmountable, there was just not much need to do so so far, and some Linux folks (as evidenced by skimming through other .NET submissions here) tend to have irrational and unsubstantiated hatred towards .NET which hinders otherwise positive community efforts.
    - jen20 2y ago
      > debugger is not intentionally made unavailable > rather the "properietary" one The fact that it is proprietary intentionally makes it unavailable for use outside of Visual Studio and Xamarin Studio - this actually caused debugging to be unavailable in Rider for a while a few years ago before they built their own.
      - neonsunset 2y ago
        This is a strange statement. That said debugger also comes with base C# extension, which is free and debugger aside, MIT, in VS Code on all platforms. Xamarin Studio and VS for Mac are deprecated. Given the confidence of your reply, one would assume you'd know this? Unless it's the exact problem I outlined previously, in which case please consider sharing grievances about something you do use actively instead, rather than what you think are .NET's issues.
breakingcups 2y ago
I remember when Delphi could briefly compile to .NET.
- pjmlp 2y ago
  The guys that worked on that compiler backend keep the tooling alive, naturally it has a different name nowadays. https://www.remobjects.com/elements/oxygene/ https://www.remobjects.com/elements/oxygene/
bj-rn 2y ago
Idk if it counts but there is VL, a node based visual programming language for .NET. https://visualprogramming.net https://visualprogramming.net https://thegraybook.vvvv.org/reference/getting-started/dotnet/introduction-for-dotnet-programmers.html https://thegraybook.vvvv.org/reference/getting-started/dotne...

pjmlp 2y ago

That is why CLR used to mean Common Language Runtime, and there were so many languages on the launch event and .NET SDK bundled on computer magazines back in 2001. Then the Windows only focus (for a while there was Rotor), and Microsoft being Microsoft, all that interest faded away and people focused on the JVM, even though MSIL was designed for all kind of languages (well dynamic came later with Iron languages and DLR), including C and C++. Nowadays CLR almost feels to have changed into C# Language Runtime, given the C# centric decision on modern .NET design.

neonsunset 2y ago
While "C# Language Runtime" as a joke term certainly exists, most runtime improvements benefit all languages that target it, individual changes would have different impact on different languages but that's expected. It is likely further devirt and escape analysis work will have greater impact on F# for example.
- pjmlp 2y ago
  As mentioned, I am waiting for .NET 9 final release notes in November. Also a solution for code generators, analysers, interceptors usage in .NET libraries and how to consume them from F#, some day, if ever.
- debugnik 2y ago
  > most runtime improvements benefit all languages that target it And most CIL ABI additions to the CLR driven by C# totally break them, because the C# ecosystem adopts them immediately (recently even breaking changes in the shared framework!), and there's no modern equivalent to the Common Language Specification. Plus, no library writer would care if there was a CLS 2.0 because every CLR language other than C# and F# is in maintenance mode or simply abandoned.
aninteger 2y ago
> Nowadays CLR almost feels to have changed into C# Language Runtime, given the C# centric decision on modern .NET design. Definitely! VB.Net is basically "dead" and F# will never really reach critical mass.
- jjtheblunt 2y ago
  F# features creep slowly into C#, though, I feel. (as those of Scala would creep into Java at a delay)

neonsunset 2y ago

Historical precedent and anti-.NET bias - CLI/CIL is a much more powerful and flexible bytecode target than JVM, but it is also not as well-documented with fewer guest languages and, as a result, community know-how. With that said, it really is a breath of fresh air to see projects like this one, alongside ongoing work on F#, the main "other" language of .NET, and a couple small toy-like languages like Draco. There are also IKVM and ClojureCLR/ClojureCLR.Next.

layer8 2y ago

Microsoft didn’t manage to have Visual Basic target .NET without turning its semantics into C# with different syntax, so this will be interesting to see.

moomin 2y ago
Anyone remember J#?
- danielovichdk 2y ago
  IronRuby?
- giancarlostoro 2y ago
  That was a in-between for J++ their Java hard fork.
pjmlp 2y ago
Yes it did, the complaints were mostly from VB 6 folks complaining about VB.NET 1.0, several VB features like Me objects, being again more dynamic, repl, were eventually added back for those that kept around in VB.NET land. Not that it matter much nowadays, given that its development has been placed on freeze mode.

aidenn0 2y ago

Before Rich made Clojure for the JVM, he wrote dotLisp[1] for the CLR. Not long after Clojure was JVM hosted, it was also CLR hosted[2]. One of my first experiences with ML was F#[3], a ML variant that targets the CLR. These all predate the MIT licensed .net, but prior to that there was mono, which was also MIT licensed. 1: https://dotlisp.sourceforge.net/dotlisp.htm https://dotlisp.sourceforge.net/dotlisp.htm 2: https://github.com/clojure/clojure-clr https://github.com/clojure/clojure-clr 3: https://fsharp.org/ https://fsharp.org/

deleted 2y ago

[deleted]

aninteger 2y ago

The lack of a debugger (except for Microsoft's propriety one in VS Code) probably limits the language a bit on open source operating systems.

bangaladore 2y ago
What does Rider use? I assume it's not a proprietary MS one? Or did they license it?
- neonsunset 2y ago
  They use their own in-house implementation. There's an OSS alternative from Samsung https://github.com/Samsung/netcoredbg https://github.com/Samsung/netcoredbg but I haven't heard of anyone using it. In general, the debugger is not intentionally made unavailable but rather the "properietary" one is just the original Visual Studio debugger extracted into a standalone package adapted to cross-platform. Other than that, CoreCLR exposes rich debugger API, and debugger implementations just integrate with it, there are no "private bits" that would make this task insurmountable, there was just not much need to do so so far, and some Linux folks (as evidenced by skimming through other .NET submissions here) tend to have irrational and unsubstantiated hatred towards .NET which hinders otherwise positive community efforts.
  - jen20 2y ago
    > debugger is not intentionally made unavailable > rather the "properietary" one The fact that it is proprietary intentionally makes it unavailable for use outside of Visual Studio and Xamarin Studio - this actually caused debugging to be unavailable in Rider for a while a few years ago before they built their own.
    - neonsunset 2y ago
      This is a strange statement. That said debugger also comes with base C# extension, which is free and debugger aside, MIT, in VS Code on all platforms. Xamarin Studio and VS for Mac are deprecated. Given the confidence of your reply, one would assume you'd know this? Unless it's the exact problem I outlined previously, in which case please consider sharing grievances about something you do use actively instead, rather than what you think are .NET's issues.

breakingcups 2y ago

I remember when Delphi could briefly compile to .NET.

pjmlp 2y ago
The guys that worked on that compiler backend keep the tooling alive, naturally it has a different name nowadays. https://www.remobjects.com/elements/oxygene/ https://www.remobjects.com/elements/oxygene/

bj-rn 2y ago

Idk if it counts but there is VL, a node based visual programming language for .NET. https://visualprogramming.net https://visualprogramming.net https://thegraybook.vvvv.org/reference/getting-started/dotnet/introduction-for-dotnet-programmers.html https://thegraybook.vvvv.org/reference/getting-started/dotne...