The Hitchhiker's Guide to Kotlin(nathan-contino.github.io) |
The Hitchhiker's Guide to Kotlin(nathan-contino.github.io) |
Kotlin can now compile to native binaries : https://kotlinlang.org/docs/native-overview.html#sharing-cod...
Kotlin can now compile to Javascript : https://kotlinlang.org/docs/js-overview.html Edit : You can even use React with Kotlin : https://kotlinlang.org/docs/js-get-started.html
Kotlin can now be used for datascience as well (You can run kotlin code in a jupyter notebook) : https://kotlinlang.org/docs/data-science-overview.html#libra...
Hardly any better than just using GraalVM or any other JVM AOT compiler, some of which go back to early 2000's even if only available in commercial JDKs.
The JavaScript compilation target still needs to do some catching up with TypeScript.
Since the project is an interpreter, it's easy to do performance testing between the different platforms. I just write some program in my language, and run it on each implementation.
The results are interesting. The JVM target is consistently 20 times faster than native. Now some of this is because memory allocations are so fast in the JVM, so if your programs does less memory allocations the difference won't be that great. However, if you compile Kotlin to native code, one has to accept that it's much slower.
Another problem with native compilation is that it's quite slow. I wouldn't want to do all my development using native, but rather develop using the JVM and then compile to native for the use cases that need it.
The only time I think that native would make sense is if you absolutely cannot run the JVM for some reason. One such reason would be for embedded (which would have to be ARM, since that's the only embedded architecture that's supported).
Kotlin native has been rocky personally, I'll check back in a year.
Kotlin on Android is a must compared to Java, else you're a fool. Haven't seen any exceptions in the industry.
Kotless is okay, works, but early days.
I've seen decent backends on quarkus and kotlin.
It's a fun language, the couroutine development is pretty nice. Flow is a lot easier than Rxjava.
I'd recommend it to anyone where they'd traditionally use Java or another similar language.
I like Kotlin enough. But I don’t love it. Like Swift (and maybe Python yet), it’s a language that tacks on more stuff every release in interest of grabbing yet another programming model niche. It’s like a Swiss Army knife with a _lot_ of blades and gadgets and tools. It’s like a VC funded start up that throws features at the wall to see what sticks and placates.
I want my languages to be built on simple unifying principles. Kotlin’s principles often seem to be:
- we get rid of boilerplate . . . when ever we can, but not really consistently. Removing boiler plate trumps consistency in code communication
- you have a rising idea over there in your ecosystem? we will add it in ours
- by keeping our documentation very simple (nee spartan), we can claim our language is simple
This year it is coroutines, tomorrow it will be sealed classes, or who knows.
I ended up going back because Java's getting better--var and records help with some of the pain--the tooling is simpler and more reliable, and working with something like Hadoop was significantly harder.
I'm keen on the idea that there would be less code and my app is getting a little creaky and could use a refresh, but does Kotlin make the boring stuff easier? Things like inflating classes from REST json calls, interacting with the SQLite database.
How does it do on the more "exciting" (ahem) parts of Android like Bluetooth? I lean heavily on RxAndroidBLE to cope with the rubbish bluetooth stack and I think the code around that could do with being simplified.
I really wanna keep using neovim and LSPs ...
As for the DB layer, I quite like JDBI which integrates well with Kotlin also: https://jdbi.org/#_kotlin
I'm not familiar with RxAndroidBLE, but they have some Kotlin examples on GH: https://github.com/Polidea/RxAndroidBle/blob/master/sample-k...
There is a bit of cognitive overhead at first, but that's the overhead of learning a new language. Plus I immediately see the benefits, specifically WRT optionals (?. and ?: operator).
Still cherry picking features from Java 11 when Java 17 just got released, https://android-review.googlesource.com/q/project:platform%2...
Jetpack Compose is the future of Android UI and is Kotlin only.
Insofar as bringing it into the app - from most apps I know of, new code is usually written in Kotlin, and the Java code becomes legacy (which is sometimes rewritten in Kotlin). It works well enough, compatibility with existing Java was important to the Kotlin team (for adoption and other reasons).
Read the Kotlin docs for more https://kotlinlang.org/docs/jvm-get-started.html . You definitely see some of the things mentioned when using both languages, like the JvmStatic annotation etc.
I might give it a whirl and start replacing the easy stuff first. In my system the worst part is the Android app and anything that makes it easier to maintain in the long term is welcome.
edit: Not sure how I missed this announcement: https://www.zdnet.com/article/google-were-using-kotlin-progr...
If that was the reason Dart would have been a better option, but I bet the Android team is not that keen on having Fuchsia take away their party, hence JetPack Composer.
So doing Kotlin in Android, with an anti-Java agenda, reduces Kotlin to use pure Android libraries, or pre-history Java ones that can still be called from Android Java.
It gets stuck indexing forever, losing all code completion and navigation abilities until it’s restarted.
Git integration sometimes stops working. It will list the files to be committed but does nothing when you click commit, until it’s restarted.
Exiting presentation mode leaves the font set to a huge size (until it’s restarted).
The main thing that can be annoying is figuring out module exports from a js library that you want to use (which is probably easy enough if you have a modern javascript background). I haven't found a library that's stumped me yet, but some are more annoying than others. Jetbrains have a tool called Dukat which will supposedly one day automate this, but for now it's not there.
Distribution size can be an issue, but it's not terrible. My current (moderately complex) app is floating at around 2MB. I haven't tried splitting it up, though that is possible.
I don't buy into sharing source files instead of clean separation via Web APIs, the additional tooling complexity isn't worth the pain.
I did vote against stuff like GWT already several times, and every time it has been proven to have been the right decision, when things went hot.
Fair enough, that's a different argument from the one you posed upthread though. The ecosystem and tooling are very much there.
Happy to disagree on architectural merit of the approach. Personally I'm done with javascript/typescript for any future products/teams I build, and am glad to have a viable solution.