>clean, concise syntax
>amazingly productive
>leverages decades of jvm libraries, frameworks, and optimizations
>fast enough
>supports multiplatform development
>google recently told their java engineers to start learning kotlin
>google doc team switching over to kotlin multiplatform
yeah, i'm thinking i'll learn kotlin
>has same problem as java in being JVM trash
good if you're invested in the ecosystem, worthless otherwise
List reasons why is JVM trash
>JVM BAD!
even you can't deny the language is comfy and very productive
>muh productivity
wastes memory and cpu cycles doing worthless things like garbage collection when I can manage my memory by myself with 0 overhead and very low power consumption while using like 1% of RAM a Java program would need because I'm not moronic.
>cnile fizzbuzzer
you are indeed correct that C is for fizzbuzzing only, which is why I program in C++
Segmentation fault. Core dumped.
never saw this coming from a program that I wrote
can't you also compile kotlin to other targets? Like native binaries, wasm and javascript?
Prove that optimal Kotlin code generates better machine code than optimal C++ code and I will consider.
it's okay anon. be free. we welcome you.
I'm not a kotlin dev, just passing around things I've heard sometime somewhere.
But apparently its using LLVM for native compilation, so I would assume that it's at least not an order of magnitude lower by default.
https://kotlinlang.org/docs/native-overview.html
Again, not a kotlin dev, but I doubt that it gives you the low level memory management tools to keep up with high-performance C/C++ code.
*slower not lower
my problem with these shitlangs is that when I want to use a shitlang, I will just use Python, it just works and it lets me write efficient code in practically any language ranging from garbage like C all the way to Rust and I will never need more.
>Again, not a kotlin dev, but I doubt that it gives you the low level memory management tools to keep up with high-performance C/C++ code.
You actually can use native memory management. There is also arena allocators in the standard library. But you can't disable GC, it's always there. But you can just simply not use it.
https://stackoverflow.com/questions/55610460/how-kotlin-native-garbage-collector-works-in-c
>But you can just simply not use it
But how far can you go in avoiding heap-allocations?
In C#, there's also "no way to disable GC", but you can define structs, manually allocate and free, use references/unmanaged pointers to pass that data around, including function pointers, and of course just use structs on the stack without dealing with the heap at all.
All of which makes it possible to just "not use GC".
I would imagine there being complications for Kotlin if the main compilation target's (JVM) main language (Java) does not allow for those things at all.
There are wrapper classes for all native stuff, like CPointer. You just use those.
yes. i am finally home.
learn clojure homosexual
sorry not interested in troony langs, if I wanted to target JVM I would maybe consider Kotlin
Not fun to use outside of israelitebrains IDE
so?
the only thing that killed Dart is that it was a G**gle product.
Kotlin is made by JetBrains, so at least you know they don't have their heads up their own asses.