Hacker News new | ask | show | jobs
by kodablah 3887 days ago
They have taken steps to separate (most) of the frontend and the backend and will be resuming work on the JS side after 1.0. While I haven't dug into the internals very much, it seems with the concept of "platform types" (i.e. implicitly nullable) and not having anything too JVM-specific, CLR support might be an approachable project for the community. I recommend the community take it and keep it up to date with pre-releases of Kotlin. With ScalaCLR IIRC, when Typesafe decided to stop supporting it it basically withered as new Scala features were rapidly developed.

It also has a better chance than ScalaCLR due to how small the runtime is. But, like Swift with ObjC, since the runtime is so small so many of the libraries are going to targer the JVM and reference JVM libs which may make the cross-VM ecosystem non-existent (doesn't mean it still won't have good CLR uses of course).
2 comments
yole 3887 days ago
Right now developing a new backend for Kotlin is much harder than necessary because the compiler doesn't have any IR and any desugaring passes - in other words, each backend has to work directly with the full AST (annotated with types etc., but still using all language constructs).

We plan to rework this post-1.0, after which building a new backend will be much more feasible.

link
pjmlp 3887 days ago
That is my view as well.

But having platform specific code hidden behind interfaces is way saner than having to write JNI for almost every framework API when using C++ for business logic.

The problem doesn't happen in the other mobile OSes thanks to Objective-C++ and C++/CX. My current approach.

link