3 ms·

How would you compare Swift with Kotlin in terms of being a good stand-in for high-level Rust? I've not paid attention to Kotlin in a while, but it seems like

by etse 4y ago

How would you compare Swift with Kotlin in terms of being a good stand-in for high-level Rust? I've not paid attention to Kotlin in a while, but it seems like there's more progress at supporting Kotlin across more platforms (Kotlin native, web?, etc). I'm curious if people feel that the language features and design are at about parity, or if one is significantly stronger/weaker.

eatonphil 4y ago
Swift has the distinction (for better and worse) of not being tied to the JVM.
- dcow 4y ago
  Kotlin-native is an effort to compile directly to your target non-jvm machine.
dcow 4y ago
I haven't seriously used Kotlin in 4-5 years. I too was excited about it supporting native compiles and web assembly but I have no firsthand experience with how far those efforts got.
manmal 4y ago
Last time I toyed with Kotlin Multiplattform (bit less than a year ago) it provided only really weird Objective-C bindings for use in iOS/macOS. Like, a statically defined List turned into an Obj-C iterator. Enum and sealed classes were quite problematic either - I honestly would not consider using KMM for anything but a PoC. BTW, JetBrains recently sunsetted AppCode, so they are bleeding their Swift talent now. I suspect that doesn’t bode so well for Kotlin‘s Swift interop.
neonsunset 4y ago
Another scenario where an often missed and underrated choice would be C#. Nowadays it runs everywhere and supports a variety of deployment targets (relying on local runtime, packaging it together into a single somewhat compact binary, natively compiling the code (NativeAOT, it's good but has some limitations) or mixing and matching all of the above). It is also one of the best high-level languages to write performance-oriented code with, especially so with .NET 7 which allows writing cross-platform SIMD code in a similar fashion to Rust's 'portable-simd' crate.
- kitsunesoba 4y ago
  My experience is probably colored by .NET/WinUI but when I was dabbling in writing a Windows desktop app a few months ago I can't say I loved C#. My background has no Java in it so maybe that's why, but a lot of things that come standard as part of Swift seem to be in external libraries with .NET/C#, and it felt like some things were different for the sake of being different. Point in case, with Swift and Kotlin I've gotten used to chaining various transformation functions (map, compactMap, flatMap, filter, sort, reduce, etc) and some of these don't have a 1:1 equivalent in C# which was a huge hit to productivity, even if the same result is achievable via other means. And while it's tangential, Xaml drives me absolutely bonkers. It's like the worst parts of iOS Storyboards and Android Framework XML layouts except there's no escape hatch for those looking to build a UI in pure code (Android Framework is a bit of an offender here too, but Jetpack Compose looks to remedy that).
  - FlyingSnake 4y ago
    > some of these don't have a 1:1 equivalent in C# which was a huge hit to productivity This is interesting because all these magical functions (zip, map, Rx etc) have roots in LINQ which sprung from .Net world. I find it hard to believe that the battle tested CLR and C# doesn't have the equivalent functions.
    - lmm 4y ago
      > all these magical functions (zip, map, Rx etc) have roots in LINQ which sprung from .Net world No they don't. They're essentially unchanged from ML back in the 1970s. The part that was new in C# was the SQL-like syntax on top of them, and most subsequent languages haven't considered that worth adopting.
  - neonsunset 4y ago
    All these are part of standard library. Map is Select, Filter is Where, Reduce is Aggregate, etc. You can write C# in a functional style easily, it is one of the premiere features. UI frameworks on the other hand…I feel your pain.
kitsunesoba 4y ago
Kotlin is about as nice as Swift until you run into some bit where it's interfacing with Java and then it becomes a lot less fun. Swift I think handles Obj-C/C interior a bit more gracefully by comparison. Various bits of other JVM baggage also aren't great. That said I've only used Kotlin in the context of Android development. It might be nicer elsewhere.
FlyingSnake 4y ago
Apart from language syntax similarities, Kotlin and Swift are fundamentally different languages, one runs on a VM (ok there's KNative) and other runs on bare metal. Kotlin has it's roots in JVM and the early language design choices clearly reflect that. Kotlin/Native will find it very hard to break free of it's JVM counterpart because it can't diverge too much from it to maintain compatibility.
jurip 4y ago
Background: I spend most of my time in Swift but do work in Kotlin too. Occasionally some Rust. Swift and Kotlin are in many ways similar, but I find Swift to be a bit nicer in almost every respect. Swift has more powerful generics, tuples, structs, powerful enums that are value types, `if let`/`guard let` statements that I'll take over `?.let {}` any day, etc. Kotlin is somewhat more expression oriented, which is nice; Swift is moving in that direction too, but slowly. A native Kotlin (I have no idea how mature it is) might be a decent alternative to high-level Rust, but I'll take Swift if it's available. It's both more pleasant to work in and I assume more performant with better access to stack allocated value types.

by etse 4y ago

eatonphil 4y ago

Swift has the distinction (for better and worse) of not being tied to the JVM.

dcow 4y ago
Kotlin-native is an effort to compile directly to your target non-jvm machine.

dcow 4y ago

I haven't seriously used Kotlin in 4-5 years. I too was excited about it supporting native compiles and web assembly but I have no firsthand experience with how far those efforts got.

manmal 4y ago

Last time I toyed with Kotlin Multiplattform (bit less than a year ago) it provided only really weird Objective-C bindings for use in iOS/macOS. Like, a statically defined List turned into an Obj-C iterator. Enum and sealed classes were quite problematic either - I honestly would not consider using KMM for anything but a PoC. BTW, JetBrains recently sunsetted AppCode, so they are bleeding their Swift talent now. I suspect that doesn’t bode so well for Kotlin‘s Swift interop.

neonsunset 4y ago

Another scenario where an often missed and underrated choice would be C#. Nowadays it runs everywhere and supports a variety of deployment targets (relying on local runtime, packaging it together into a single somewhat compact binary, natively compiling the code (NativeAOT, it's good but has some limitations) or mixing and matching all of the above). It is also one of the best high-level languages to write performance-oriented code with, especially so with .NET 7 which allows writing cross-platform SIMD code in a similar fashion to Rust's 'portable-simd' crate.

kitsunesoba 4y ago
My experience is probably colored by .NET/WinUI but when I was dabbling in writing a Windows desktop app a few months ago I can't say I loved C#. My background has no Java in it so maybe that's why, but a lot of things that come standard as part of Swift seem to be in external libraries with .NET/C#, and it felt like some things were different for the sake of being different. Point in case, with Swift and Kotlin I've gotten used to chaining various transformation functions (map, compactMap, flatMap, filter, sort, reduce, etc) and some of these don't have a 1:1 equivalent in C# which was a huge hit to productivity, even if the same result is achievable via other means. And while it's tangential, Xaml drives me absolutely bonkers. It's like the worst parts of iOS Storyboards and Android Framework XML layouts except there's no escape hatch for those looking to build a UI in pure code (Android Framework is a bit of an offender here too, but Jetpack Compose looks to remedy that).
- FlyingSnake 4y ago
  > some of these don't have a 1:1 equivalent in C# which was a huge hit to productivity This is interesting because all these magical functions (zip, map, Rx etc) have roots in LINQ which sprung from .Net world. I find it hard to believe that the battle tested CLR and C# doesn't have the equivalent functions.
  - lmm 4y ago
    > all these magical functions (zip, map, Rx etc) have roots in LINQ which sprung from .Net world No they don't. They're essentially unchanged from ML back in the 1970s. The part that was new in C# was the SQL-like syntax on top of them, and most subsequent languages haven't considered that worth adopting.
- neonsunset 4y ago
  All these are part of standard library. Map is Select, Filter is Where, Reduce is Aggregate, etc. You can write C# in a functional style easily, it is one of the premiere features. UI frameworks on the other hand…I feel your pain.

kitsunesoba 4y ago

Kotlin is about as nice as Swift until you run into some bit where it's interfacing with Java and then it becomes a lot less fun. Swift I think handles Obj-C/C interior a bit more gracefully by comparison. Various bits of other JVM baggage also aren't great. That said I've only used Kotlin in the context of Android development. It might be nicer elsewhere.

FlyingSnake 4y ago

Apart from language syntax similarities, Kotlin and Swift are fundamentally different languages, one runs on a VM (ok there's KNative) and other runs on bare metal. Kotlin has it's roots in JVM and the early language design choices clearly reflect that. Kotlin/Native will find it very hard to break free of it's JVM counterpart because it can't diverge too much from it to maintain compatibility.

jurip 4y ago

Background: I spend most of my time in Swift but do work in Kotlin too. Occasionally some Rust. Swift and Kotlin are in many ways similar, but I find Swift to be a bit nicer in almost every respect. Swift has more powerful generics, tuples, structs, powerful enums that are value types, `if let`/`guard let` statements that I'll take over `?.let {}` any day, etc. Kotlin is somewhat more expression oriented, which is nice; Swift is moving in that direction too, but slowly. A native Kotlin (I have no idea how mature it is) might be a decent alternative to high-level Rust, but I'll take Swift if it's available. It's both more pleasant to work in and I assume more performant with better access to stack allocated value types.