The most batteries included multiplatform language right now is _by far_ Kotlin and nothing else is remotely close. The ecosystem is amazing, the language itself is awesome and follows sane rules, you can chose between native code, JVM, WASM, or JS-IR, or all as backends to compile to (for the exact same code) depending on your use case. Compose Multiplatform is also wonderful and by far my favorite UI library now and I’ve shipped a fair bit of code with it. It’s a single UI library that I can share my UI across every platform (including iOS and android), and even seamlessly interop with native widgets on platforms like iOS if I need to, like the camera viewfinder for example.
Kotlin’s real strength is the compilers ability to target as many different backends as you want and cross compile into any platform you want. I have an app in production that save for about three lines of swift that declares the view controller for iOS specifically, shares its entire codebase all in kotlin between Android, iOS, Mac, Linux, and Windows. I could add a line to the build file and add web as a target and turn it into a web app.
The comment you are replying to was focusing more on the low-level features of Swift for systems programming (hence comparing it to systems languages). Kotlin is cool but it is not a system programming language and the native code compilation from Kotlin is not aimed to be.
That earlier comment didn’t actually mention “systems” at all (although it does include “low-level”).
I feel like “systems programming” is getting increasingly ill-defined these days, anyway. If Kotlin and Java aren’t allowed, how about Go? Are you ruling out all languages with garbage collection?
A basic litmus test I use for systems programming languages is: “can I imagine the Linux kernel including this language one day?”
Currently that’s C, Rust, and some assembly.. obviously there are more languages used for systems programming tasks too. Memory management, concurrency, and low-level access are also super important in a system language. How would you define a systems language?
C++ would sob in a corner, but the Sob static object was instantiated before the Tears static object because the link order changed and so there's a dangling reference and nothing runs any more.
I think systems programming, like system tools or cli tool for example can also be done with a garbage collector e.g. in Go or Ocaml. For low-level development you would usually expect that the program manages memory itself, not some garbage collector. This is not black and white, some approaches of reference counting for example might be suitable for some low-level development. Or in some languages you can choose like Nim, D or if I understand correctly, now in Swift ?
> That earlier comment didn’t actually mention “systems” at all
It doesn't really need to mention "systems" specifically, since the comparison to other common systems languages, in addition to the words "low-level" implicitly imply systems programming languages.
Usually, languages with GC will not be considered contenders for systems programming.
> The most batteries included multiplatform language right now is _by far_ Kotlin and nothing else is remotely close.
I've been using C#/.Net lately and I've been very impressed. Very large ecosystem and community. Perhaps larger than Kotlin. And you are not stuck with one IDE from one company.
Microsoft also has dotnet MAUI that sounds similar to Compose Multiplatform. I have not used neither so I can't speak to any strengths or weaknesses in the UI libraries.
I’ve gotten the impression that MAUI might be a dead-end, with MS pushing Blazor instead.
I’m amazed people like C# so much. I think it really shows its age when you compare it to Swift or another modern language.
Some things I’ve been frustrated with:
- throwing isn’t a contract made at the function level. Anything can throw, and you can ignore it if you want. And the APIs are inconsistent because of it
- nullable types and default values are weird and seem like two solutions to the same problem
- Blazor bindings are very boilerplate heavy
- hot reload doesn’t work most of the time, and iteration times are bad compared to every other stack I’ve used
Kotlin isn't bad, but having written plenty of both it and Swift, I'd rather write Swift if I had the choice. Their syntaxes share a lot of similarities, but subjectively I find that Kotlin is less ergonomic, not as conducive to code that reads smoothly, and is finicky about odd details in comparison. I'll take SPM over Gradle any day too.
On the more minor side of things, Swift's built in JSON serialization is super handy. It's really nice to not have to increment the dependency counter to parse JSON and makes spinning up projects that much faster.
Kotlin Native's choice to go with a GC over native memory management is my biggest issue with it and really limits its use for memory and performance sensitive use cases.
> The most batteries included multiplatform language right now is _by far_ Kotlin and nothing else is remotely close.
Kotlin is nowhere close to Java in this comparison. For all intents, there is just one realistic IDE for Kotlin. And realistically only one build system. And the community is very small. Java, by comparison, has many IDEs to choose from, many build systems, and a very large community to answer questions.
I've been using Flutter and Dart for multiplatform apps, as I found Compose Multiplatform to be far behind Flutter thus far in support. Dart also compiles to a VM, WASM, JS, and native code, although not the JVM but I don't know how useful that is if you already have the previous three.
Kotlin’s real strength is the compilers ability to target as many different backends as you want and cross compile into any platform you want. I have an app in production that save for about three lines of swift that declares the view controller for iOS specifically, shares its entire codebase all in kotlin between Android, iOS, Mac, Linux, and Windows. I could add a line to the build file and add web as a target and turn it into a web app.