As a Java and JVM focused developer the openning up of .NET really excites me. First, because .NET is a fantastic framework in and of itself, but also because this hopefully will encourage Oracle to be faster and more competitive with Java features and improvements.
I'm not sure that's fair. Java 7 and 8 have made some great improvements. The release cycle is fairly frequent and it's actually possible to migrate software easily enough unlike the python 2.7->3 standoff.
I know what I am about to say is both heresy and insanity, but maybe we could get a C# implementation that compiles to the JVM?
I mean, yes, C# has been largely open-sourced already. But with the new compiler framework being opened up also it seems imaginable that someone could write a version that spits out Bytecode instead of MSIL.
I have nothing against the JVM, but am not a huge fan of the Java language (and also how the Java libraries have been forced to be developed due to limitations within Java the language).
Yes Java 8 made Java much MUCH better than before, but just because Java 8 is a around doesn't mean all the libraries and other underpinnings got magically updated overnight.
One of the primary problems with this is generics (java/JVM uses type erasure, CLR/C# keeps type information) and value types (CLR/C# has them, JVM does not); That's why you can implement the JVM on the CLR (see IKVM.NET[1]), but not the other way around.
I'm not a vm or compiler expert by any means but Gosu and Ceylon have implemented reified generics on the JVM somehow. It seems possible, but I don't know what the performance impact would be.
Well it's obviously doable — both the JVM and CLR are equivalent to Turing machines, so it follows that they can run the same set of programs. It just, uh, might be non-trivial. :)
The Eclipse IDE plugin works but is pretty slow. I wouldn't use it if I wasn't so used to autocompletion + documentation in my IDE.
The module system can use the central maven repository but it doesn't accept dashes in the name like jackson-core unless you put it in quotes. (Took me a while to figure out).
Taken at face value I think this is misleading - a typical F# generic type will be represented as a normal .NET generic type at the IL level. However, it is true that some types are erased, like unit-of-measure type arguments or types surfaced by type providers.
Type erasure on the CLR is exactly as it is on the JVM. Generics are needed for interop with generic libraries (which aren't used that much beyond collections anyways in core libraries).
Erasure is necessary when the type system is differently expressive from C#, which I beleive F# is.
It would be super difficult to represent value types, generics and the reflection metadata in the JVM without building some kind of giant abstraction layer. MSIL is rich, maybe overly rich. If you get rid of value types and generics from C# you're basically left with ... Java.
Most languages give you enough rope to hang your self with. Scala gives you options to choose brand, width and color from a wide selection. The flexibility of Scala was scary when I started.
Anyone that wants to bring something new to our projects needs to prove what is the business value. If it reasonable, it gets adopted.
So for Scala to be adopted on our projects, customers need to be convinced what is the business value of having their multi-site team learning it, instead of us using their already installed infrastructure.
I can dabble in alternative programming languages on my hobby projects.
Since the CLR was designed to be hosted, I don't see why someone just doesn't make a CLR host that runs in/on the JVM, similar to something like SQL-CLR.
I know you can do this, but it would be a bad idea anyway, to support two different IL's instead of just one..
One way to solve something like this, with much less effort and elegance, would be to make both langs output LLVM IR for instance, and jit the native binary from there..
Thats my point, i cant think in any way something like this would be a good idea, given the ammount of resources needed to do something like this for trivial results that would not payoff the efforts.
There is only one scenario that this would make sense, and its on Android, given it is tied to a jit runtime engine, but then , they could just drop CIL and compile from source in a intermediate their runtime would understand, the same one's java is already using.. so again.. no luck with that effort
