Isolated(any)

nshipster.com

24 points·peterspath··4 comments

This feels like a great example of how wildly overcomplicated Swift has gotten in the past few years. I'm not sure exactly what the right time for Swift to have said 'enough' might have been, but I do know it needs a Snow Leopard [0] release.

In particular, I'd love to see the language designers spend a year simply improving compiler error messages. I don't spend a lot of time building iOS apps these days, and the inscrutability of the compiler's messaging turns that into a vicious cycle.

[0] https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard

They are actually working on that now with approchable concurrency[1].

[1]https://github.com/swiftlang/swift-evolution/blob/main/visio...

I think Swift Concurrency is a great idea that unfortunately wasn't executed very well. The motivation behind it is that concurrency is difficult to understand and tricky to get right, but Swift Concurrency is at times even more difficult to understand and has even more pitfalls and gotchas compared to old-school synchronization primitives. I don't know where exactly it went wrong but it does feel that they really overcomplicated this feature.

And thus grows the ever increasing list of reserved keywords in Swift. All for a badly designed feature. Along with another pile of crap on top, approachable concurrency, that will still work weirdly and be prone to so many bugs and impossible to understand behaviours.

Swift's insistence on having NIH syndrome made them ignore all proper concurrency management systems of the past fifteen years. What's that, structured concurrency, Erlang's lightweight processes, Project Loom, goroutines? all better concurrency systems than anything Apple has ever put forward, all publicly available in the form of implementation or research paper years before.

Reply on news.ycombinator.com