KotNet or anything to do with .Net is mentioned in that single sentence that you quoted. There doesn’t seem to be any kind of public repository or branch on the main kotlin repository and I couldn’t find any mention to it anywhere else.
What I’m trying to say is that I wouldn’t take this to seriously right now. Sure if they publish some more information about this(additional blogpost, link to the repository, etc), maybe it’s something to take serious, but right now it’s a small hackathon project that did not warrant more than a single sentence in a blog-post about the most interesting results of that hackathon.
4 Likes
Yeah, the CLR compiler should be at least as complex as JVM compiler, and this one took few years to make. So not anytime soon. But the idea of the default language lives on, which is great.
6 Likes
There is a goal to make kotlin a ‘default language’.
To meet this requirement, programmers need Kotlin to be a choice when programming on the CLR. No essential that C# programmers switch, more essential that programmers do not need to become C# programmers to solve that problem.
I think the area stalling the growth of Kotlin right now is Cross-platform. Kotlin has multi-platform in beta, and with that in production, and availability of cross-platform libraries built using multi-platform, Kotlin can be compelling for cross-platform applications. Right now, it you want cross-platform, Dart with the cross-platform flutter libraries is the goto solution.
C# is necessary to complete the mission, but probably takes a back seat to multi-platform and getting libraries like flutter up and available on multiple platforms for now.
8 Likes
It seems to me that creating a Kotlin compiler for .NET is a different thing than making Kotlin more cross-platform.
Talking about making Kotlin more cross-platform, you already can run Kotlin on devices where you can run .NET application. You just install JVM to do it. This JVM dependency is hardly a big enough problem to create a new compiler.
The motivation for a new compiler might be enabling developers to integrate Kotlin with .NET code, like using .NET libraries in Kotlin code or writing .NET libraries in Kotlin. But, again, whould this motivation be enough, considering we have C# for such tasks?
Now about the motivation that you wrote about. You wanted to use Kotlin to “write once, run everywhere”.
If your product is an application, then, as I wrote before, you already can do it. There are JVM implementations for all platforms that you would want to target.
If you product is a library and you want it to be available for both JVM and .NET projects, then what about dependencies? You would still need two separate code bases. One would use libraries you have for JVM and the other would use .NET ones.
Indeed, you could still use this Kotlin to .NET compiler to create a library, used by both of the codebases. This library wouldn’t have any 3rd party dependencies, probably implementing some business logic aspects, domain model objects, etc.
This particular motivation, though it makes sense, is kind of… limited, niche.
And, the last kind of motivation that I can think about is enabling Kotling developers to write for .NET without having to learn a new language. And here we have the same concerns as with the previous one. The developers wouldn’t need to learn a new language, but they would need to learn new libraries.
And one more thing. I’m not sure that using a .NET library in a Kotlin code would be straight forward. Yes, you would be able to compile both C# and Kotlin to .NET byte code. But would you be able to port the API of a .NET library written in C# to Kotlin API?
And, the other way around, would you be able to always create a C# API for a .NET library written in Kotlin? Not sure about that. There might be problems here.
I think you’ve missed the point. The reason for Kotlin to run on .NET is not so that you can run your code on more devices, it is so that you can create components that interoperate with other components of the .NET eco-system. For example it would allow you to create a component like an XML parser that works both in the Java and the C# world.
2 Likes
Although I am not a .net programmer, I want kotlin to be more generic and popular,.So I support it. In addition, Java is gradually becoming less popular, C# is the opposite, maybe kotlin will develop better through .net
2 Likes
No, I wrote about such components as well. The problem with them is that they wouldn’t be able to use ordinary JVM or .NET dependencies. Though, they could use libraries that are themselves components of the same type, having a dedicated binary for each of the platforms all binaries with the same Kotlin API.
This dependency limitation is ofc something that technically can be countered. Say, by enabling a portable component to have some parts of it written “natively” in two variants: for JVM and .NET. A similar way as JREs are shipped with different implementations of some APIs depending on the target OS.
Or the dependency limitation might be solved if there would be a way to port binaries between platforms (in the both directions), plus some way to port all possible C# API to Kotlin. The both might be doable, I’m not sure. But, something tells me that would be a lot of effort.
The Kotlin blurb says “Kotlin Multiplatform is also useful for library authors. You can create a multiplatform library with common code and its platform-specific implementations for JVM, JS, and Native platforms. Once published, a multiplatform library can be used in other cross-platform projects as a dependency.” Yes, there are challenges in managing the differences between platforms. But if it can be done across the JVM, JS, and Native platforms, then surely it can also be done for .NET?
(Incidentally, I’m not waiting for this feature. We solved the problem a different way, by writing a Java-to-C# transpiler. That also had to manage dependencies, of course, but only the dependencies actually used in our code, which is much easier than the general problem.)
1 Like
I’m one of those library authors 
We plan to develop the new version of our SDK in a write-once & use everywhere way. Kotlin seems to be the perfect option for the platforms it supports. But, we also need to support C# (for our S2S flows) and Unity (for our game clients). So, I would be more than happy to see Kotlin working with .NET and creating .NET dlls as well.
2 Likes
Bike-shedding for my first post here, so here’s my 2 cents…
There once was a Scala compiler for .NET. It didn’t work, because targetting a new backend takes a lot of resources, and because the CLR is less flexible.
Turns out Java’s type erasure for generics is a boon for alternative languages. For example, Scala has higher-kinded types, but HKTs are currently not supported by the .NET runtime, and they need to be, as the .NET runtime does reification.
So on top of .NET, if you develop a language like Scala, you can choose to do your own type erasure, and thus have your generics not interoperate well with .NET’s generics. Also, you take a performance hit, because .NET’s runtime isn’t as smart as the JVM — I mean, the JVM may not do specialization for value types, but it tries doing escape analysis, and it has pretty good GCs lately. Without specialization of value types, you may end up with surprinsingly bad performance on top of .NET.
Or, you can go the way of F#, and introduce .NET’s generics with reification in the language, but then that pins you to what .NET supports. And Kotlin may not be as expressive as Scala, but I’m pretty sure it doesn’t want to be limited by what .NET supports, and we can probably spot differences in the current behaviour, at least when it comes to variance and such. Otherwise, for extra stuff, you introduce your own special DSL (e.g., F#'s inline functions), and hope that C# .NET doesn’t duplicate that functionality (e.g., interfaces with static abstract methods), as it will leave you in the awkward position of multiple ways of doing things.
Scala has a more expressive type system than Kotlin, of course. But it’s not the only sample in town. Clojure is another example whose .NET version did not go so well. Dynamic typing and the CLR don’t blend well, languages like Clojure taking a performance hit. That, plus there’s a complete lack of interest for alternative languages in the .NET community. At least, anything that doesn’t come from Microsoft has slim chances of generating interest.
It’s interesting that the JVM and JavaScript’s V8 (which is also inspired by the JVM), due to the immense pressure to keep backwards compatibility in the language, pushed most new development in the runtime, making it very flexible for alternative languages. Whereas .NET pushed most new improvements in the C# language. Although to be fair, with .NET Core, this seems to be changing, but even today, it’s being beaten by the pace at which the JVM evolves (e.g., Project Loom, or GraalVM).
In spite of the marketing, .NET has been historically a pretty bad target for alternative languages. It’s not just the capabilities of the runtime, but also small annoyances, like the debugging symbols being hard to generate and use. I remember that back in the day, at least, the files for debugging symbols (the .pdb files) where using a proprietary Windows-only format, so the Mono project had issues in using those files, generating its own symbols (.mdb files). At least they introduced “Portable PDB” in .NET Core, AFAIK.
The only somewhat successful alternatives to C# are F# and PowerShell, and these are still Microsoft languages. The JVM and JavaScript runtimes have fared much, much better, a lot of it boiling down to the Open Source culture around them.
For people wanting portability, a better choice for the future will be to go native, possibly with an interop layer for using .NET resources. This is because Kotlin, as a very client-side language, needs a good iOS story anyway, and if it can pull iOS off, then interoperating with .NET resources shouldn’t be a big issue. And going native doesn’t mean just Kotlin Native. It can also mean using GraalVM’s Native Image, which is pretty awesome, or WebAssembly, at least once languages with GCs receive good support.
5 Likes
Thank you for the detailed reply. I got an idea while reading. Isn’t it possible to interop with CLR using managed C++ bridge? Kotlin/Native should be able to do this.
2 Likes
Hello ya’ll. New maintainer/primary developer of IKVM here.
I’d be interested in providing any sort of assistance you all might need in getting this working.
2 Likes
I am glad to hear that the project is reanimated. Is there a simple way to use IKVM as a drop-in replacement for JRE so people could test their programs?
Yes. We provide a “JDK/JRE image” drop. This is a directory with your classic bin/ and lib/ directory, with bin/java.exe, bin/javac.exe, and all the other tools.
I did try to get Rider and IntelliJ pointing to this, but it complained about it not being a valid JDK. So, I don’t know exactly what it’s looking for. But it works fine for most other tools expecting a JDK: including the OpenJDK test kit.
I can also confirm we have had a few users who attempted to get Kotlin compiled classes working in IKVM in general in the last few months, and it runs fine. With the standard disclaimer that bugs should be reported so we can fix them.
1 Like
I can’t find which version of JRE specification does it implement…
1.8
That has not changed.
I see. I probably will try to make a test project. We moved all our libraries to 11 some time ago.
Understood.
I’ve spent the last year now trying to get IKVM back in shape. Old project, unmaintained for near a decade. Lots to do. Only a handful of contributors. Etc.
JDK9+ stuff is on the roadmap now at least.
3 Likes
Great. Glad to hear it.