Apple is killing Swift

Kotlin is more of a "write-first" language where it's easy to bang out some code, but reading others' Kotlin can be a pain. When there's too many options for how to write things, people like to try to get clever and play code golf.

Have you worked professionally in Kotlin? I've done years of it professionally and your analysis feels very off the mark. Maybe you worked with people who like to write overly clever code? (Those people exist in every language).

I can't speak to Swift vs. Kotlin because I have not developed Swift myself.

I've used both Kotlin and Swift in a past role - Kotlin for some backend stuff, and Swift for a iOS RTMP library.

I've found Kotlin to be great at the time as it's "Java, but what if Java was more C#" - i.e. a cut-down less verbose version of Java. I personally dug it at the time, but I saw a project that was entirely written in Kotlin, and there was many, many classes in one file which just made me appreciate Java's one file one (main, non-static) class structure. The codebase was a mess, and as much as I liked Kotlin, I think it's something you really need to sit down and really agree on coding styles beforehand if you are working with multiple people because it's really easy to make a mess.

Swift on the other hand. Yeesh. I did not have a good time with Swift. Admittedly I was dealing with RTMP code so this was byte manipulation and string manipulation as well as trying to manage concurrency - like all of the poorly developed aspects of Swift - but I still have my negative impressions.

Because I came from Java/Python world to Swift, Swift felt like Apple made Python, but their way. Apart from the common if/else and for loops, it really felt like Apple/the designers of Swift tried to make unique features that didn't feel all that necessary. For example, take guard - that's literally an if (!condition) {} statement in syntactic sugar. I kind of felt like it was supposed to be used for nullabillity though (the Kotlin equivalent but just for nullability IIRC is someThing?.let { //code to run if not null } ?: { //code to run if null }).

String manipulation was a pain - look at this monstrosity of an answer that explains how to substring. Also bear in mind I was working on Swift 2 code and had to migrate to Swift 3 code.

If you've never worked with Swift, every major(ish) version was effectively a breaking change (at least from what I remember from 2 -> 3 and I think even 3 -> 3.5?), and the way you had to migrate was to use Xcode to automatically detect deprecated code and let it "fix" your code, although in an attempt to fix your code it could end up breaking it. This used to happen to me all the time with the byte manipulation code, and I would have to google stack overflow instead, find the answer, rewrite it, and use Xcode's "fix" tool to guide me through the broken code like I'm surfing on a wave of broken tides to find the next botched bit of code.

I think the article explains how concurrency was never really implemented. It's genuinely shocking that it hasn't been a priority to this day - Apple chips with all their cores, you'd think they would want to utilise that power more, but what do I know.

After about a year or two writing and maintaining Swift code, I decided to take the plunge and learn Objective C. Imagine the surprise of my life when I found Objective C to be a lot more fun to learn due to:

• Literally decades of documentation from Apple and third party developers compared to the fleeting amounts of documentation on Apple's website - I've looked up AVAudioPlayer on Apple's documentation and honestly it looks a million times more better than it did before - I remember very, very sparse info like the documentation was auto-generated from the functions of the class and with minimal wording. This looks very helpful now, and I would've killed for stuff like this rather than Apple Developer videos where the dev talks about playing low latency video in an half an hour video with no transcript.
• A clear explanation of Apple's thread delegation stuff (effectively previous point)
• Once I developed in it, the syntax wasn't too horrible. I mean, sure, it is bastardised C, but for bastardised C, it was pretty good syntax.

Eventually I moved away from mobile development altogether. Apple's and Google's grip on the market means you are effectively forced to push something new at least every year (even if your app is OK and doesn't need updates). Meanwhile, making a website is cheap, hassle free, and you can do whatever you like and charge whatever you like, using whatever payment means you like (Paypal, Stripe, etc).

(Sorry for this long rambling post, this whole post bought back memories. If you've enjoyed Swift, good on you, and I hope it continues to serve you well.)

I've been doing a lot of coding in lua for a video game engine I'm working on and boy, does it make me miss Java with it's beautiful objects with automatically written get and set methods, and IntelliJ even could make class diagrams automatically so you could easily understand the code. It was an elegant tool from a far more civilized time.

I write a lot of Swift and Kotlin for work and I have a pretty strong preference for Swift.

This might just be bias since I’ve been writing Swift for a few years more than I have Kotlin, but I find Kotlin kind of awkward. It dies on some weird hills with its syntax choices that sometimes feel like they’ve been made with just for uniqueness’ sake, and while the way it handles null checks can be nice sometimes, it doesn’t work just often enough that it makes me wish it had Swift’s if let. I miss guard often too.

Also, I find that Kotlin is dragged down by Java ecosystem baggage to a far, far greater degree than Swift suffers from its Obj-C compatibility/heritage. My exposure to Kotlin is primarily through Android development and so most often for me this manifests in wanting to throw gradle and proguard out the nearest top floor skyscraper window.

Agreed. Reading 1 is news, and what I was interested to come read about - I'd be thrilled to hear of an upcoming paradigm shift for iOS development. 2 is basically an opinion piece, which is what we got, and leaves me reaching for more coffee.

Rust has gnarly looking syntax and doesn’t seem conducive to old style imperative UI toolkits (at the very least, its community seems infatuated with declarative, reactive, and/or immediate mode toolkits)

Arguably this is a good thing that shows Rust is taking active steps to encourage good, robust applications. It's a pain to learn a paradigm shift, but sometimes the new ways are better?

I definitely get that "alien language" comment. I tried briefly to make an iOS app to stream music from BattleOfTheBits, figuring that Apple is known to be fairly good to developers and it should be easy to figure out Swift and their way of doing things. But coming from years of working with Javascript and PHP before that, just dealing with HTTP requests was a nightmare. It felt like I was trying to build a server, and the example code Apple provided basically needed you to already be an expert at Swift syntax because it had what felt like random unexplained punctuation everywhere, each of which was actually a small complication that required additional code to deal with, which was beyond the scope of the example code provided.

Of course, it wasn't entirely impossible to understand, and once I grasped all the loose ends it all seemed reasonable to handle things that way, but it was so much to deal with at once for something that was relatively trivial in my previous domain that it basically felt like being dropped in a foreign country with nothing but a phrasebook to help you communicate with the locals.