Swift – A great language strangled by governance

"A great language strangled by governance" – it's not clear to me that Swift is in a materially worse place than any of the 3 alternatives this post points to. Rust has had a lot of drama and botched their async/await, Python had 3, took a decade to recover, and has failed to address its terrible packaging over the last 2 decades, and the Kotlin process described sounds almost identical to the Swift process.

Was Swift entirely top-down controlled at the beginning, with a bunch of breaking changes? Yes, but it has very clearly graduated from its early development now with no forced breaking changes and an open proposal process that is clearly working. Has Swift hard-coded Apple framework exceptions? Maybe, but that has never gotten in the way of me using or understanding Swift code, so I'm not sure it affects me as a developer. Has Swift become a hugely complex compiler? Sure, but I'd rather have a complex compiler and a better developer experience, especially if Apple is paying for it.

I don't disagree with the facts here, this just doesn't resonate with me at all. I'm a very happy Swift user, would like to be using it a lot more, and enjoy the forward momentum in the ecosystem as Swift becomes in my mind one of the most advanced languages available.

Swift is controlled by Apple, Inc. Nobody worth listening to is denying that. The steering committee is almost all Apple employees, most of the commits going in come from people who commute to Cupertino, and whatever the progress is on Windows or Arduino or whatever, it's clear that "first class" really means iOS. That's all true. Apple makes proposals, they seek some community input, and in the end they pick what they like and it ends up in the language.

But even with that said, the rest of this post is of low quality. Tim Cook and his MBA buddies didn't personally come in to ruin the language because the shareholders aren't making money. Chris Lattner is, whatever his contributions to the language previously, just a guy. He would probably try to put Swift on GPUs today if he had his way. It's not the first time he sold it out before. You've got to go beyond "omgz so many keywords so complicated!!1!!" and look deeply at the real sources of complexity. Swift has a powerful generics system that has worst-case behavior that really sucks. The discussion process has a bunch of busybodies that have nothing better to do than talk about names of things. Yes. These are real problems. It's funny when there are random hacks in the source code to support things that Apple is shipping. But that is how a large project works. You are more than welcome to laugh about it on Twitter but substantive criticism it is not. Which is a shame, because there is plenty of it go around.

I know it's subjective, but if we're arguing about Swift's quality by comparing with Python, I'm not buying it.

When it comes to governance, it’s not without wrinkles, but it’s not as bad as the author makes it sound. If anything, things got a bit less “dictatorial” since Chris left. Different core team members pull in slightly different directions which made the language more balanced in my view.

I'm enough of a purist to be annoyed whenever I see the "expression took too long to type check" error. (I think bidirectional type inference isn't worth it with Swift)

The gaggle of verbose pointer types makes me want to switch to C++ whenever I have to deal with memory directly.

As the article mentions, a bunch of features were added for the sake of SwiftUI. Function builders allow SwiftUI's syntax to be minimal. They allow you to write:

  VStack {
     SomeView()
     AnotherView()
  }

  VStack(
     SomeView(),
     AnotherView()
  )

Then there are property wrappers, which wrap struct/class fields with get/set code (IIRC Lattner didn't like the property wrappers). They've been partially replaced in SwiftUI by macros. The @Observable macro (probably the most widely used one) decorates your class with code that notifies listeners (almost always SwiftUI) of changes. I'd be curious to see what SwiftUI would look like without property wrappers (or macros).

I think they had a missed opportunity to really add robust updating of views in response state changes. Currently it's still relatively easy to not have your SwiftUI views update because your data model uses some object that isn't @Observable.

I wrote a UI library inspired by SwiftUI, but in Rust [1], and of course I couldn't add anything to the language, and more experienced Rust programmers discouraged me from using macros. So it can be done without all the extra stuff Swift added.

[1] https://github.com/audulus/rui

Used to think Swift was the future given the resources Apple could throw behind it, but at its current state after 10 years I no longer do. It will remain a mainstay thanks to the Apple ecosystem, but don't see its popularity extending far beyond that.

The rate at which the Swift language has changed just in the past 3 years feels as significant as the rate at which it changed between 2016, with the release of Swift 3, and 2022.

I'm sure that people who are 100% all in on iOS development feel like the rate of change is delightful, but for the rest of us who have other responsibilities, it's exhausting and bewildering.

1) overload the keywords you do have to mean random unrelated things depending on context (which is why "static" in C++ means a bunch of random things), or ' 2) create context-dependent keywords (e.g. "final" in C++ and "match" in Python), which work, but complicate every parser everywhere.

As much as it pains me to type the following: JavaScript got it right. The initial version of the language reserved a number of keywords (e.g. "class") that would only become useful two decades later.

I can't share the author's enthusiasm for Swift on server either. WASM support is not production ready so Cloudflare workers or Deno deploy is out. Vapor is the only properly maintained framework I can find (happy to be corrected) which I did not find ergonomic. Google Cloud Functions or AWS Lambda would be options but there's no reason to limit oneself when Rust is production ready on most web platforms.

[1] https://stackoverflow.com/questions/56433665/what-is-the-som...

The static concurrency checking stuff is cool on paper but has so far just introduced noise to our codebase so we’re not touching it until it cooks a little more.

I’m basically asking for the same thing I was 5 years ago though and the author touches on, fix the compiler issues.

Official Android support would be nice too but the community is filling the gap there.

I use Rust a little on the side and tooling, compiler messages and ecosystem are far ahead of Swift. Language wise I still prefer Swift for the work I do.

If Swift compiled five times faster, I would want for very little. But I don't know how they'd walk back the combination of type-based overloading and implicit conversions. See: https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Ov...

I'm a Clojure developer, have been exclusively one for the last 10 years and have no intention of changing anytime soon (in other words, I don't care/follow closely what the majority of development world is and what the trends are). A few years ago we had "Open Source is Not About You" [1] by Rich Hickey, basically pushing back that the creator(s) of Open Source don't owe anything back to the community. That piece has aged well for me: now I understand that something is what it is, not what I wish it was. And more importantly, the goal of open source isn't to be liked or used by everybody. It's a thing put out by its creator for others to use, and that includes Apple.

So really, why does the governance matter so much? If you don't agree with something, why not fork it and make it like you want it?

[1]: https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

The complexity is very manageable, a decent Java, Objective-C or .NET developer can pick it up in less than a day, is feature-packed and stuff just make sense.

The problem I have with it is that some decisions are very ideologic.

You can easily link to C libraries for example, but the pointer types in Swift are so fucking unusable (because pointers are evil) that it makes no sense to try it. (unless you cannot chose an other language)

Same with Java and Kotlin on Android, .NET and C++ on Windows, JavaScript on the Web, ISO C on UNIX/POSIX, Go on Docker/Kubernetes,....

The devs here are a lot more nuanced than the guys on Reddit lol

Decisions are made openly with excellent (if exhaustive) discussion, clear reasoning, and mostly on the merits.

Features are building on prior features over the years, and when things have needed to be changed or deprecated, they get changed. So the language is alive but not encrusted.

Decisions are made much more independently and quickly than Java, which has a similar installed code base and motivated corporate patron. Both small-scope and sweeping architectural changes work through the evolution process pretty quickly.

All languages starts with a clean sweet spot but major gaps, and then migrate to common features as they age. Right now, Swift has probably the most mature concurrency plan of all languages, and is beginning to address the lifetime issues presented by value types.

No other language blends low-level efficiency and control with high-level type-safety so well - no less seamless inter-op with C/C++, static macros, etc.

What's not maturing as fast: third-party libraries ecosystem because most people just need Apple's, Windows support (because - why?), and alternate IDE's, static analysis, etc.

As for 217 keywords, etc.: be glad there's a name for everything, without a plethora of ways to do the same thing. If it weren't easier to do complicated things with a correspondingly complicated language, everyone would be writing functional lisp code.

The real problem now is there's no real agreement on how to do the function coloring, effects, traits, etc., but that's what's needed to make use of modern hardware.

In particular, the type system being bidirectional has made it both pleasant (when it works) and painful (when it doesn't), and stuffing all this new behavior into a type system constraint solver is a bit of a black art. Venn diagrams and verbiage aside, it's just hard for people to think about, e.g., what ~Copyable means for generic parameters, or how a parameter can place a function in a different memory region.

But they'll do it after a boatload of discussion, and then make a dumbed-down happy-path 10-minute video for WWDC with code folks can play with - 10 million folks.

If anything, the language is strangled by history, but remains attractive because the team does such a good job.

I'm sure they're aware of the compile times. If they can make C++ interop work (not easy), they can make Mini-Swift :)

As for this governance talk - I can only shake my head at these attempts to start drama. I don't understand it.

I'd call it the impurest incentive of all.