https://kotlinlang.org logo
Join Slack
Powered by
If I understand correctly: - Kotlin/JVM is best fo...
# announcements
c
If I understand correctly: • Kotlin/JVM is best for “I want to be as fast as possible (at the cost of RAM and startup time)” • Kotlin+GraalVM is best for “I don't want to wait for the VM to start (at the cost of throughput)” • Kotlin/Native is best for “I want to use as little RAM as possible (at the cost of speed)” Is that correct?
✅ 1
u
When you say GraalVM, do you actually mean GraalVM native image? Because GraalVM itself is only a (JIT) JVM implementation, which I don’t think offers any significant startup performance improvements
n
isn't GraalVM-the-VM and native-image both better in basically every way than conventional JVMs? native-image sometimes has compatibility issues is the main thing
j
I did actually not know Kotlin/Native is slow, any reasons and resources about why?
n
it's more like JIT JVM is actually really damn fast once it's warmed up
n
I don't know that it is, but if so, I'd assume that a lot of it boils down to a JIT approach just fitting much better with Java/Kotlin as languages
In Kotlin you have way more dynamic dispatch all over the place, both intrinsic to the language but also just given type erasure. An AOT compiler wouldn't be able to inline most of these things so you'd be left with piles of vritual calls. It could still be quite fast, but a JIT has an advantage here, after the warmup it can have a fast-path of inlining with a quick check to verify, and then virtual in a slow path
Compare to C++, where most things are statically dispatched and monomorphized, you use dynamic dispatch very judiciously, in that setting, an AOT compiler grinding a way for a good while can usually do better. I should probably add, Kotlin/Native seems to be LLVM backed, LLVM compiles very slowly compared to what you'd need for a general purpose JIT, so I'm assuming that Kotlin Native is all AOT optimized, though it is still possible to do JIT optimization in native of course.
c
I'm not entirely sure about Kotlin/Native, but all the forums mention it's very slow (compared to JVM). If I understand correctly, Kotlin/Native is targeted towards IoT, where low memory footprint is the most important thing? In the (soon-ish) future I will start a project that requires very high performance, so I'm wondering what the best architecture would be (I know benchmarking is more important than guessing, but rewriting everything in another language later is not fun). Looks like the best option at this point is pure C for the most sensitive parts and Kotlin/JVM with JNI for the “glue” & all features that are less sensitive
n
I mean obviously there are personal preferences here, developer familiarity, existing ecosystem considerations
but the overwhelmingly most common choice in industry for ultra high performance applications is definitely C++
It's pretty much all of HFT, it's pretty much all of AAA game dev and engine dev
Using pure C instead of C++ is really hurting your expressiveness and type safety in performance critical code parts, even something as simple as a very fast hash table, it's a real pain in C. And I respect the productivity benefits of Java/Kotlin, but I think you losing most of your gains once you start having to deal with the mixture. But it really depends on many things, especially the skillsets of the developers
n
There are some areas where C dominates. Take for instance Embedded development where C rules the roost (especially with Embedded development that targets uCs). On the Linux, and Embedded Linux platforms many of the important userspace APIs are written in C, which Kotlin (via Kotlin Native) can take advantage of. Sure the same thing can be done with Kotlin JVM (via JNI) but that is much more difficult/clunky compared to Kotlin Native, which makes C interop reasonably straightforward in most situations (all mappings are automatically generated).
Interop with the target platform does need to be taken into consideration. It isn't all about performance. If you were targeting Linux in a Kotlin project for example then Kotlin Native would be a better fit than Kotlin JVM.
In a Kotlin Multiplatform project you can have different modules using different Kotlin development platforms. For instance you could have a Kotlin Multiplatform project (IoT based) that is comprised of five modules: • common - Share general business logic • androidClient - Android client via Kotlin Android • server - Backend via Kotlin JVM • webClient - Web client via Kotlin JS • linuxArm32Client - Linux desktop client via Kotlin Native You don't always need to stick with a single Kotlin development platform over another one. It all heavily depends on what you are trying to do.
On the IoT side code size needs to be kept low just like RAM usage. With JVM based apps the code size is often far too large.
l
Rust is great and safer alternative to both C and C++ that has a comparable performance.
n
I'm assuming the OP is talking about developing high level software where languages like Kotlin are suitable for this, but system level languages like Rust aren't.
l
Rust is comparable to C and C++ and this thread has been talking about these a lot, so I'm reminding these are not the only ones in the game. My comment is about replies in the thread, not about the OP message.
n
It's comparable, just vastly less industry adoption, harder to find developers, etc typical new language pretty problems
The core seems nice
l
Just like Kotlin a while ago, it's irrelevant.
n
Industry adoption and finding developers is irrelevant? Lol ok
l
It's not on topic.
C developers can learn Rust relatively easily, just like Java developers can learn Kotlin quite easily.
n
It is, but I think you have your own notion of the topic so 🤷
That's not similar at all either, but ok
Anyway not much reason to do this here
l
Some folks praised C++ and C for performance in this thread, so I'm saying there's also Rust, which is also safer in several areas. I didn't intend to debate which one has more users, adoption and hiring.
n
I don't really agree with Nicks comment about high level software vs low level system languages. C++ or Rust can be used to write high level software, there are extra costs, it just boils down to how it weighs against having a high perf C core
I didn't praise C++ a performance primarily, I said C++ is the industry standard in high performance applications, which it is, not Java/Kotlin + C, not Rust. That's all.
l
Rust can also be used to write software. Once it's compiled, all software is low level somehow. BTW, Firefox is made mostly in Rust nowadays.
n
Also not true....
l
I said 2 things, which one are you referring to?
n
That firefox is mostly Rust
l
I don't know exactly, but lots of new code in Firefox is made in Rust for sure, and it helped them avoid many security flaws they'd have if they used vanilla C++ instead.
c
The thing that's certain is that most of my project will be written in Kotlin. I will need a core that requires as much performance as possible (and it uses Vulkan) and I thought C would be a good contender since I like the language (I really don't like C++, but that's on me). Rust looks very promising but I have no idea how well it plays with Vulkan and with JNI/Project Panama.
n
It really depends how big your core is
If your core is very small, pure C could be reasonable
By very small I mean literally like a thousand lines of C
Once you pass that point, just using C++ for implementation and exposing a pure C API is a strict win
As I'm fond of pointing out, even some C standard library implementations are in C++ :-)
today i learned 1
I should say it's a strict win if you know C++ at least reasonably of course
c
I've had classes on it, but because this is only the core of the project I'd rather use C and be absolutely sure I understand everything going on rather than use C++ (let's say the quality of features can vary quite a bit). The rest of the program (which is going to be the vast majority in LOC) can take full advantage of Kotlin for “ease of use” ^^ But yeah, I'm wondering if Rust could replace C here (if I understand correctly from what I've read, it promises much more explicitness than even C in some areas, as well as safety, so...)
👍 1
n
It probably can, just more work to have a C API relative to C++, but notably it's still a much more complex language than C, closer to C++ in that regard, which you need to learn
11 Views
Open in Slack
PreviousNext
Powered by