I really like your plans of building a native port of Kotlin. But I don’t really get why Jetbrains decided to invest into that. The main use case of Kotlin as I see it is being a better Java, and running Java natively does not seem something that is used a lot. There are already native compilers for java and jvm available, but they don’t seem to be used very much except for smartphones. And Jetbrains seems to be building their own compiler instead of reusing an existing implementation.
Obviously Jetbrains has assessed the potential for a native Kotlin port, so I’m wondering if you could share some of your conclusions. Specifically
Why build your own tools for Kotlin Native instead of taking an existing JVM-bytecode-to-native compiler?
What are your goals with Kotlin Native, what new use cases / market are you trying to address?
On the opposite side of the fence with Kotlin Native. See this initiative as a huge waste of time and resources by the Kotlin team that would be much better spent elsewhere. To take a language native that is high level and turn it into a systems programming language will not end well (eg language fragmentation would occur). Far better to use a systems programming language for anything native (a program that works on the system level).
Instead of wasting resources on Kotlin Native the Kotlin team should instead allocate the resources on something worth while like Kotlin JS (for developing a web front end), or even toward making Kotlin a viable alternative for developing full stack web apps (plenty of compelling use cases there).
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
@gz_k - Different team (called Embedded?) working on embedded development with Kotlin (eg micro controllers, SBCs like the Raspberry Pi, and IoT devices).
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.
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.
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.
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.
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.
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?
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.
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.
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.
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!
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: