https://kotlinlang.org logo
Join Slack
Powered by
Hi All. I hope I’m not asking that was asked 1000 ...
# kotlin-native
g
Hi All. I hope I’m not asking that was asked 1000 times before, but I couldn’t find any reliable answer on the web. We are evaluating using K/N for our new and shiny startup’s standalone client app, which should run on MacOS, Linux & Windows. We have no plans to run this client on iOS/Android. Do you know of any real-world standalone desktop app project that’s using K/N? Is K/N suitable for this you think or is it mainly a tool for doing KMM right? We will need things like: • desktop notifications • File-system monitoring and • Displaying a React based UI inside a browser wrapper window. EDIT: building Kotlin/JVM is not an option for us, as we’re building a daemon, and the JVP heap requirements is not acceptable for our use-case.
e
if you're targeting desktop, I'd build a JVM application instead of K/N. the ecosystem is more mature
l
Also, #compose-desktop is really great on the JVM.
g
Thanks @ephemient @Landry Norris please see edit: KJVM is not an option for us due to memory consumption profile of the JVM.
l
I don't know of any UI apps for K/N. I've not been the largest fan of making K/N only apps. So far, I've done cli type projects, and settled on supporting JVM for testing and debugging because of the better tooling and I plan on using K/N for release. This has worked fine for me so far, and should be fine as long as the libraries you use support both K/N and JVM.
e
with regards to memory profile, how so? Kotlin/Native still uses a garbage collector - currently reference-counted, but it is migrating to a generational tracing GC. it should not be substantially different from JVM
g
@ephemient I have not looked into the internals, but I do know from experience that my JVM apps are memory hoggers - i.e. allocate first, use later. With an occasional overstep bounds defined with -Xmx as noted here. We believe this is not an option for a client app that stays resident on your desktop for days at a time. just allocation X amoung of GB and then not using them is okay for a dedicates server, but not for a desktop that runs many apps in parallel. Does this make sense at all? Am I missing something?
e
-Xmx
is maximum heap size but there are things in JVM that don't live on the heap, so of course the maximum memory usage will be larger than that
l
That's fair. That's why I would recommend using JVM for dev, since the tools are better, and resource usage is generally less of a concern on a dev machine, then using K/N for release. The major downside here is the limitation that your libraries have to support JVM too.
e
Kotlin is fundamentally a garbage-collected language and all targets use GC. K/N's current reference-counting GC has too many limitations (cannot support concurrency as expected on every other platform) so JetBrains is working on a replacement, which in its initial implementation will be a very basic STW tracing GC. this will not perform as well as JVM's heavily-tuned GC algorithms but over time should approach it.
🙌 1
g
@Landry Norris - want to make sure I understand correctly - the idea is to develop deploying to JVM, debug there etc… but when releasing build to K/N? but then I wouldn’t be able to use any of kotlin.native.concurrent.freeze which I understand is the recommended lib when doing cocurrency on K/N?
e
the big difference between K/N and K/JVM is AOT vs JIT. there are plusses and minuses on both sides, but if you're only targeting desktop, it will be easier to use K/JVM with GraalVM's native image to perform AOT.
🙌 1
💯 1
l
My understanding of freezing was that it was originally a workaround to the limitations of the older memory model. I forgot about Graal. I haven't used it before, but it may be good to try, although it sounds like your primary concern is memory over performance.
Graal does limit what you can use for UI, though. I don't think Swing is fully supported, which also limits compose.
e
right, GraalVM doesn't fundamentally change the memory model (although it does avoid the need to keep execution traces around for JIT, at the cost of larger binary sizes)
t
K/N is not a cross platform desktop UI development tool, it will always need something on top. so unless you want to use some of the very early and unproven projects for this, that is what you will be building rather than the actual application.
g
We really love Kotlin, and used it on the server side. But for desktop we’re evaluating it vs Rust. so we want both speed AND tight memory usage, which is what rust alegdly promises us as an alternative.
e
GraalVM does actually work with Swing now. I don't know if it works with Compose though. in the past it has had issues with kotlinx.coroutines but I believe those are resolved now.
l
You could use GTK for UI on native. I wasn't a big fan, and switched the project to JVM, but someone with more GTK experience would probably be able to use it more easily.
g
we considering to use React for UI. I.e. use K/N for the “deamon” stuff, but then when in need for UI, just open a browser wrapped in a window, and have it run our React app there. (Or even use electron )
l
Have you looked into K/JS for the react part?
g
so doing UI with K/N is not a concern, as long as we can use Electron, or KTor for hosting our React App
RE: k/js - not yet - thanks for the tip
l
Ktor 2.0.0 will support running native when it's released (hopefully soon because of 1.6.20), by the way.
🙌 3
e
neither Kotlin/JVM nor Kotlin/Native will win against Rust on memory usage. Kotlin's design balances performance and other metrics with developer happiness. (also K/N's performance is waaay lower than JVM or Rust, because it hasn't been a focus yet, owing to more important issues that JB is working on first)
✅ 2
t
Rust has a very established ecosystem for making CLI/daemon type applications, in Kotlin/Native it’s an afterthought. So Rust would be a more natural choice. With K/N you’ll be working with much less and you are much more on your own for this type of app at the moment. If you really like Kotlin (or some Kotlin code you can make reusable) and that’s reason enough for you, it can certainly be done. C interop isn’t exactly perfect (certainly not compared to Rust or Go, or of course just using C/C++) but it’s usable, and you can just use that to do whatever Kotlin cannot. It will probably also fit your perception of memory usage stats etc. Maybe not so much portability (e.g linux/aarch is there but barely). An even less obvious path could be using both, they should link just fine.
🙌 1
👍 1
6 Views
Open in Slack
PreviousNext
Powered by