My experience interacting with teams and devs targeting Swift is that when Apple says “jump” you jump.
What do people already using Swift in production think?
With Swift, I have a hard time getting a feel for what the unifying gestalt of the language is supposed to be. It's a better C! It's objects! It's functional! It's typesafe! It's protocols! It's async! It's closures! It's a better C++! It's modern! It's a systems language! It's a scripting language! It's for UIs! It's actors! It's declarative! It infers things!
I get stuff done with it (obviously) and it's capable, but the effect has not been "it's a bird, it's a plane, it's Superman." It feels like some sort of anime shapeshifter caught in a cycle sometimes. Or a bogart.
I keep hoping these are growing pains, intermediate steps, with a "long game" characteristic of Apple, but I'm not seeing it yet.
Kotlin seems to be following a similar path, just a few steps behind in some places, and a few steps ahead in other.
In fact, you could state the same complaints against Turbo Pascal on the MS-DOS days.
The problem with Swift (as of like 1.5 years ago when I stopped using the language daily) was its ecosystem. Swift package manager wasn't really used (at least for iOS apps), there was no real decent ecosystem outside the xcode world (no langserver, some server-side swift abstractions).
I think Swift would really thrive if Apple were to give it some room to breathe in the open source community, but until Swift decouples itself more from Apple's own needs, I couldn't imagine using it for anything other than iOS development.
Swift has the benefit of actual value types, no GC, and IME it's much faster. But it only runs on Apple's OS (technically there's support for Linux but people say it isn't good). Kotlin has access to all Java packages and runs on the JVM, and with Kotlin multiplatform JetBrains is trying to make it run on almost anything.
Besides which I don't want to have to keep track of weak references, at that point I would rather just have a full ownership model: https://github.com/apple/swift/blob/main/docs/OwnershipManif...
There is a Herb Sutter talk at CppCon about the downsides of reference counting.
Basically the solution to those problems is to make use of hazardous pointers or deferred destructions on background threads, which are a kind of lightweight tracing GC.
Outside Android, Kotlin will always be playing catch-up with platform features, having two ways of doing the same thing for features introduced before the platform went their own way, FFI that only goes one way, the native variant is being redone due to the clever idea of being originally incompatible with JVM memory model, it is officially a way to sell InteliJ licenses.
Anything Rx beyond the simplest of examples? Nope.
I'm not trying to argue about that though - I just want to know under what set of circumstances I should prefer async/await over Rx and vice versa.
From what I'm gathering I should stick to Rx (Combine) when I have multiple related tasks or want to fire off changes in response to events, whereas async/await is useful for one-off asynchronous tasks like most web requests? I'm really not sure.
Maybe I just haven't learned proper EventLoopFuture-style development style, but you really seem to get stuck callback hell, similar to the early days of NodeJS. It's a bear on code readability.
Re: the sibling comment about Combine -- I've heard great things about Combine but AFAIK it's still part of Apple's platform-specific layer atop Swift so the small group of us using Swift atop Linux can't use it (yet?).
> when Apple says “jump” you jump.
just not with the betas