3 ms·

Yeah this seams to me like a repudiation of the whole idea of .NET, as a multi-language system. They may add support for F# later, but by that time, the damage

by sixbrx 11y ago

Yeah this seams to me like a repudiation of the whole idea of .NET, as a multi-language system. They may add support for F# later, but by that time, the damage will have been done because the message is clear: "use anything other than C# or VB at your own peril". Currently F# is completely shut out - it can't even be used to make libraries to be included in these kinds of apps! That makes it more dangerous career-wise to use F# going forward, lest your team get wedged into a position of having to rewrite one of your libraries because of your choice of using your "pet" language. Not good for the career. The whole point of bytecode is to make things like this language independent. Big failure of vision to let this group do such a hack, IMO.

kevingadd 11y ago
This is most likely just an artifact of F# producing unusual IL that's harder to handle. In my experience, it's less 'we only support C#' and more 'compilers other than C#/VB.net produce very strange IL that is hard to handle well' - which is true. Given the small # of users that rely on those weird compilers, it's hard to justify supporting them first, especially if they aren't performance-sensitive.
- MichaelGG 11y ago
  I emailed the .NET Native team asking them about this. They confirmed that they reverse out IL to higher-level constructs. So they aren't really working at the IL level, they're working on C# represented as IL. This isn't entirely uncommon. A lot of code that deals with Expression<T> does so very poorly and won't work on many valid trees because they weren't able to get C# to emit certain expressions.
MichaelGG 11y ago
Yep, it's incredibly disappointing. The CLR model is rich enough that MS Office can be compiled entirely to MSIL and run fine. The F# folks had to drag Microsoft kicking and screaming into shipping generics - else the CLR and C# would have probably only gotten the lame Java-esque erasure model. Yet despite being shown up, utterly, entirely, they just sorta stumble forward. They realise there's no serious competitor in the language space - Java's remained terrible. There's no threat to C#, and it's a lot easier to maintain a compiler than a platform. The runtime hasn't seen any change since .NET 2 introduced generics (with driving work from MSR). Since then, they've tweaked perf a bit, but haven't extended the model at all. Until there's a real threat, they continue down this easier path. Swift shows up and demonstrates tuples and matching won't kill average devs, ok C# will probably add those. And honestly they can probably get fairly far just reacting here and there. It is sad though to see the grand idea of the CLR fall this far.

by sixbrx 11y ago

kevingadd 11y ago

This is most likely just an artifact of F# producing unusual IL that's harder to handle. In my experience, it's less 'we only support C#' and more 'compilers other than C#/VB.net produce very strange IL that is hard to handle well' - which is true. Given the small # of users that rely on those weird compilers, it's hard to justify supporting them first, especially if they aren't performance-sensitive.

MichaelGG 11y ago
I emailed the .NET Native team asking them about this. They confirmed that they reverse out IL to higher-level constructs. So they aren't really working at the IL level, they're working on C# represented as IL. This isn't entirely uncommon. A lot of code that deals with Expression<T> does so very poorly and won't work on many valid trees because they weren't able to get C# to emit certain expressions.

MichaelGG 11y ago

Yep, it's incredibly disappointing. The CLR model is rich enough that MS Office can be compiled entirely to MSIL and run fine. The F# folks had to drag Microsoft kicking and screaming into shipping generics - else the CLR and C# would have probably only gotten the lame Java-esque erasure model. Yet despite being shown up, utterly, entirely, they just sorta stumble forward. They realise there's no serious competitor in the language space - Java's remained terrible. There's no threat to C#, and it's a lot easier to maintain a compiler than a platform. The runtime hasn't seen any change since .NET 2 introduced generics (with driving work from MSR). Since then, they've tweaked perf a bit, but haven't extended the model at all. Until there's a real threat, they continue down this easier path. Swift shows up and demonstrates tuples and matching won't kill average devs, ok C# will probably add those. And honestly they can probably get fairly far just reacting here and there. It is sad though to see the grand idea of the CLR fall this far.