Kotlin/Native v0.4 released: Objective-C interop, WebAssembly and more | Hacker News Reader

Kotlin/Native v0.4 released: Objective-C interop, WebAssembly and more

blog.jetbrains.com

84 pointsingve16 comments

Is my understanding correct that IntelliJ IDEA will not have Kotlin/Native support, it will be only part of CLion? https://blog.jetbrains.com/kotlin/2017/11/kotlinnative-ide-s...

Is this because C and C++ is CLion-only?

I'd love to see C&C++ support become part of IntelliJ IDEA bundle ;) Not sure why it hasn't been this way.

JetBrains IDEs are tooled for particular language workflows, but can, to a certain extent accommodate other languages through its plugins, though not as thoroughly as the corresponding IDE. (For example, you can still use the Python plugin in IntelliJ, but PyCharm has far more extensive support.)

CLion is the product targeting the CLang family of languages, and therefore that is where, quite reasonably, JetBrains has targeted its Kotlin/Native support.

My trouble with multiple IDEs approach is that most of the projects involve multiple languages and for me it doesn't make sense to start up PyCharm for Python and IDEA for Java. Would feel awkward to keep two IDEs configured to work in sync (both settings, shared code folders) and handle unnecessary RAM and CPU use.

Regarding general workflow, I would also have to make some a mental decision if .txt, .md, .sql, .js belong to my IDEA or PyCharm IDE.

So, unfortunately, for my case, everything goes through IDEA, regardless of having a separate IDEs with more extensive support for Python, Ruby etc :(

This is a really interesting development. I've been poking around with making a cross-platform library lately, and had settled on Go because it does such a great job of building for iOS and Android simply (though the go bind tool), but the implementation feels a little messy because the nature of Go (e.g., no classes, property accessors, etc) doesn't translate easily to Objective-C or Java. So Kotlin might be a really interesting alternative here.

How about Flutter with Dart? It uses AOT so plays well with IOs. But granted, their approaches are very different as Flutter renders most things by itself.

The project I'm working on doesn't use any UI (that's still native), so I'd disregarded Flutter - but perhaps that's not fair. Looking at it, it seems to have straightforward ways to use native functionality, but I'm not 100% sure how I might go about exposing Dart classes/methods/etc to existing native code. Worth looking into, though - thanks!

I guess that now all libraries should be built with the cross platform mindset, including platform abstraction, multitarget testing and avoid leaking interfaces... the compiler and the standard library are just the beginning.

I hope so, but I think it is very unlikely to happen. Bear in mind that the libraries for Android, iOS, Windows, Linux are completely different, so it is not easy to make a wrapper around them. And if you want something to run in different platforms you still have the jre.

Is kotlin native reference counted like swift or do they use some form of garbage collection?

How do they deal with named arguments in Objective—C?

That article mentions "Object pinning", something usually only useful when you have a GC.

See the answer for the 2nd comment:

Memory management is cooperating with Objectve-C runtime memory mgmt, see https://github.com/JetBrains/kotlin-native/blob/master/runti... (function runDeallocationHooks())

> Is kotlin native reference counted like swift or do they use some form of garbage collection?

Reference counting is garbage collection.

I have a mac but can anyone comment in using these tools on windows if this is possible.

All JetBrains IDEs are cross platform (Linux, Mac, Windows). Kotlin Native has support packages for all three for developing to those targets.

https://bintray.com/jetbrains/kotlin-native-dependencies

Kotlin/Native sounds like everything that GCJ was not.

Well, it's definitely true that it's not like GCJ, because it doesn't compile Java code and doesn't support Java libraries. So you can't just take a Kotlin/JVM program and compile it for Kotlin/Native, since the JVM-based libraries it uses won't be available.

But both GCJ and Kotlin/Native compile a high-level, garbage-collected language to native executables, so I suppose they're similar in that sense.

Reply on news.ycombinator.com