4 ms·

I can't speak about any of the programming language experts you've seen, but: > To implement this feature, the C# language designers had to modify the underlyi

I can't speak about any of the programming language experts you've seen, but: > To implement this feature, the C# language designers had to modify the underlying runtime itself and add special bytecode instructions for the feature I think this argument is misconstrued. This is inherent to the way the CLR was designed. It is not meant to be something that is kept as-is in terms of the bytecode it accepts. It is constantly being improved upon. Most new language features to C#, F#, or other CLR languages mean an update to the CLR if they're related to a new feature in the abstract. While there's an argument to be made on whether this better than a more generic runtime, the point is that requiring a change to the CLR is not a big deal; that's part of their plan.

sreque 10y ago
It should be plain to see that it would be much easier to implement your programming language on top of the CLR or JVM if you didn't need to request new features from Oracle or Microsoft to be added to the runtime. I remember one time someone proposed a patch to the JVM to add tail cail optimization and it was basically rejected or deprioritized into oblivion: http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-October/002017.html http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-October... These VMs are complicated machines and Oracle/Microsoft aren't going to risk modifying them unless it fits their respective agendas.
- tracker1 10y ago
  Which is why I've been very happy to see .Net Core take the path it has... it's been much more open to outside collaboration even if the bulk is done by MS employees.