Kotlin native vs Rust


#1

Did any one tried both languages, if so, what are your observations/comments that can be used to define pros and cons for each one comparing with the other.


#2

Discalimer: I have a little bit experience with Rust, solid experience with Kotlin, no experience with Kotlin Native, but I have some thoughts :wink:

I think the main difference is that you have much more control what the computer actually does in Rust. It is harder to learn and use Rust, but you can squeeze out the last bit of efficiency. Another difference I see is that Kotlin Native is relatively new and immature whereas Rust already has matured a bit (although it is also new compared to it’s main competitor C++). The Rust ecosystem is probably a lot bigger. Kotlin uses garbage collection at runtime whereas Rust checks memory management at compile time. Rust is cleaner in some aspects, because compatibility with the Java legacy (null, abstract class/interface with default methods) was not a design restriction. From a programmers point of view Rust is more functional and less object oriented, you can see this in error handling, pattern matching and the absence of null and classes.


#3

The main difference is memory management system. In Rust memory management is done mostly in compile time. On one hand, it allows to make programs with much smaller memory consumption, on the other hand, it complicated development a lot. Rust and K/N use LLVM as a backend so performance should be more or less the same. The language syntax (excluding borrowing) is similar.

Rust is much older than kotlin, but it did not manage to step outside its initial development niche (web-browser and other memory-critical system applications).I think, that for those you should use Rust. For non-system applications, kotlin has better potential.


#4

From the point of view of a systems programmer, it didn’t complicate development - it picked up a lot of the burden of doing concurrent shared memory programming without shooting yourself in the foot. This is described in detail in Fearless Concurrency with Rust, and it goes straight to Rust’s design goals.


#5

Exactly. Any memory management is better than C/++. Rust has an elegant solution which does not involve additional costs, but from the point of view of application developer any memory management complicates things. Application developer just do not need to think about it. Also in Rust you must think Rust. Borrowing requires a set of patterns which would not exist otherwise.

So for system programmer Rust is a good choice. For anything else, maybe not.


#6

Currently I am working on a GTK+/GStreamer desktop client program. Initially in C++ then I switched to D – D is a much nicer programming language than C++ and the GTK and GStreamer bindings are better. Then the GStreamer people decided Rust was the language of future working so I switched to Rust. Very different to C++, and better. D and Rust are just very different, both have pluses and minuses. The Rust bindings to GTK and GStreamer are good, and they have some futures/channels/executor extensions that make event loop programming nice.

When I look for GTK and GStreamer binding for Kotlin/Native there isn’t anything that gets close to what is available in D and Rust. So no matter how nice the Kotlin language is, Kotlin/Native cannot currently compete with D or Rust in the GTK and GStreamer applications arena.


#7

I’ve just started writing a tool to generate language bindings for libraries which support gobject-introspection, because I think this is really needed. I’ve also tried Rust, and didn’t like it. My main goal is Kotlin Native, which is a better fit than JVM in several ways, but I’m starting with the JVM (using JNA) as a prototype/proof of concept because of Native still being kind of beta-ish with no good support in free editors. I’m hoping a free IntelliJ plugin for Native will appear as part of the multiplatform model.


#8

The Rust gir tool https://github.com/gtk-rs/gir and the D gir-to-d tool https://github.com/gtkd-developers/gir-to-d do a great job of creating GTK+ and GStreamer bindings. The GStreamer community are likely to settle on Rust as the replacement for C it seems. I am not sure what the GTK+ people will do but gtk-rs works nicely as does gstreamer-rs. Having said that I actually prefer D over Rust, and GtkD has excellent bindings to GTK+ and GStreamer.

If Kotlin/Native had a Kotlin binding to GTK+ and GStreamer (rather than just using the C API directly) this would be a Very Good Thing™.


#9

There also is java-gnome: https://github.com/afcowie/java-gnome/tree/master/src/generator


#10

I hadn’t seen java-gnome, but I looked at JGIR. Both look unmaintained; although Java’s fairly stable I guess it’s had some useful new features since those projects were last updated, and certainly the G* libraries will have changed a lot.

I don’t know about java-gnome, but JGIR doesn’t allow you to override a GObject C method in Java, at least not in a straightforward way. I thiink I can achieve that.

Another reason for writing JVM bindings in Kotlin instead of Java is that g-i has nullable tags, it would be a shame not to take advantage of them.


#11

Java-gnome uses same .defs files as gtkmm, you can download fresh ones and regenerate, link above points to generator.


#12

The problem there is that the gtkmm binding is hand crafted, it is not generated from the GIR files – as far as I know.


#13

If you are interested in Kotlin/Native because of performance, you really should choose something else. Kotlin/Native is native not for performance. It is for situations, where you can’t afford a JVM (like an iOS app) and want to share logic between platforms, or just write clean readable code. Kotlin/JVM is faster than K/N, and Rust is faster than both.