https://kotlinlang.org logo
Title
l

Lucy

03/05/2023, 3:44 AM
I'm looking for a fairly low level language (need access to platform APIs, building shared libraries, pointers), and I'm wondering if Kotlin/Native might suffice for that. I've ruled out C/C++ and Rust already because I'd prefer something else. Decent community support/libraries would also be nice. Thoughts?
v

vbsteven

03/05/2023, 11:01 AM
What is the reason why C/C++/Rust are ruled out? Kotlin/Native can work for this purpose: • It has the ability to interact with native (C) libraries through cinterop • It can work with C pointers • It can export Kotlin code as shared libraries The community and library support is still very early days and not many libraries are availlable yet. While in theory you should be able to use any C library from your KN project, it will probably require getting familiar with cinterop and
.def
files to create library bindings yourself.
l

Lucy

03/05/2023, 2:17 PM
I'm not a fan of those languages in general, and for Rust, especially the borrow checker. It's just a preference, but obviously I understand if there aren't any viable alternatives currently. Seems like Kotlin/Native would work for my use case, though. I'm just a little concerned about the future of it, as I've seen others mention the terrible performance
v

vbsteven

03/05/2023, 3:58 PM
I guess it is still early days and only time will tell. I'm bullish on it and currently putting a lot of time in trying to get it to work for my own use cases.
l

Lucy

03/05/2023, 6:26 PM
Got it. Well, it's worth a try. Less obscure than the other options like D, at least.
l

Landry Norris

03/06/2023, 2:43 PM
The performance difference seems mainly associated with the runtime. K/N compiles to LLVM bitcode, same as C/C++/Rust, meaning aside from some bitcode optimizations, code that doesn’t need to trigger the GC should run about similar to C (backed up by my testing). There’s also of course the difference that K/N doesn’t compile to a ‘native’ (current CPU) target by default, unlike these languages, but that’s not useful in production anyways.
l

Lucy

03/06/2023, 2:59 PM
Hmm. Well, I'd imagine a lot of code would end up triggering the GC regardless. I wonder if there's any plans to improve the runtime performance then. Because 17x slower than C++ vs 4.3x for the JVM is pretty terrible.
l

Landry Norris

03/06/2023, 2:59 PM
Where did you get those numbers?
I've checked some others as well, though. It's a big difference
l

Landry Norris

03/06/2023, 3:02 PM
Kotlin 1.6 (in 2021) brought a large improvement in performance. I’d like to see the benchmarks with the latest versions of languages. I remember seeing Kotlin code being quite slow on the 1.5.x versions.
Looks like the C++ gets compiled with the native target and O3, which I’d argue is a bit misleading, since it doesn’t represent ‘production’ binaries, which rarely have either optimization applied.
l

Lucy

03/06/2023, 3:05 PM
There's this as well. Seems to be up to date. https://programming-language-benchmarks.vercel.app/kotlin-vs-cpp
l

Landry Norris

03/06/2023, 3:06 PM
Don’t get me wrong, for open source code, O3 and native target can greatly improve performance, but because native target can only build code that will run on the same model of CPU, and O3 optimizations often cause subtle bugs in large projects, few closed source projects would be built with either.
l

Lucy

03/06/2023, 3:06 PM
Oh yeah, fair point. But anything I'd write would be OSS anyway :)
l

Landry Norris

03/06/2023, 3:08 PM
Gentoo users often tout the performance improvements of native+O3 (they claim 2-3x performance benefit), but even Gentoo’s wiki recommends trying it first, and building ‘normally’ if you see weird issues.
l

Lucy

03/06/2023, 3:08 PM
I would be vary of O3 for sure.
l

Landry Norris

03/06/2023, 3:09 PM
I think it’s technically possible to tell the kotlin compiler to use both of those when running clang, but not sure how reliable that would be.
l

Lucy

03/06/2023, 3:09 PM
Being able to pass O2 and native might be nice if it's possible
l

Landry Norris

03/06/2023, 3:10 PM
I’d look into using freeCompilerArgs. Sounds like a cool weekend project (noting that you should never distribute a binary built with native target, since you can only guarantee it runs on the same CPU model).
l

Lucy

03/06/2023, 3:11 PM
Yes, of course. A public binary wouldn't use it
l

Landry Norris

03/06/2023, 3:11 PM
Complete guess based on vague memory:
freeCompilerArgs += listOf("clang-flags", "-O3", "clang-flags", "target=native")
l

Lucy

03/06/2023, 3:12 PM
Cool! Will try it out
Well, those don't seem to be valid args for the kotlin compiler. I did some testing and it seems like native is still around 3x slower than the JVM. So, not ideal, but it's hard to gauge when it'll become an issue
v

vbsteven

03/06/2023, 6:54 PM
It will depend on your use case as well. If your Kotlin code is mostly calling into other native libraries it won't matter that much. If you intend to write the performance-critical parts in Kotlin it's a different story. Which use case are you targetting and how are you benchmarking?
l

Lucy

03/06/2023, 7:22 PM
DLL injection into a game. It's not going to be performance critical, though. And seeing as the win32 api is accessible, it should be possible to hook into functions and stuff, right?
v

vbsteven

03/06/2023, 7:26 PM
AFAIK there is no problem in accessing anything that can be accessed from C. (Calling functions, passing pointers, defining new functions and passing those as pointers to other C functions, etc)
l

Lucy

03/06/2023, 7:30 PM
Yeah, seems like it'd work fine