Even with Kotlin Native in mind, we have no plans to break Kotlin's backwards compatibility guarantees, and we do plan to support the new JVM features such as value types. So if Kotlin works well as a Java enhancer for you today, it will only work better in that role in the future.

Perhaps the bigger issue here is fragmentation. Here you are, a young language with a lot of promise whose primary appeal is Java interop and whose target market is enterprise Java and already you're dividing your efforts to offer something which your target market will likely have zero interest in. Why not wait until you have real market share in the job market and only then worry about native? Kotlin is a very niche language. That's it's appeal.

One of the niches where it's found a lot of popularity is Android development, which naturally leads developers to thinking about sharing code with the iOS version of their app. This is where Kotlin Native fits in, I think.

Also (just dreaming here) if Kotlin Native were to use some kind of Swift-like reference counting rather than a traditional GC, it could be really nice for interfacing with COM on Windows, where you need to be able to release references to COM objects immediately and possibly in a specific order. In a language with GC, your objects might not be collected soon enough, which leaves the references alive and the process hosting the COM object unable to shut down.

I agree with you about the potential of Kotlin Native. And I, too, would like reference counting, at least as an alternative to GC.

But I think that for really smooth interop with the host platform, it won't be good enough to have just one generic Kotlin Native, that compiles to native code with a cross-platform compiler infrastructure like LLVM. It would be much better to have multiple Kotlin native implementations that integrate well with various host platforms. For example:

* Kotlin for Apple platforms: Every Kotlin object is an ObjC object, and ObjC APIs can be used with minimal glue code in optimized builds. All Kotlin strings are NSStrings and vice versa. Same with collections (NSArray, NSDictionary, and their mutable counterparts); Kotlin's separation of read-only and mutable interfaces is a good match for this platform.

* Kotlin for Universal Windows Platform: UWP, being COM-based, doesn't have a root object type like the Apple platforms. Still, we'll want to be able to call UWP APIs and implement UWP interfaces with minimal runtime glue. And UWP has a reference-counted immutable string type (HSTRING), so all HSTRINGs should be Kotlin strings and vice versa. I don't recall how collections work on UWP.

* Kotlin for classic Win32 + COM: Similar to UWP, but the situation with strings is more complicated. BSTR isn't reference counted, so on this platform, Kotlin would probably need to have its own string implementation, with bridging to and from BSTR for COM interfaces.

.NET and .NET Native work perfectly fine with COM, in spite of having a GC.

Only if you make sure to call Marshal.ReleaseComObject on all your objects, which requires you to hang on to explicit references to all of them, which is not very convenient for many COM APIs, e.g.

   Application.Database.Classes.Item("MyClass").Refresh()

where you would have to save all the intermediate objects in variables just so you can destroy them.

Python works much better with COM, in my experience, because of its more primitive but more predictable reference counting.

I use .NET since pre-alpha days and never used it, RCW and CCW take care of that.

Unless you are talking about manually loading them.

Also, are you aware that UWP and .NET Native are built on COM?

I have run into this problem in two cases:

1. When writing a COM add-in for a host application. When the application wants to shut down, the add-in must release all references to the objects of the host application, otherwise the process doesn't shut down. (At least with the application I'm currently writing an add-in for!)

2. When using out-of-process COM servers such as Excel from another application. This tends to leave lots of "excel.exe" processes running unless you explicitly release everything.

See for example: https://www.add-in-express.com/creating-addins-blog/2013/11/...

Here is Microsoft describing how they ran into this problem when mixing COM and .NET in Visual Studio, how they solved it using Marshal.ReleaseComObject, how that itself caused other problems later when they combined it with CCW, and ... I'm not sure what their ultimate correct solution was:

https://blogs.msdn.microsoft.com/vcblog/2006/09/19/mixing-de...

https://blogs.msdn.microsoft.com/visualstudio/2010/03/01/mar...

I am aware of UWP bringing COM back into fashion again, which is why I'm interested in potentially using Kotlin Native with it. :)

I've run into this kind of problem while implementing a Windows screen reader that needs to use COM-based accessibility APIs, both in-process and out-of-process. I naively chose, some 12 years ago, to use Lua, even for the in-process component. Lua, of course, uses tracing garbage collection, not reference counting.

Thanks for the explanation and links.

I guess the reason for never bumping into it was that all use cases I encountered so far, the controls were in-process and died when the application terminated.

Hold on a second there... I am primarily a Java developer, although I dabble in some functional languages like Erlang, and usually mix some Lua in here and there). I've followed Kotlin for a long time waiting for a clear sign that Kotlin is worth learning after being burned by Scala. With co-routines I feel it's worth it, although I would desperately love being able to compile to native! That for me would be a killer feature. Currently I am learning Rust after dismissing Go for the task (love the simple concurrency, don't like the basicness of the language), and Swift (what a mess, I prefer ObjC!). Although I'll probably keep with Rust anyway because it's too impressive to not, the non-GC nature of Rust isn't important to my use-case, I basically just want a native Java. A native Kotlin would be perfect, as long as I can get high quality Gnome bindings. In fact, the main thing I would want out of a native Kotlin is around the native-code-interopt, and in my case that would be the libraries needed for native Gnome desktop application development.

I suspect some combination of

1) It's hard for a new language to get traction. Lower odds that a new startup! They see so many ruby and python shops adding Go to their stack and want to compete in that space. Kotlin's biggest market seems to be android devs and competing with Go puts them in the datacenter.

2) IDEA's IDEs have a better value proposition to devs working with statically typed languages. Appealing to current Java devs builds the Kotlin ecosystem, but appealing to dynamic language devs expands IDEA's customer base more.

IDEA is pretty awesome with JavaScript too. The best IDE I have seen even for dynamic languages.

Actually Netbeans is also quite good for JS, it is a pity it gets so little love.

Visual Studio code is great for JS and TypeScript btw.

I completely agree.

Kotlin is close to the ideal language for me because it is just Java done right. If they want to go native and can do it without impairing any of the JVM usability, I guess go for it. But I don't see the point behind it. I don't develop native apps so maybe I just don't know enough, but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages.

I feel the same way about the Kotlin compiling to Javascript ability. I write both the frontend and backend of web apps so I theoretically should be the exact target market for Kotlin to Javascript but I have no interest in it. ES6 and/or Typescript work better there and have an entire ecosystem around them. And even if they didn't work for me I'd prefer Dart which targets the frontend first instead of being an extra like Kotlin Javascript.

My advice to Kotlin: Stick with what you do best. Kotlin is on the exact right track on the JVM but I think all these different modes are going to make people more cautious about adopting it in any of them because they'll worry it's a jack of all trades but master of none.

In my eyes going native is nice for the distribution of command line apps (if they are static binaries), but also for avoiding the startup time of the jvm.

>[...] but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages

Not for me. Go's type system is too primitive, and Rust is maybe too low level if you don't need the advantages compared to languages with a GC. So a language like Kotlin with a better type system (than go) fits nicely in between the two (that might change if Rust get's a GC type). Especially since it will probably have (or has already?) better tooling considering that Jetbreains is behind it.

> but also for avoiding the startup time of the jvm.

Funny enough, all commercial JDKs do support AOT compilation to native code, and Oracle is slowly adding support for it as well.

Personally I'm intrigued by Kotlin Native as a replacement for Python and Go tools without requiring the JVM.

I find it's a fundamentally better language than both and so being able to write CLI tools and other smaller stuff in it would be nice while still being able to leverage Kotlin + JVM on the backend would also be nice.

Same - a common language for JVM, JS, Native is both unique and intriguing to me. These are three really big targets. It's not that it would be unique in being a higher level compiled language or a language making Java development more fun to me, but being a common languge for among the most popular targets besides .NET today.

Scala already does that with scala.js (production-ready) and scala-native (don't know if production-ready, probably not since it's only at 0.1 and they want to implement a better GC instead of relying on boehm like now).

Just wanted to point that out in case you didn't know that already.

Fair enough, I might be wrong and there might more of a desire for Kotlin Native than I thought there would be.

Kotlin native sounds great to me! There is a big world outside the bloated JVM!

We've seen 1/10 the memory usage on golang vs java with similar performance, so properly executed there is a big opportunity in the native space.

And the fact that it has a rather small standard library with JVM 6 compatibility means it's very very easy to adopt it into existing Java 6 (Android!) projects.