I really wanna keep using neovim and LSPs ...
The Hitchhiker's Guide to Kotlin
31–34 of 34 posts
Re: The Hitchhiker's Guide to Kotlin
#32Kotlin is a really nice language. I wish it was used more especially that now it isn't just limited to the Android and Java ecosystems. 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/Native is hardly a stable target, given that they botched the implementation by going with an incompatible memory model as Java, and have spent the last year fixing it by rebooting it with a proper GC implementation. 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 ne…
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).
Re: The Hitchhiker's Guide to Kotlin
#33Earlier quoted context omitted.
Kotlin/Native is hardly a stable target, given that they botched the implementation by going with an incompatible memory model as Java, and have spent the last year fixing it by rebooting it with a proper GC implementation. 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 ne…
I feel the non-JVM targets are a real distraction from what is a lovely language. I’d rather they focussed more on fixing the issues with kotlin in IntelliJ - you’d think controlling both the language and the IDE would result in a less buggy experience than the current situation.
Re: The Hitchhiker's Guide to Kotlin
#34Earlier quoted context omitted.
I feel the non-JVM targets are a real distraction from what is a lovely language. I’d rather they focussed more on fixing the issues with kotlin in IntelliJ - you’d think controlling both the language and the IDE would result in a less buggy experience than the current situation.
Could you elaborate on specific issues you have with Kotlin/IntelliJ? I use both as my daily work environment and I barely have issues.
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).