Hacker News Reader

Comment by elpakal | Hacker News Reader

> current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy)

I agree, but I'm telling myself this is only a temporary pain caused by the changes for supporting Swift 6 language mode. Are you talking about something else?

View on HN

Temporary but measured in years and forced on every Swift dev out there … hard to dismiss.

My comment was not about that though, I was more thinking about the super slow build times, unreliable SPM with strange limitations, Xcode still shows errors while reporting a successful build, Previews not previewing, etc.

Don’t forget our old friend “The compiler is unable to type-check this expression in reasonable time”

Is this still a thing in Swift? I loved Swift 1, spent a couple of days upgrading to Swift 2, a week or more for Swift 3. At that point I just switched to React Native. I understand that iterating is generally a good thing, but the constant cykle breaking changes in the language was just too much.

Yes. It feels like the language is being handled by academics who don't actually use it, Swift 6 really drives it down.

The lack of Sendable support for Combine and half-assed support on Async Algorithms only makes it more painful to transition at this point in time.

It's now almost a full year since Swift 6 (concurrency) was introduced, and I've spent a lot of time rewriting, debugging and generally tweaking things to make the compiler happy... The promise of "strict concurrency" is yet to yield any meaningful benefit, despite the huge cost of having it.

I think the pursuit of some kind of semantic purity in the Swift language overshadows more practical needs and concerns. Making Swift too different from its neighbours like Kotlin and Rust also makes it harder to context switch. It now takes a lot more time and effort to get into the flow of developing native things for iOS...

Disagree about the academics point but Async Algorithms is basically an abandoned project at this point. There is someone working on it but the intention is that it evolves basically at the pace that the language does, but without the investment that the language gets. I would recommend against relying on anything going on there.

Between a dead Combine that no longer functions in Swift 6 or a severely handicapped AsyncSequence lacking basic features, where are developers supposed to turn to?

All these projects like Async Algorithms, AsyncExtensions, Asynchrone, etc. are being born out of necessity.

Deprecating Combine would be less of a problem if Sendable wasn’t a hard requirement but it is.

I mostly write these things by hand when necessary which sucks but at least I know what is going on with them.

Are you talking about Combine or Async Algorithms? This has been brought up before about Combine, but AA's repo still has some recent commits.

No, I'm talking about the latter. Combine is truly dead but the other repo is mired in an inability to make real changes, because that requires significant review effort, which is not really there. So it's just bugfixes and small tweaks.

Let's not forget the absurd insistence on "will change" semantics in onChange() instead of the far-more-useful notification "did change."

And of course the brain-dead design of withObservationTracking, which only fires on the FIRST change of a value. I mean... by what definition is that "tracking?" It's goddamned useless, unless of course you implement the clumsy workaround of re-establishing observation tracking every (first) time it fires.

Then there's the bizarre hypocrisy of evangelizing the "single source of truth" while telling everyone to prefer structs over classes in Swift. But structs are COPIED everywhere, which of course breaks the "single source of truth" on the first function call.

I wasted so much time trying to conform to these "best practices" until I finally realized that the people promoting them don't know WTF they're doing. Then I went back to classes, injected the "single source" everywhere it was needed, and got to work adding functionality.

And let's not even get into the half-assery that is SwiftUI... still, all these years later.

For context, I was saying that same thing in 2017*, because it seemed obvious, especialy given the elite consensus was it was obvious SwiftUI was being introduced to allow full cross platform development, including web.

In retrospect, I was starstruck by the people I learned programming from, and Apple Neue funds software engineering, especially developer tooling, to the point it is not actively harmful, as opposed to not painful, and very opposed to not-harmful-and-not-painful-on-not-our-platforms.

* Of course, not for Swift 6 Language Mode™, the thing is, there's always been a Huge Project that's launching, but not landing...

Web was never part of SwiftUI story, where does that come from?

You're absolutely right, never made any sense.

I'm not comfy calling out specific names, but the sort of luminary who would have been featured on Daring Fireball over the years proposed this and took umbrage to this being pointed out at the time.

I can think of 2 off the top of my head who specifically did this, one who went on about it until they saw SwiftUI x macOS 1.0 and that became their new drum to beat on. (i.e. the quality was low)

Reply on news.ycombinator.com