There have been a few discussions on this, notably here:
mainly discussing whether or not there is a requirement for Kotlin on .NET.
I’m more interested in a different angle: is it feasible?
In Saxon we have a product written in Java that is increasingly moving onto other platforms (.NET, JS, native) using a variety of technologies, and involving more code forking than we would like. If we could migrate our code to Kotlin and target all those four platforms it would be an enormous step forward. We’re not interested here in whether Kotlin can complete against other .NET-only languages; its unique-selling-point would be multi-platform targeting, and there’s really nothing else that can do that. We’re having to rethink our .NET strategy because of the demise of IKVM, and because IKVM never did and never will support .NET Core.
If we offered to fund the development, with the aim of releasing something as open source, would we find someone interested in doing it? If you think it can be done and you think it’s an interesting project, then let us know and we can talk about it.
I think that in theory it is quite possible. CLR byte code is not so different from JVM and as far as I remember, memory model is also similar. But the main question is how much will it cost. You need to create a new compiler for it. Probably it would be easier to invest in general replacement of IKVM. It would both allow to run kotlin on .NET via bytecode translation and run plain old java programs as well.
I would imagine there’s a lot of information available if you work from source that’s lost if you work from bytecode, so a code-generator backend for CLR could do a better job that generating Java bytecode and then converting. In particular, you could re-target a lot of the commonly-used APIs (such as collection classes and I/O classes) onto .NET equivalents.
You have a point, but still it is a question of price. It would be the same for both cases, but there are much more people, wanting to invest in general JVM to CLR transformer than people wanting only kotlin.
You do not need direct CLR code generation to retarget API. If you have a way to reference those API from platform-declaration (kotlin IR wrappers or whatever), then it does not matter, how actual byte-code transformation goes. Of course, CLR has some features that JVM does not (like reified generics).
I have experience in compilers, code converters and IL bytecode and find such effort interesting. I also believe Kotlin is superior to other languages including C# with Rider in terms of productivity, but also that the .NET platform is far better than the JVM one (bytecode, API design, and optimization), specially while project Valhalla is taking that long.
Some OSS projects covering these areas I created in the past:
Isn’t there a problem with the license for java standard library or something which you can’t avoid when you have any jvm bytecode you want to transform? I thought that was one of the reasons why k/n doesn’t support jvm-libs. Why would this be different with a JVM to CLR transformer?
After looking into it again I can’t really find anything. Maybe I just imagined it. I mean there was this big lawsuit between Google and Oracle, but that went in favor of creating custom versions of the jvm. And I thought that JetBrains decided to not create a jvm transpiler for some legal reason, but I can’t find anything about it anywhere. So I guess just ignore my earlier comment
As far as I can tell, Kotlin common runtime could be implemented easily with .NET API (kotlin package), and then you can just use .NET APIs from Kotlin, no Oracle’s API or Bytecode involved at all in that process.
If Kotlin can do to C# what it did for Java that would be amazing. It would make using Unity3D so much nicer. Plus you could easily port your game logic to run server side on the JVM.
The biggest issues I see from a users perspective would be surfacing and interfacing with C# struts.
I think this merits a lot of discussion. With the work that’s been done in the past year approaching 1.4, making the Kotlin compiler much more language-independent, I think this is a feasible and very promising idea.
I’d assert that a lot of the pushback the thread from three years ago faced has since been resolved.
I would love to see this as well. The CLR is a better VM and the ecosystem on the CLR is richer now than it is on the Java side IMO.
Kotlin code would not be write once run on either JVM or CLR though, at least not trivially. Kotlin data structures have java data structure semantics, which in turn are different in the CLR. They could be wrapped with a thicker layer to hide the difference though.
I would be happy to devote time to help such a project along.
I think this is one of the main reasons that this has not been attempted yet. Maybe the kotlin team will have time for this once the compiler rewrite is done (1.5) but I wouldn’t get my hope up. Also I don’t think this will be a priority.
The other reason why I don’t see this being done in the near future is that I don’t think many people will switch from C# to kotlin. While kotlin may be the better language for a new project it will doubtlessly take quite some time for kotlin interop with C# to be as good as it is with java and I don’t see any people switching before that. Also C# is quite a bit more popular than Java so the number of people that want to switch is likely to be lower.
I don’t disagree that C# has a lot of momentum, however it is arguably nearly as “tired” as Java. I loved coding in F#, though was probably too esoteric for the broader developer community.
I currently use Kotlin on the JVM. Very frustrated with lack of good numerical libraries, lack of value types, poor interfacing to native libraries (as compared to .NET), lack of easy “unsafe” code decoration to extract C level performance in places, etc. The CLR environment in retrospect is a better environment for numerical work than the JVM, however lacks the likes of Kotlin.
The question is whether the popularity of Kotlin is because it is a “better java” for the JVM, where Scala has failed or whether it is due to the language itself. The merits of the language are substantial, but am sure much of the adoption is due to frustration with Java, tie-in with Andriod, etc.
Could you please elaborate about numerical libraries in a different thread? I am not very familiar with C# ecosystem, but some time ago, when we were deciding about what platform to stick with, we made a completely opposite conclusion: .NET lacked good scientific libraries, whereas Java had a lot of them. Could you explain, what features do you need?
The .NET ecosystem has improved greatly since 2001 and at this point surpassed what is available on the JVM side re: numerical libraries. There are ton’s of numerical libraries for Java, though a large % abandoned at some point. That said there are maintained Java libraries for the fundamentals.
The lack of value types, the high-latency native API, and inability to do “unsafe” in a practical manner are the reasons why the JVM is poorly suited for numerical work.
For the moment my numerical needs have been met either with a Java library (for very fundamental stuff: for example ejml) or by implementing specific numerical algorithms I need where cannot find either a library or a robust implementation. But I should note that the likes of ejml are siginificantly slower than .NET counterparts which either use “unsafe” or have the ability to swap out with a BLAS backend at almost 0 cost. And if I need to evaluate in the complex space, no value type I can use on the JVM …
Could you please create a separate topic here or a thread in kotlin slack channel for #mathematics? It would really benefit kotlin scientific community if you explain what is needed and what use-cases do you have. We are developing a lot of things and we need to prioritize. I’ve been doing numerically intensive tasks in JVM ecosystem for many years and I’ve almost never felt problems with that.
EJML is indeed a little bit obsolete, but there are very fast implementations in ojalgo libraries. Kmath features complex number implementation which is pretty fast with native interface, but I never had a task to test it.
+1 for adding an MSIL/.NET/whatever target now that there’s a Kotlin IR.
I’m hoping the Java interop in .NET 5 will be able to load Kotlin/JVM libraries, we may get a small glimpse of what code brevity looks like. I work on an OSS C# project and I all too often find myself typing when () or .also {}, getting red squiggles, and then being sad.
