Why Kotlin Native?

I think it’s a new team that work on kotlin-native. It should not affect too much the pace on kotlin.

I see plenty of good things with kotlin-native:

  • ios: developing apps with the same code for android and iphone ++
  • small hardware (iot, …) with kotlin.
10 Likes

This ^

Desktop, Android, iOS with just 1 single code base is huge!

And let’s be honest, Kotlin is a really nice and beautiful language, when i look at languages like Go and Rust with their ugly syntax, i’m glad i’ll finaly be able to use a native language with a beautiful / easy to understand syntax

3 Likes

@gz_k - Different team (called Embedded?) working on embedded development with Kotlin (eg micro controllers, SBCs like the Raspberry Pi, and IoT devices).

3 Likes

@abreslav talked about it here : Stream episode A Chat with Andrey Breslav by Talking Kotlin podcast | Listen online for free on SoundCloud

He mentions a completed hired team that rocks ;-).

2 Likes

It may slightly oftopic but could some one explain what is the key benefits of Kotlin Native in comparison with Kotlin + JVM + JIT? I guess potentially lower footprint, as for performance, JVM is might be the most perfect virtual machine due to its long & hard evolution (on benchmarkgames it cits not far from C/C++ by performance).

As for me it would be great to have Kotlin faster, “smaller” and on embedded devices as a native citizen also.

It’s already possible to write for those 3 with Kotlin although for desktop you are stuck with Java UI components (e.g. Java Fx) instead of native UI components.

Intel created the Multi-OS engine (https://multi-os-engine.org) that basically lets you write for iOS with Java and thus also with Kotlin. Here are some sample apps using Kotlin with MOE: GitHub - multi-os-engine/moe-samples-kotlin: Multi-OS Engine: Kotlin Samples.

It is of course also possible to write for those and more with C# (or any CLR language) using Xamarin, but Kotlin is a better language, which is why I advocated in another thread for Kotlin on the CLR instead of native.

2 Likes

Not sure who you mean by “you”, but I know JB is focused on native instead. I certainly have no plans for it, I just advocated for doing a CLR version since it should be pretty easy.

I am going to look into ikvm myself.

1 Like

@scellow - As @dalewking has mentioned in this thread you can already cover Desktop (via TornadoFX and JavaFX), Android (via Kotlin Android Extensions and Android SDK/Android Studio) and iOS development (via Multi OS Engine) with Kotlin. Exactly what benefits does Kotlin Native bring that is worthwhile?

Remember that JetBrains has presumably made a HUGE investment into Kotlin Native. JetBrains will be expecting a huge ROI for the resources (man power, money, computers, time etc) that they are investing into the project. VERY HIGH stakes are involved. The gains NEED to be significantly higher to justify the means!

JetBrains could have a compelling case with Kotlin in the embedded development area, however that is a BIG if! Besides discussions on Kotlin in embedded development need to be done on a separate thread.

Embedded is the only case I can see. But I really don’t see a big movement when most embedded is still C or C++. As a former embedded developer, I have often wondered why C# did not become the replacement for C++ in the embedded space. The failure of C# to take over embedded development doesn’t give me a lot of confidence that Kotlin will fare any better.

1 Like

Hopefully in few months there will be EAP release of Kotlin Native, and it will likely get most of your questions answered. However, few points:

  • Kotlin is not “better Java”, Kotlin is a nice and powerful programming language on its own, and most issues topicstarter had seems to come from this original misunderstanding
  • producing reasonably-sized self-contained binaries without need of heavyweight runtime is rather frequent problem
  • “compiled to machine code” isn’t same concept as “system level software”, in history of computers we had Golden Age of both VMs and compiled code, and here at Jetbrains we would like to provide both options to developers (for example, almost all software in Apple devices is compiled to machine code)
  • remember, we’re tooling company, and as such - we do provide people with better tools to do their job, and there are places (embedded, iOS, IOT) where native compilation is just better fit.

Hopefully, it will give you somewhat better insight on what and why we are doing.

17 Likes

Is it too early to ask how memory will be managed in Kotlin Native? I mean plain manually, ARC, GC, Rust-style? When not running on the JVM there are also not the limitations of the JVM. That is Kotlin Native doesn’t need to inherit the limitations Kotlin inherits from the JVM. So, is Kotlin Native exactly the same thing as Kotlin or will it excel beyond?

4 Likes

Sure Kotlin is more than only a Better Java, but replacing Java & being Java compatible were the main reasons for why Jetbrains started it and has motivated many of the language design decisions, and I expect the Java compatibility will also be a very important reason for adoption in the future.

I gather from your answer that Jetbrains is mainly trying to target the embedded/lower spec’d computing devices market with Kotlin.

1 Like

Just my 2 cents, but I think existing Kotlin problems should be fixed before adding more compiler backends. Quality before quantity, and all that jazz.

2 Likes

@JanKanis - Look at this post for more insight into what target platforms/markets JetBrains might be targeting with Kotlin Native.

Following the same logic, we should have fixed existing IntelliJ IDEA problems before starting the work on ReSharper, RubyMine or Kotlin - and because there are always existing IntelliJ IDEA problems, these projects would never have started.

To reiterate, a separate team works on Kotlin Native; none of the resources of the existing Kotlin team were diverted to that project.

6 Likes

I’m a perfectionist, I appreciate that’s not always (or even often) practical in the real world. Nevertheless, I think there’s something to be said for structuring work such that most issue can be ironed out before launching in other ventures. It forces you to simplify.

Anyhow, don’t let my barb lower morale. I’m certainly excited for Kotlin Native!

1 Like

I’m also a little skeptical, but as JetBrains had a hiring opportunity that meant native vs Java vs JavaScript wasn’t zero-sum, that does eliminate the worries over the existing userbase being deprioritised.

The big looming problems I can see now, without any obvious solutions:

  • Yes in some senses Kotlin is not just a better Java, but Kotlin’s standard library is basically Java’s standard library + some thin extensions, so in other senses it is. All existing Kotlin code is full of import java.stuff, and I’m guessing 95%+ also imports open source Java libraries. Kotlin Native could perhaps reimplement some of the Java standard library, but out of the box, if you grab some arbitrary Kotlin code it isn’t going to run on Kotlin Native unless there’s an AOT Java compiler included. Same is true for Kotlin JS of course but the limited browser environment means people expect an anemic standard library anyway.
  • “Native” often implies “no GC”, especially in the embedded realm. All existing Kotlin code expects GC to be present. Perhaps Kotlin Native will still be a GCd language. If it’s not, then at that point without a GC and without the Java standard library, they’ll basically be two separate languages.

So it’ll be interesting to see what design decisions JB makes here.

By the way, just as a reminder, you can combine Kotlin and “small standalone native binaries” today. Look at the Avian examples:

https://readytalk.github.io/avian/

One of the projects I keep trying to find time for is a tool to make creating such binaries brain-dead simple.

1 Like

I would be really surprised if they’d come out with a Kotlin native compiler that doesn’t also compile Java. That would just split the ecosystem for no reason, especially as Java is basically a subset of Kotlin in semantics. I wouldn’t be surprised if it will just take class files as input. Andrey already said they were going to implement a GC.

My interpretation of what Jetbrains people have said about Kotlin Native is that they think IoT/embedded is going to grow a lot in the future, which is probably true. These devices are getting plentiful and powerful enough that bare metal languages (C/C++/D/Rust) aren’t a necessity anymore and higher level languages make sense, but not powerful enough to run a full JVM. There aren’t many well known languages in this space of high level + native compiled. What I can think of there’d be Go, Java with existing AOT compilers, or native compiled .Net, and Go is still a much smaller ecosystem than the other two. I think Jetbrains thinks they can create a good enough alternative with Kotlin Native to have an impact. I’m not very familiar with the state of existing Java AOT compilers, but I wouldn’t be too surprised if Jetbrains thinks that existing tools are not good enough and it will be easier to create a new compiler based on LLVM. And a Java-ecosystem based language would be uniquely suited for that since it is the only major ecosystem that is mostly self contained, in the sense that it is very rare for Java apps and libraries to have mandatory dependencies on native libraries. Which is unlike the .Net, Go, and any other open source language ecosystem.

A Kotlin Native offering would offer the same selling points as Kotlin/JVM but for the IoT and embedded market. I.e. a language that is very easy to learn for lots of developers and a familiar environment with a huge library ecosystem. Splitting the Kotlin ecosystem by not compiling Java libs would be a bit nonsensical, since then you would just have a new language and a new ecosystem with few libraries, which is not a very attractive proposition to a prospecting IoT developer.

The only thing I’m missing is how exactly Jetbrains plans to profit from this. Selling more tools to IoT devs is nice, but maybe they’re also planning to be an IoT or Kotlin consulting company or something like that.

2 Likes

I agree with @JanKanis, and disagree with my teammates from JetBrains that we need to compile Kotlin directly to LLVM. Unfortunately, I could not push my opinion to my teammates, so it remains my personal opinion.

Kotlin is an awesome languages for JVM, created WRT good interop with Java and with tons of Java libraries. Indeed, there are some disadvantages in JVM, at least, in OpenJDK, like large runtime size, JIT (as opposed to AOT) which can be inacceptable in some cases, unpredictable GC pauses, etc. That does not mean, however, that we should compile Kotlin ourselves directly to LLVM. This means that we need more appropriate JVM implementation. There are some, like RoboVM, MOE, etc. We can pick one and contribute our code there. We can even invent our own JVM AOT, it’s not that hard, at least comparing to Kotlin Native which has to implement semantics which is close to JVM. I see some advantages there:

  • We don’t have to do large amout of work, we can easily start with what we have and then make things better.
  • We could get a good adoption from people who have experience with Java and a little unsure to start using Kotlin. With JVM AOT approach they could write most of their code in Java and start to write some of the code in Kotlin (and fall in love with it). With current approach these people either refuse to port their app to iOS at all or discover and use MOE.

Let me tell about some myths about “ugly monstrous JVM”

  1. JDK is not necessary large. It is, but we can cut only parts necessary for embedded/AOT/iOS/games/whatever else, and it can be small enough. We can even use minifier like proguard or write our own one, which is capable of eliminating unused classes and methods.
  2. JVM is not necessarily JIT. We can sacrifice some ClassLoader features to have chance of creating pure AOT. AFAIK, RoboVM does not support class loaders, and it’s not a big limitation for iOS and embedded development.
  3. JVM implementation is not tied to GC, any automatic memory management mechanism is acceptable, including ARC, region-based memory management, etc.
  4. JVM is heavyweight. JVM bytecode consists of very simple instructions that remind of assembler. Full spec describes about 200 instruction versus x86 architecture which has thousands of instructions. Most of instructions are like iadd, fadd, isub, fsub, etc, which are trivially mapped to LLVM IR.
  5. GC does not necessarily produces unpredictable pauses, there are GC scheduling algorithms that give strong guarantees of upper limit of time spent in GC.
5 Likes