I feel the same. Apple software quality certainly hasn’t increased. Years back I remember some apps crashing suddenly after updating MacOS. I checked the binary and saw they’d started adding Swift.

Half a decade later it seems like it should be better and Swift stuff should be stabilized. But nope, I’ve had more little glitches in both iOS and MacOS. It’s hard to say it’s due to Swift, and not management priorities. Still it feels partially related to Swift.

Swift’s goals are great, I like the syntax, but the language implementation seems to just special case everything rather than having coherent language design.

That and Swift de-emphasizes Obj-C message passing. I have a pet theory that message passing produces more robust GUI software that’s easier to adapt to complex needs.

Software written in a simpler language like Objective-C - verbose, fast to grok and fast to compile is actually more maintainable in the long run than a so-called "developer friendly", humongous, complex and slow-compilation language like Swift.

A lean language reduces the surface area for beautiful expressiveness by clever people - making sure the dumb/junior guy who is maintaining your project in the future can actually fully understand what is written. And it can build and run fast - so you can iterate and test out software behaviors fast.

No one in this world is immortal. If it takes too much time to grok code, write/compile/run tests - a developer will be disincentivized to do so, no matter how amazing the language features are.

My guess is that Swift has adversely affected Apple's overall software quality. As more software moved from Objective-C to Swift, quality has dropped precipitously.

As someone frequently flipping between Swift and Kotlin, while I don’t necessarily feel like Swift is massively superior, I often find myself thinking “why is this so quirky and pedantic” when writing Kotlin.

For example, I really really wish Kotlin would adopt Swift style if let/guard let statements. Kotlin smart casting doesn’t work just often enough to not be able to consistently rely on it and the foo?.let { } syntax is ugly.

Combined with the JVM warts of gradle and jankiness of code stripping and obfuscation, generally speaking if I could opt to use Swift in place of Kotlin for Android dev I would do so in a heartbeat.

I have been skeptical of Swift ever since I heard the original goal was the one language to rule them all from Assembly to Javascript. When something is too good to be true it probably is. But I have also given Apple plenty of benefits of doubt.

It seems Swift 6.2 is still unfinished and is acting more like Java. Eternal evolution of language. While it is popular among tech and HN crowds to have new language and framework to play around and work. It brings particular little if not negative user experience in terms of final products. I often wonder if Apple could just have some light touches of improvement on Objective-C in the past 10 - 12 years and instead focuses on actual OS and Apps quality.

It is this lack of focus that has been with Apple since Steve Jobs left.

It's second system syndrome combined with the fact that Objective C and the NeXT underpinnings were put together by a team of truly the greatest minds of a generation.

Swift was put together by some great minds, and some minds, Apple still attracts talent, but in far lower density. This isn't even a jab, just from the fact that they are far larger and the talent pool is smaller with far more competition.

What percentage of genius level developers want to work for a company where they can't talk about their work and generally get zero public credit?

Good code is just one of many ingredients to great software, and programming language is a small factor in good code.

Swift was never going to make Apple software great (nor Go or Rust or anything else for anyone else).

Though, honestly, if you're thinking about computer languages in terms of cool, you're going in the wrong direction.

It’s easier to write more robust code with Swift, but if Apple don’t prioritise quality, the language can’t fix that.

Swift wasn't designed to solve any of the problems Apple engineers had writing customer-facing software. It was a shiny new language which could be marketed to third parties as something modern and familiar, unlike Objective-C with its odd mix of C and square brackets.

Surely developer productivity and maintainability have increased from the ObjC days, no? Swift criticisms aside, it certainly allows access to more ergonomic high-level coding patterns.

This might just be the long term effects of a platform dominated by people who generally value hardware over software.

Agree on Paul Hudson being great, but not so much on the guiding around the pitfalls. One big issue with the Swift community in general in my opinion is that a lot of the community content is incredibly shallow. Most of them are fine with "there's this feature and you can do X with it, cool right?" style-content, meaning very few people actually take the time to explain what the trade-offs are / performance considerations / how things work under the hood, and IMO this took a huge negative hit in the average skill level of Swift developers.

Agreed about Paul Hudson. He also just seems like a genuinely nice guy. I was kind of shocked to receive an email from him out of the blue last weekend (well, from GitHub, but with his name in the "From" field). Turns out it was about a PR [0] to one of my packages where he fixed typos in the README.

[0] https://github.com/visfitness/reorderable/pull/2

The last sentence is exactly how I would describe Paul Hudson, as a HwS reader/user.

You might mess up 403 vs 401 in this system, but then in the next system you're messing up Unauthorized vs Forbidden.

It's like when you see a poisonous snake and can't remember if "red touches yellow" is paired with "deadly fellow" or "friendly fellow".

> case _401 or case error401.

I'm not seeing why it's worth a whole language feature to avoid prefixing strange identifiers.

> Just use semantic names like `HTTPStatus.NotFound` and you wouldn't have a problem in the first place.

Have to disagree there: when I tried re-implementing a basic websocket server in multiple languages (https://news.ycombinator.com/item?id=43800784), I found it so frustrating when they'd insist on hiding the raw close-codes behind pretty names, because it meant having to stop what I was doing to jump into the documentation to figure out what pretty name they gave a particular close code.

All I wanted was to return 1003 (https://datatracker.ietf.org/doc/html/rfc6455#section-7.4.1) if the websocket sent a string message, but:

- Dart calls this "unsupportedData" (https://api.dart.dev/stable/latest/dart-io/WebSocketStatus/u...)

- Java-Websocket calls this "REFUSE" (https://javadoc.io/doc/org.java-websocket/Java-WebSocket/lat...)

- Ktor calls this "CANNOT_ACCEPT" (https://api.ktor.io/ktor-shared/ktor-websockets/io.ktor.webs...)

And some others:

- .NET calls this "InvalidMessageType" (https://learn.microsoft.com/en-us/dotnet/api/system.net.webs...)

- libwebsockets calls this "LWS_CLOSE_STATUS_UNACCEPTABLE_OPCODE" (https://libwebsockets.org/lws-api-doc-main/html/group__wsclo...)

Just... why? Just call the thing 1003 and link to the spec.

Yeah, the feature is mostly about test cases and macro generated code. The numeric property names are far less useful, as the good syntax requires tick marks: .`404`

Yeah, this feature seems wholly unnecessary and possibly dumb. The example given is ridiculous.

If you can't figure out what stripHTMLTagsFromString() does, you have way bigger problems than a lack of spaces.

As he mentioned in a forum post some years ago, Chris wanted the language to be more modular, but Apple's drive for adding features to it sets very different priorities.

To be fair, every new language version usually includes things that eliminate those special cases making writing the code more straightforward. Like the described support of functions in key paths, or the ability to set default global actor isolation.

I wonder why the author left Go out of his list of examples of language stewardship.

how can the next great language avoid the trap of syntax bloat while providing the same extraordinary functionality

The Swift language team has recently open sourced swift-build, and the community's assumption is that it was done in order to eventually move everything away from xcodebuild to swift-build, which would let you build an app from swift packages and fully break from Xcode: https://github.com/swiftlang/swift-build

You are talking about the language but bringing up an example of creating an app for an Apple platform. Regardless of the language you will have to create app bundle structure, copy assets inside, add mobile provision and sign it.

If you ask me, those platform specific things should never be integrated part of the language.

I'm confused. You said "none if it plays nicely with Xcode" but then you complain about what the experience is like when not using Xcode.

> None of the decision-makers seem to have the sense or incentive to say "no" to anything.

How could you know that? Not all the 'no's show up as a proposal. The proposal template also has an "Impact on ABI" section which you can use to guide your "can I ignore it"-sense.

> It sure feels like Swift governance is broken.

What is the actual problem though? Not enough features that you would use? But I don't see how this is a governance problem

Java governance: slow at times but mostly sane. C++ governance: I won't even open this can of worms. Swift governance according to you: too many features I will ignore.

That's a matter of taste.

I enjoy "bloated" languages. Many languages are bloated nowadays, but the community agrees what set of features to use, what to avoid. Still, those rare features can be useful for stuff like making DSLs through clever use of the language.

It's much worse to have a minimal language that takes years to add new features, like how Go took over a decade to add generics.

There’s a section in the proposal about this: https://github.com/swiftlang/swift-evolution/blob/main/propo...

Tl;dr: Sequence and Collection are incompatible with noncopyable types and conditionally conforming when elements are copyable would result in too many implicit copies. They’re working on protocols to cover noncopyable collections such as this, which will probably have a similar API shape.

Swift's become so feature-heavy, and complex, whilst the documentation is all over the place. That's not even counting things like SwiftUI, or its rather arcane CLI tooling.

Out of curiosity, I put in more than 150 genuine hours in 2024, trying to get deeply into Swift - and eventually just abandoned the language.

In comparison - I got very far experimenting with Go in the same amount of time.

Unless one needs to get into the Mac ecosystem, I see no reason why learning Swift should be necessary at all.

I can’t speak to swift, but in experience with many other langs and runtimes I will say that single-threaded business logic by default is still the only sane choice even today. There are exceptions both on client and server side, but you get so incredibly far with one thread, while eliminating so many potential bugs, that it’s borderline whether parallelism should even be exposed to application developers at all.

Even in Go which has my favorite parallel concurrency model, there are many footguns and needless walking on eggshells for business logic. You can still offload IO and bespoke compute to other threads when it makes sense. This view isn’t a panacea, but damn close for the 99% of use cases.

Coincidentally I also think the early success of JavaScript an largely be attributed to single-threaded run-loop and callback-oriented concurrency. Even on the server JS is still holding strong with this limitation, and that’s despite all the other limitations and insanity of JS.

Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.

Apple effectively solves the problem which doesn't exists.

Before Swift 6, I've worked lot of unique projects both macOS and iOS and never spend time on debugging. I don't know what debugging time exactly?

Everything probably already is or should be

which is better?

I find 'simple' languages charming. Hence, I still like Objective-C. I also like Lua a lot.

I liked Swift when I tried it a couple of years ago, but it seems overloaded with features these days. I haven't tried Swift UI yet, but I did think the Objective-C approach with xibs, struts and such worked fine.

I don't use the new concurrency features, as they are one of the main culprits of this mess. (so stick with 5.x)

SwiftUI is a wreck, that is still not good for advanced UI and you still have to use UIKit for some parts, and

Taking Objective-C, with DispatchQueue, and some modernization of it, and some new data structures, which it need, was all it was needed to make a good new langue.

It could have been Apple's rival to GoLang, but instead it ended up being hydra/monster with too many pardagimns, and none of them are good.

My guess is you've encountered issues with actor isolation made suddenly explicit in your language upgrade. This is exactly what's addressed in Swift 6.2, so it won't be nonsensical in that case. Speaking from my personal experience of trying to upgrade and stopping.

The moment this language version is released I will move to Swift 6. In our project case it will happen. with no source code changes.

Rust doesn't keep adding features like Swift is. There is a lot of stabilization happening.

Isn't there some contradiction in your comment, I would have thought that distributed programming is precisely the thing that server side programming needs most?

Academics value simplicity and fundamentals… Swift with its timeouts smells of Big Company incentives where everyone wants to make a contribution and management that see themselves as babysitters instead of product creators with competition.

  > or are so enamored with the actor paradigm (erlang)

maybe you're referring to structured concurrency?

It’s opt in. Very explicitly opted in. Did you read the post? Because it improves actors and makes it easier for app devs and general programming use cases. Honestly I don’t get the “sky is falling” mentality towards swift because a feature they won’t use or are affected by is added.

“Due to these insane changes” Which changes?

> Truly incredible that they not only defaulted, but LIMITED change-detection to WILL-change

That's not strictly true. You get the new value inside the closure. This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI. Before you had to write the code like this to achieve that:

func startObservation() { withObservationTracking {

        print(store.state.toggle) // Here we have the new value (+ it is called once before any change)

    } onChange: {
        Task { startObservation() }
    }
}

There is a two parameter onChange modifier btw

It just seems to me that this is the exactly wrong way to solve a programming problem. If the problem boils down to "I want some variables (almost always test function names) to be more human readable", the solution should never be "hey let's add this feature to the core language and make identifiers use any ASCII string! I dunno, maybe I'm wrong here and being overly critical. But to me it just screams "Swift has lost the plot."

Tests are never called explicitly by programmers, or at least they never should be. You could argue that they don’t really need to be functions at all, just pieces of code that represent tests.

Naming things is hard. If you can more accurately describe your test and not think of a separate name for it I'm all for it.

Also I like the backticks better than what zig came up with: @"404"

I don't know about other languages but Ruby is similar in that you can name a function with any string (though you might not be able to call it in the standard way) and the Rails default test framework takes advantage of that.

The feature is fine but there are better reasons to introduce it.

For macro generated code it is convenient to use identifiers that people won't accidently use in their own code. The ability to use arbitrary identifiers solve that.

This is useful for testing. Currently, I need to write both the string name of the text and an identifier based on that name for the function itself. Soon I will only need to write it once. This is not much useful for much else though, and just because you can write code like this, it does not mean you should.

Kotlin has this, but it's basically only ever used for tests. I've never seen a real world method with a backtick name.

Many of these features have convoluted-sounding names like "global-actor isolated conformances" or "control default actor isolation inference," but they are changes that make actually using the language simpler.

People aren't expected to really learn that there is a "feature" called global-actor isolated conformances, but at some point they'll try to make a UI type conform to `Equatable,` and instead of an error saying you can't do that, they'll get a fixit about needing to specify the conformance as `struct MyUIType: @MainActor Equatable` instead.

I bet 99% of codebases won't use "method and initializer key paths," but there's really no reason why you should be able to get a key path to a property, but not a method. It just hadn't been implemented yet, and the language is more consistent now.

Personally, I think raw identifiers are kinda dumb, but that just means I won't use them. IMO there isn't really more cognitive overhead when using the language because it's possible to use spaces in function names now.

I too wish deprecation with migration path was a more common pattern in today's language development. The language has very much needed work and the numerous bugs within Apple's own libraries certainly hasn't helped.

That said, some of the, erm, "new ways" to solve problems have been significant advancements. EG: Async/Await was a huge improvement over Combine for a wide variety of scenarios.

Yeah, I’m not an active Swift developer. But reading this article about all the existing complexity and all the new complexity in this update makes me think Swift has jumped the shark.

So it's becoming C++?

Is having too many ways to solve a problem an issue for solo indie developers?

I use it as a C++ alternative on Linux. We ported a substantial code base from C++ to Swift last year and it works great. Performance is better in some places, comparable to C++ in others. Productivity is definitely improved over the C++ codebase. We didn’t use rust for this project after evaluating how that migration would impact how it was designed internally, and we decided it wasn’t the right way to go. I think the “swift is only relevant in apple ecosystem” view is inaccurate these days. Swift certainly isn’t the answer to every project, just like rust or any other language isn’t the universal answer to every project. It’s worth considering though if it is appropriate.

There’s a level of self fulfilling prophecy here: people don’t use Swift off Apple platforms because there isn’t a critical mass of people using Swift off Apple platforms.

But that said it can be frustrating. A lot of the documentation and tutorials you find out there assume you’re on an Apple platform where, e.g. Foundation APIs are available. And the direction of the language, the features being added etc, very clearly serve Apple’s goals.

(Side note: IBM was an early adopter of Swift off-platform but then stepped back: https://forums.swift.org/t/december-12th-2019/31735)

Apparently Arc Browser is written in Swift: https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc...

Also using it in an embedded Linux project [1]. 75% of code written for this project is Swift. The rest is Dart and C/C++. It’s a productive language.

[1] https://forums.swift.org/t/an-embedded-audio-product-built-w...

Generally only useful within the Apple ecosystem is definitely inaccurate.

An example: https://vapor.codes/

The problem is that people only think it’s generally useful in the Apple ecosystem.

Unlike Rust, it has some C++ binding, which is extremely useful.

For hobby programming at first I picked Java for the alternative to C++ and then Swift since 10 years. I really thought Swift language is the one which going to replace the Python. How dump I am. It's supposed to be. Because of SwiftUI, the direction of Swift language changed. The so called open source label is not fit to the Swift language. May be we can call it as free programming language by Apple.

I used vapor server also and now I think that Swift really has advantage for cross platform development. Just because of SwiftUI they've to adopt nonsense updates. IBM took greater decision on Kitura.

Vapor is still with Swift version 5.9; Let's see how it's ends.

You can't really say a language with a garbage collector (Swift) is an alternative to one without (Rust, C++, etc), because a lot of the time, the reason someone is using a non-GC language is because they don't want a GC.

EDIT: Yes, ref. counting is garbage collection, before the replies blow up. haha

Seriously, smart people making dumb decisions.