Honest question. Not trying to troll. One of the pitches in the earlier days was “C/Objective-C OK, but you can’t write safe/next level code with it—-Swift will close that gap.”
N years later, it doesn’t feel like there has been a step change in Apple software quality; if anything Apple software feels less solid, and looks cool “look what I did” extension points. I mean, some of the tings you could do with runtime categories, and runtime prototypes were really cool. Now when I work on my 2 apps that originally happily port to Swift/UIKit, I’m just left confused with how to make things work. I’m happy when it finally works, and don’t ever try to improve the thing, it’s too much work.
There’s lots of different variables at play here; I’m not trying to stretch inference too much. Heck, it could have been that with adding Swift to the mix, the forces that have contributed to reduced quality in Apples stuff would be even worse.
I’m just frustrated. When I work in Elixir, I’m like this is cool. When I work in Kotlin, I don’t feel like “Apples got a language like this too, but it’s got that extra special zing that used to make stuff Apple touched cool.”
elcritch · 32d ago
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.
ardit33 · 32d ago
It is not just the language but the frameworks. SwiftUI is a wreck, and still not mature even after 6-7+ years in 'production'. You still have to drop to UIKit to do advanced UI, and for what it is, SwiftUI is just not practical enough for cases that are not trivial.
The trouble is that all new kids/engineer are learning it first, which means software wont get better. Apple need to improve it first, and I don't see advanced folks ditching UIKit anytime soon for advanced UI.
LudwigNagasena · 32d ago
Seems like another case of the general trend in software development of easy things becoming easier and hard things becoming harder.
interpol_p · 32d ago
I don't completely agree with you. Having used both SwiftUI and UIKit extensively, I value both of them and think they are both quite strong in different areas
I have published a word game written entirely in SwiftUI [1], the effects and animations would have been much more difficult to do in UIKit, and the app itself would have been hairier to write and maintain [2]. I also track crashes, and this particular app has had four crashes in the past year, so I am very pleased with the stability
That said, there are definitely times, as you say, where you have to drop to UIKit. For the word game mentioned above, I had to drop down to UIKit to observe low-level keyboard events in order to support hardware keyboard input without explicitly using a control that accepts text input
SwiftUI is mature, it's pretty advanced — especially for graphics and animation heavy UI. It has limitations, particularly around advanced input event handling, as well as the application/scene lifecycle
I plan to continue to use both UIKit and SwiftUI where they make sense. It's easy enough to bridge between them with UIHostingController and UIViewRepresentable
[2] Specific examples include: image and alpha masking is trivial in SwiftUI, Metal Shaders can be applied with a one-line modifier, gradients are easy and automatic, SwiftUI's Timeline+Canvas is very performant and more powerful than custom drawing with UIKit. Creating glows, textured text and images, blurs and geometry-based transitions is much easier in SwiftUI
krzat · 32d ago
What baffles me the most is testability of SwiftUI. It simply does not exist.
sunnybeetroot · 31d ago
This is true, I wonder what Apple uses internally to test SwiftUI.
firecall · 32d ago
That’s a shame!
I haven’t used Swift UI in a couple of years, but I always thought the basics of it were excellent.
They got the declarative API foundations right I thought.
Shame it’s still flakey.
The preview used to crash constantly last time I used it.
cevn · 32d ago
I have a good bug right now. My wife bought a Macbook Air. I use High DPI and she does not. It is impossible to switch between users in this situation, one of the core functionalities of the computer is just broken. Makes me wonder if anyone at Apple uses these computers..
eptcyka · 32d ago
No one tests multi-user functionality, afaict.
deergomoo · 32d ago
It’s insanely buggy. My wife has two user accounts, one for her work and one for everything else, so she can switch out of the work user at the end of the day to put it out of her mind.
She comes across bugs on the regular that I’ve never seen in 16 years of Mac use, but only when the other user account is logged in (i.e. quick user switching rather than a full log out).
Stuff that user accounts shouldn’t even make any difference to, like the menu bar disappearing or rendering too far up so it’s half off screen. Save dialogs stop appearing. Windows that are open but appear to be rendering off screen somewhere. It’s wild. This is on a < 1 year old MacBook Air running the latest OS. It’s an absolute shambles.
jonhohle · 31d ago
His has been my experience as well. The changes from System Preferences to Settings have been an abomination. Previously we had uniquely designed layouts for each setting. Now everything is a list. Now menus scroll without any indication that there’s more content. “Sheets” are no longer resizable and take up the center of the view. User space networking (cool) hangs while pegging one CPU (lame). Everything requires special permissions and several times a month I’m having to figure out why a program can’t access something. Writing programs forces using Swift UI APIs that don’t have equivalent functionality to their App Kit versions.
After over 20 years, I’m really unhappy with macOS. The last five years have have been a huge productivity regression.
hombre_fatal · 30d ago
I created a new user on my macbook for my girlfriend when her laptop broke, and she could see my files in the “Recent files” tab. I’m not even sure if there was a separation of files. And I have no clue what the intended boundary is supposed to be between users.
I made a new user for Zoom screen share and was equally confused when my personal files and info would show up in searches and such. And it seems like most things install globally?
Ended up using a whole new computer to have a clean screenshare environment.
crossroadsguy · 32d ago
Has Apple been testing anything in the last many years?
90s_dev · 32d ago
How much they can get away with.
cevn · 28d ago
Lmao!! Thank you for that laugh.
frizlab · 31d ago
That doesn’t mean much. Swift is new. Usable Swift even more so. All of the apps Apple propose have legacy. New apps from now (e.g. Invites) will be much more interesting.
rcruzeiro · 32d ago
> 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.
This could not be furthest for the truth. The entire process of proposing a new language feature to getting it implemented and shipped is out in the open for everyone to participate/see.
What’s that got to do with coherent language design? Just because it’s somewhat open doesn’t mean it has consistent design. Then by all accounts Apple just forced through language changes needed for SwiftUI.
rcruzeiro · 32d ago
I agree that that is the one counter example for the above. Apple forcing the closure syntax to better cater to SwiftUI left a sour taste in the mouths of an entire community.
msie · 32d ago
Too many cooks!
codr7 · 32d ago
And no Steve Jobs to pull them down to earth.
saagarjha · 32d ago
Steve Jobs, of course, was always involved in the details of programming languages targeting his platform.
flohofwoe · 32d ago
He would probably raise hell about the state of the new macOS Setting window though. How this thing made it through QA remains a mystery.
elcritch · 31d ago
He really was involved. As I understand it Obj-C was championed by him. NextSTEP was largely software related:
I still feel like GUI programming hasn’t progressed in the years since this. Actually they’ve regressed in many ways.
codr7 · 32d ago
I wasn't there so I can't say for sure.
But my impression watching from the outside is that he had a finger in every pie.
mdhb · 32d ago
Conversely, Dart does the exact same thing and is probably the best designed language I’ve ever come across
SpaghettiCthulu · 32d ago
Best designed? Really? Support for something as basic as consistent integer types across platforms is non-existent.
lenkite · 32d ago
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.
interpol_p · 32d ago
It's easier to read and navigate a well-written Swift codebase than a well-written Objective-C codebase
Conversely, it's easier to debug an Objective-C app than a Swift app, simply because compiling and debugging is so much faster, and debugging so much more reliable
I don't know about a software quality drop being attributable to the migration to Swift. So many other things have also happened in that time — much more software that Apple produces is heavily reliant on network services, which they are not very good at. I find Apple's local-first software to be excellent (Final Cut Pro X, Logic, Keynote) and their network-first software is hit-or-miss
They have also saddled developers with a ton of APIs for working with their online services. Try to write correct and resilient application code that deals with files in iCloud? It's harder than it was to write an application that dealt with only local files a decade ago!
Swift is easy to blame, but I don't think it's responsible for poor software. Complexity is responsible for poor software, and we have so much more of that now days
zozbot234 · 32d ago
There's a limit to how "lean" a safe, low-level language can be. Rust is leaner and simpler than Swift but not by much, and pretty much all of its outward features are "load bearing" to a far greater extent than Swift's.
(People have tried to come up with simpler languages that still preserve safety and low-level power, like Austral - but that simplicity comes at the cost of existing intuition for most devs.)
cosmic_cheese · 32d ago
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.
joe_fishfish · 32d ago
Ha, I switch between the two as well, but I feel the opposite. Kotlin is much more intuitive for me, and Swift is more clunky. I do miss guard lets in Kotlin, but that’s about it.
Skip tools is pretty cool and I very may well use it for at some point, but it works by translating Swift+SwiftUI to Kotlin+Compose and I’d prefer a more direct approach that lets me build Android binaries with Swift (preferably with the whole of UIKit available, though that’s not likely).
dlachausse · 31d ago
From the FAQ…
> Skip supports both compiling Swift natively for Android, and transpiling Swift into Kotlin. Read about Skip’s modes in the documentation.
Yes, it transpiles a Swift+SwiftUI codebase into a Kotlin+Compose codebase. I don’t want that intermediary step, I want the Swift itself running on Android.
dlachausse · 31d ago
> Skip supports both native mode - in which your Swift is compiled natively for Android - and transpiled mode - in which your Swift is converted to Kotlin. The mode is specified at the level of a Swift module. Each mode has strengths and weaknesses, and it is common to use both native and transpiled modules within a single Swift-on-Android app.
The ?.let syntax is terrible. I don’t see how anyone thinks it’s better than doing a normal if != null check.
renewedrebecca · 31d ago
Feels like a lot of people like making dealing with null as complicated as possible.
cosmic_cheese · 31d ago
The only time I ever use it is when the if != null check doesn’t work (aforementioned smart cast failure) and I don’t feel like creating a local var to fix it.
ksec · 32d ago
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.
zozbot234 · 32d ago
> 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
You can have both. Rust feels "mature" and "finished" if you stick to the stable featureset, but it's still bringing compelling new features over time in spite of that. But this can only be achieved by carefully managing complexity and not letting it get out-of-hand with lots of ad-hoc special cases and tweaks.
saagarjha · 32d ago
Objective-C being stuck in the 1990s forever was not necessarily a good thing.
moltopoco · 32d ago
Stuck in what way? It would have been easy for Apple to make an "Objective-C without the C", where it's still using message passing and the Foundation libraries, but without header files, raw pointers, and all the @messy @syntax. Add little goodies like auto-stringification of enums and so on. I think that kind of superficial cleanup would have been enough to modernize the language. They could have spent the rest of all the time that Swift has consumed on better dev tooling.
zozbot234 · 32d ago
I mean, "Objective C without the C" is just Smalltalk. It exists already. But that doesn't help you if you want any amount of backwards compatibility with the existing ObjC ecosystem. So you're kinda forced to go with the low-level approach.
moltopoco · 31d ago
What would stop Apple's hypothetical "Objective-C without the C" from talking to existing Objective-C code? After all, Swift can use UIKit just fine. Even mixing C++ and ObjC is reasonably easy.
In a sense, MacRuby was trying something similar, but the dependency on a GC doomed it.
lenkite · 32d ago
Umm...Java is extremely conservative in adding new features. Not really sure you can compare to Swift that throws 10x the features in with every major release.
ab5tract · 31d ago
Also, if it hadn’t been (slowly) improving all this time then I would have defenestrated my work laptop, myself, or both long ago.
I’m trying to imagine using it without the stream API just shuts my entire brain down. Records arrived pretty recently and are already essential for me.
You will always have to pay me to program Java, but you’d have to pay me 5x my current salary to do it in Java 8 or earlier.
donatj · 32d ago
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?
jmull · 32d ago
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.
JimDabell · 32d ago
It’s easier to write more robust code with Swift, but if Apple don’t prioritise quality, the language can’t fix that.
panic · 32d ago
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.
jimbob45 · 32d ago
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.
cosmic_cheese · 32d ago
A big one that I feel is under appreciated is how Swift has rooted out nearly all passing around of untyped data, untyped dictionaries, casting without checking, etc in Apple platform projects.
I don’t mind Objective-C when I’m the one writing it and can ensure that the code is responsibly written, but it wasn’t unusual to have to work on existing Obj-C codebases littered with untyped data, casts, etc some amount of which was inevitably erroneous and only seemed to work correctly. Chasing down the origin points of data, fixing a laundry list of method selectors, and adding in checks always sucked with the compiler doing little to give you a hand. With Swift, even in codebases with poor hygiene fixing things is easier since the compiler will yell when something’s wrong.
ab5tract · 31d ago
Just curious, but would it have been feasible to update the Objective-C compiler to reduce these pain points?
Or was there issue more intrinsic to the design of the language itself?
cosmic_cheese · 31d ago
With the caveat that I’m not all that knowledgeable about compilers, as I understand it, no not really. The compiler’s “reasoning” about types is extremely rudimentary and is easy to “deceive” because like a C compiler, it trusts that the dev knows what they’re doing. This can enable an experienced vet to move quickly due to low resistance, but makes the occasional slipups that even vets commit easy to miss.
You’d basically need to implement the Swift compiler in the Objective-C compiler to get similar type safety, but to make it work you would probably need to change various bits of syntax, drop inline intermixture of C and C++, and remove a lot of Obj-C’s dynamism, basically making it a new language. That’s why Swift was created, and in the past Obj-C’s bracketed smalltalk-like syntax had proven unpopular amongst newcoming devs, so they chose a more mainstream syntax instead.
ab5tract · 31d ago
Thanks for this! More or less what I expected, just wanted to be sure.
WD-42 · 32d ago
This might just be the long term effects of a platform dominated by people who generally value hardware over software.
w10-1 · 32d ago
The article doesn’t give enough attention to the glacial but steady changes in the ownership model that will have great benefit in avoiding copies in value types, Swift’s strength and Achilles heel.
I have to say Paul Hudson has almost single-handedly taken over communicating the essentials of Swift to the world; he’s fantastically reliable, brief but enthusiastic, guiding people around the many pitfalls.
rockbruno · 32d ago
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.
saagarjha · 32d ago
I think one of the problems is that the people who are actually using the language features generally don't have time to do it, Apple doesn't do it themselves, and Paul Hudson has 300 new features a year to view. Plus, iOS developers cargo cult harder than any other programming community I've come across, and this generally doesn't work really well if your explanation is difficult to quickly convey.
strongpigeon · 32d ago
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.
The last sentence is exactly how I would describe Paul Hudson, as a HwS reader/user.
sedatk · 32d ago
Free-form identifiers are neat for test-case naming, but not for `HTTPStatus.`404``. I think having `HTTPStatus.Error404` was a bad idea to begin with. Just use semantic names like `HTTPStatus.NotFound` and you wouldn't have a problem in the first place. Now, a single character typo can easily make a 404, 403 and create a bug. It's less of a problem with semantic names.
If you want constrained numeric types in Swift, that's another problem to tackle. But `HTTPStatus.`404`` seems to be the least ideal way to go about it. It lets you do stuff like to declare `HttpStatus.`404`` with a value of 403 too.
hombre_fatal · 32d ago
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".
sedatk · 32d ago
Messing up Unauthorized vs Forbidden is a semantic problem, but 403 vs 401 can be either semantic or syntactical. It’s not like you’d mispress a key and get Forbidden instead of Unauthorized.
monkeyelite · 32d ago
> case _401 or case error401.
I'm not seeing why it's worth a whole language feature to avoid prefixing strange identifiers.
iamcalledrob · 32d ago
I think this is kind of indicative of the Swift approach: if in doubt, add language features that make code look nicer.
Not a fan personally, but Swift is littered with little "niceties" (complexities) like this.
sedatk · 32d ago
I don’t think it’s the sole reason, but I find that example odd for sure.
Defletter · 32d ago
> 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.
Just... why? Just call the thing 1003 and link to the spec.
sedatk · 31d ago
If you don’t want to deal with that, you can just use the number. Some APIs have integer overloads for that purpose, but you can also typecast. I don’t find HTTPStatus.`1003` more helpful than 1003.
Defletter · 30d ago
Many of the languages/platforms/libraries that I used (eg: Bun) do not provide any kind of named-constant for this reason: just type 1003. But the value of named constants is that you can attach documentation to them.
To clarify something I said earlier, I would rather have to stop what I'm doing to look at documentation (something that can be done within the IDE) than have to open up a browser and read through the specification to figure out what some magic-value means. Having a provided named-constant that tells me what 1003 means is very useful for me and for other maintainers or contributors to the project, and it can link to the spec for more information anyway. Just having raw magic-values is not great for maintenance. Likewise, having pretty names entirely detached from the actual close-code makes searching for places where that close-code is used much harder. Even just "1003_REFUSE" or "1003_CANNOT_ACCEPT" is so much better.
jshier · 32d ago
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`
DidYaWipe · 32d ago
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.
finalfantasia · 32d ago
“Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff…”
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.
aatd86 · 32d ago
I wonder why the author left Go out of his list of examples of language stewardship.
singularity2001 · 32d ago
how can the next great language avoid the trap of syntax bloat while providing the same extraordinary functionality
brainzap · 32d ago
By not providing them. Say "sorry, here is an ugly workaround, generate this xy code."
trevor-e · 32d ago
Lot of nice improvements here. I'm actually quite liking the async API after using it in a couple small apps and learning the fundamentals.
I really wish the entire Swift team would spend a quarter fixing bugs and improving the compiler speed, though. So many trivial SwiftUI cases trigger the "this is too complex for the compiler" errors which are so frustrating to fix.
catapps · 32d ago
I've been starting to use Swift again lately after like four years, and while the language is beautiful & the package management story is now a LOT better with SwiftPM, I found that none of it plays nicely with XCode, Simulator, or anything to do with iOS/macOS development -- its primary use-case!
I found myself awestruck that I *HAD* to use XCode or xcodebuild, and could not just run `swift build` and generate an iOS app.
In the end, I had to:
- compile the .app structure myself
- run codesign manually
- manage the simulator manually
- bundle xcAssets manually
- provide swift linker flags manually targeting the toolchain/sdk I needed
- manually copy an embedded.mobileprovision
It was a good learning experience, but what's the story here? Did Apple just give away Swift to the OSS community and then make no ongoing effort to integrate their platforms nicely into the non-xcode build tooling? Looking into https://github.com/stackotter/swift-bundler
seankit · 32d ago
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
tough · 32d ago
yep can confirm swift build works, at least i was able to build a MacOS app and avoid Xcode at all costs thanks to it phew
singularity2001 · 32d ago
yep Swift build Works magnificently but only for Mac so far
tough · 31d ago
ohh gotcha, well hoping it gets linux/win support soon too, it's great!
viktorcode · 32d ago
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.
catapps · 31d ago
Sure, but developing for Apple's platforms is Swift's primary use. I'd say Dart & Flutter is a fair comparison:
As flawed as they are in my eyes, its dev tooling quality is something I appreciate and wish I saw here. There are two CLIs, one for the language (Dart) and one for the framework (Flutter). Some would say that the CLI equivalent would be xcodebuild, but that depends on the complex .xcodeproj/.xcworkspace structure and still requires XCode to be installed.
marcellus23 · 32d ago
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.
catapps · 31d ago
As far as I could tell, if you create a Main.swift file, you can't just open that in XCode and start running it as an iOS/macOS application, and instead have to create a .xcodeproj/.xcworkspace through XCode, and add your Swift to the scaffolded project - this seems backwards to me.
(I then separately complained at all the steps it took to get it running without XCode, as I didn't want to be locked into using it)
marcellus23 · 30d ago
Oh — actually you can create a Swift package and open it with Xcode. You don't need an explicit xcodeproj or xcworkspace.
realaleris149 · 31d ago
Not op, but I think "doesn't play nicely" means does not work so you have to do it in other ways. This has been my experience as well, albeit it was couple of years ago.
jmull · 32d ago
It sure feels like Swift governance is broken.
They're just shoveling stuff in to the language.
Individually, most items aren't so bad, but collectively they've got a mess and it's getting bigger fast.
None of the decision-makers seem to have the sense or incentive to say "no" to anything.
It's sad, because the language had such promise and there are some really nice things in there.
Well, at least it's relatively easy to avoid or ignore.
myHNAccount123 · 32d ago
> 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.
smotched · 31d ago
People like this just complain. Without pointing to anything real or saying anything meaningful. You just have to ignore them like spam.
tempaccount420 · 32d ago
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.
monkeyelite · 32d ago
> InlineArray does not conform to either Sequence or Collection
Why not? Does this mean I need to make a struct which wraps InlineArray and implements Collection? Why didn't they do that?
EDIT: found the answer (I still have concerns):
> While we could conform to these protocols when the element is copyable, InlineArray is unlike Array in that there are no copy-on-write semantics; it is eagerly copied. Conforming to these protocols would potentially open doors to lots of implicit copies of the underlying InlineArray instance which could be problematic given the prevalence of generic collection algorithms and slicing behavior. To avoid this potential performance pitfall, we're explicitly not opting into conforming this type to Sequence or Collection.
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.
saghm · 32d ago
Interesting; if I'm understanding correctly, it sounds like Swift doesn't have a standard lazy iteration API yet? I would have guessed that it did if asked before reading this, but it's good to hear that they're already working on it. Since I feel super spoiled by lazy iterators in Rust, I'm super curious if anyone has more Swift experience and could chime in on if there are other language features or APIs that might illuminate why there wasn't as much of a need for this earlier; my general perception of Swift as an outsider is that it tends to have pretty well-thought out decisions based on factors that I just happen not to know about personally (e.g. compatibility with other parts of the Apple software ecosystem or different priorities due to the domains Swift is often used in compared to the type of stuff I work on personally).
adamwk · 32d ago
There are lazy collections, but they’re not default.
Why the protocols are designed the way they are is until very recently all types were implicitly copyable, but most of the collection types like array and dictionary were copy on write; so the copies were cheap. I think in general, though, there are a lot of performance footguns in the design, mainly around when copies aren’t cheap. The future protocols will hopefully rectify these performance issues.
monkeyelite · 32d ago
Yeah - super weird. It’s like they saw a nice way to avoid thinking about ownership and references, and now have to reconcile with the real problem.
All of these “replace C++” projects have been quite disappointing. Where they tried to make big simplifications they often just didn’t understand the original problem and inherent complexity - or they made a good, but opinionated design choice which has been unable to survive bureaucratic demand for more features, etc.
nhojb · 32d ago
Swift is collapsing under the weight of its increasing complexity. So many, many special cases & they keep adding more!
As a developer it becomes so very hard to reason about code behaviour. This is especially true with concurrency, which was meant to simplify concurrent operations, but in actual fact is a nasty can of worms. In an effort to "hide the complexity" it just introduces a huge amount of unexpected & hard to grok behaviour. The new "immediate" Task behaviour & non-isolated async behaviours are good examples of this.
knighthack · 32d ago
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.
viktorcode · 32d ago
Spans and inline arrays are the two missing pieces of performance puzzle Swift needed. I'm super hyped for the release!
amichail · 32d ago
Do you try to put everything on the main actor to dramatically reduce your debugging time?
klabb3 · 32d ago
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.
monkeyelite · 32d ago
Absolutely - the idea of threads haphazardly interacting, like 2002 Java, is a terrible default assumption for designing languages and libraries.
It's not even clear the perf gains are great. Everything locking all the time has killed a lot of performance.
trevor-e · 32d ago
Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.
favorited · 32d ago
Especially in apps, where most of the code will be about preparing the user interface and handling events. And it's relatively easy to make most lower-level components actor-agnostic – either by making them conform to Sendable, by making them actors, or by giving them their own internal synchronization.
Hashex129542 · 32d ago
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?
hn-acct · 32d ago
Everything probably already is or should be
bsaul · 32d ago
Coding in both swift and rust is really a funny experience. It's like two roads being built going toward the same city, but starting from widely different places.
ak_111 · 32d ago
which is better?
singularity2001 · 32d ago
Swift started from beautiful syntax
rust has ugly syntax
Swift is becoming more rust like but also safer
bsaul · 32d ago
i think i prefer swift as a language, and rust as an ecosystem. The amount of quality libraries in rust is astounding.
But that may change with swift getting more and more into safety and reaching the limits of how many keywords a language can have and remain descent. I honestly don't know what the feeling of learning swift would be like today.
And on the other hand, i don't see how the rust language can really get nicer without sacrificing on a few design decisions and goals (in order to keep the language extremely versatile).
viktorcode · 32d ago
The actual targets are very different. For Rust is to be memory safe and available at any level starting from embedded. For Swift it is to be readable.
Hashex129542 · 32d ago
Mostly nonsense updates.
Swift was my favorite programming language after C++/Java since 2014. I've been faced major updates few times happily. It was one of the most easiest language. But now,
I tried to update a project from Swift 5.x to 6.x which has 150+ source files itself and no external libraries which is written by my own use and it has almost all swift 5.x features. They made up Swift as super hard. I decided not to use Swift 6 anymore and yes I don't need to reduce debugging time, Even though I don't have powerful computer and debugging time isn't matter to me & development time is actual matter to me.
The language itself becomes Rust (the programming language using by aliens). I Hope Swift language is upgrading itself for Aliens or the Swift team is filled with Aliens. Now, I feel ObjC is super easiest language than Swift.
PS: I understand Swift is Corporate Product & upgrading towards SwiftUI than general purpose programming language. I never gonna use Swift 6 even I do use ObjC for my projects.
wsc981 · 32d ago
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.
wingerlang · 32d ago
There is probably around a decade-long leap between XIB and SwiftUI. XIB files are only found in legacy code nowadays. It might have worked fine in smaller projects, but I think there are good reasons why it was left behind.
In my experience, most XIB files were either so small and easy that it was simply easier to replicate it in ten lines of code. Or so giant an impenetrable that it took thousands of lines of code to replicate it with, and at that point most people prefer to work with code over a dense XIB file.
rcruzeiro · 32d ago
xibs were an absolute nightmare if you worked with a team. Even in the Objective-C days a lot of developers were sticking with programatic layout to avoid xibs. Google even had this mandated in their Objective-C style guide.
cosmic_cheese · 32d ago
On iOS, code-only UIKit with bits of SwiftUI interspersed for simple components (think collection view cells) is definitely the way to go. UIKit is well equipped to be written that way (unlike Android Framework, which practically forces use of XML layouts in many cases).
For Mac dev, AppKit is still fairly heavily weighted towards use of XIBs, but it’s not nearly as much of an issue there because on average each individual XIB isn’t as overloaded with controls because the UI is more split up.
rcruzeiro · 32d ago
I’ve also had a good experience using SwiftUI with hosting confia for my cells. I am now at a point where I mostly use SwiftUI with just the occasional fallback to programmatic UIKit for the bits that are not quite there yet.
saagarjha · 32d ago
FWIW Android's XML layout is actually pleasant to use (though Jetpack Compose is also quite good).
cosmic_cheese · 32d ago
My experience with Android XML is mixed, but that might actually be more of an Android Studio problem. I did enjoy being able to reasonably hand edit the files, which isn’t practical with XIBs, and so naturally git conflicts aren’t as hairy.
I definitely prefer Compose these days though.
saagarjha · 32d ago
Google's style guide is usually not a great reference if you want to write a language that they didn't make. But yes, XIBs kind of suck.
ardit33 · 32d ago
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.
myHNAccount123 · 32d ago
> SwiftUI is a wreck, that is still not good for advanced UI and you still have to use UIKit for some parts, and
Skill issue. *ViewRepresentable exists.
ardit33 · 31d ago
You are making my point... if you have to use ViewRepresentable in half of the app, then SwiftUI failed. It was supposed to completely replace UIKit, but now it is just another framework to work with...
(makes easy things super easy, but harder/complex things harder).
It has some ways to go......
myHNAccount123 · 31d ago
Many developers have no issue achieving their desired designs with Representable or just swiftui.
Hashex129542 · 32d ago
> but instead it ended up being hydra/monster with too many pardagimns, and none of them are good.
So true.
viktorcode · 32d ago
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.
read news about rust and swift these days, it seems modern c++ might keep its dominance for the future
metaltyphoon · 32d ago
Rust doesn't keep adding features like Swift is. There is a lot of stabilization happening.
ardit33 · 32d ago
Swift is amateur hour in action by academics that don't value practicality. The new Concurrency was ill thought, and done by people that just perhaps either don't have enough practical experience, or are so enamored with the actor paradigm (erlang) that they had to shove it down the throat in a ecosystem where it is not used that much. No one is really using Swift for distributed programing.
Glad they are backtracking on this, and I hope they start remove features and simplifying things. Swift's enemy is its own self and the people steering int into just an academic exercise, rather than a practical and performant language that can be used in many domains.
Server side Swift right now is dead due to all these insane changes.
Hopefully things get better on the server/other non ios domains, but the language needs to get simplified and become practical and fun to use.
ak_111 · 32d ago
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?
danielscrubs · 32d ago
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.
andrekandre · 32d ago
> or are so enamored with the actor paradigm (erlang)
swift actors are barely actors in the erlang sense, not even close
maybe you're referring to structured concurrency?
hn-acct · 32d ago
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?
xmorse · 32d ago
does it really matter if it takes 1 hour to compile?
DidYaWipe · 32d ago
"a new Observations struct that is created with a closure, and provides an AsyncSequence that emits new values whenever any any @Observable data changes"
Is this another asinine onChange()-style mechanism that actually means WILL change? In other words, it tells you BEFORE the value is set on the object, so you can't do jack squat with it much of the time.
That's the M.O. of onChange now, which is utterly brain-dead. Gee, I've been told that a value changed in this object, so let's recalculate some stuff. WHOOPS, nope, none of the other objects (or hell, even the affected object) can take action yet because they can't interrogate the object for its new contents.
Truly incredible that they not only defaulted, but LIMITED change-detection to WILL-change, the least useful of the two choices.
viktorcode · 32d ago
> 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:
print(store.state.toggle) // Here we have the new value (+ it is called once before any change)
} onChange: {
Task { startObservation() }
}
}
DidYaWipe · 30d ago
I know that you get the new value; but in many cases (almost every case I encountered), that doesn't help. You mention
"This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI"
I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, because you're getting notified BEFORE that object has changed.
For example, if I have an object that represents a camera, and the user tweaks a value in the UI that changes its resolution, the camera might offer a different set of values for things like frame rate.
So if I get notified that the user changed the resolution, I can't then tell the Recorder object to recompute the remaining recording time based on the camera settings, because those settings will not have changed yet.
And incidentally, I've used startObservation() in places, and it's crippled by another idiotic design choice: It only works once. It reports the first change, and then never another one. So in the onChange closure, you have to re-start the observation. Every goddamned time.
It's another great example of serving only the most illogical and obscure use case. Who the hell would expect something called "startObservation" to just quit after one change? The stupidity is just galling.
viktorcode · 28d ago
> And incidentally, I've used startObservation() in places, and it's crippled by another idiotic design choice: It only works once. It reports the first change, and then never another one. So in the onChange closure, you have to re-start the observation. Every goddamned time.
The restart is there in my example, and it doesn't look too complex. And this aspect of observation is exactly what will be changed in Swift 6.2. Nice improvement, I'd say!
> I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, because you're getting notified BEFORE that object has changed.
If your model stores 2 interdependent states then you'll risk running into infinite update loop regardless of whether you've been notified from `didSet` or `willSet`. It can be fixed by changing the model.
To be fair I didn't understand your example with camera and resolution. In all cases you already know the new value and so the dependent code is good to go. The code shouldn't ever care where the value comes from: the main state, the future state, or some mock state.
hn-acct · 32d ago
There is a two parameter onChange modifier btw
90s_dev · 32d ago
> So, rather than writing
>
> @Test("Strip HTML tags from string") func stripHTMLTagsFromString() {...}
>
> we can instead write
>
> @Test func `Strip HTML tags from string`() {...}
Maybe I'm just really new at programming, but this seems like an absolutely bad feature, and the example actually perfectly proves it:
You really want to name a function "Hello World!" instead of helloWorld, just so your stack traces can pass a 5th grade English class exam?
90s_dev · 32d ago
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."
nulld3v · 32d ago
Many languages have had this feature for a long time. Ruby, ~~Rust,~~ Kotlin, etc... It hasn't been an issue at all.
I like that most languages seem to have reached consensus on backticks or other similarily awkward characters for this feature. Typing these identifiers is like hitting a speed bump, which seems to be enough to make devs avoid them except for very specific use-cases.
0rzech · 32d ago
Rust does not have this feature. Function names can't have spaces, for example. Underscores are used instead. Maybe there are some macros for arbitrary ASCII strings - I don't know - but it's not a language feature.
nulld3v · 32d ago
Wow, you are correct! A Rust "raw identifiers" can be a reserved keyword. But other than that, all other normal identifier naming rules still apply...
And apparently I never figured this out even after 3 years of Rust lol, thanks!
nulld3v · 31d ago
Whoops, I had an edit that apparantly did not submit. My comment is very wrong now, the only language in that list that supports "raw identifiers" in the same sense as Swift is Kotlin.
Although I still stress that it has never been an issue in Kotlin.
jibal · 32d ago
Zig uses @"arbitrary name"
It's an important feature for FFI, as well as passing operator functions around. (It seems bizarre to me that you can't do `+` in Swift, but I don't know Swift so maybe there's another way to name such functions.)
Also, the Zig library now uses @"..." for variables with the same name as keywords, rather than using ad hoc naming conventions in those cases.
90s_dev · 32d ago
Now that you mention it, JavaScript has this inherent problem too:
> foo["hello world!"]()
I'm halfway glad I've never needed to write C++ professionally, but it seems to me like all my TypeScript would probably transliterate to very clean C++31.
wiseowise · 32d ago
The issue is that it’s not a problem in the first place.
raydev · 32d ago
> languages have had this feature for a long time. Ruby
Yes, that is precisely why I don't like Ruby, it's actually impossible for tools to reason about many things that would make finding bugs before shipping feasible. Big companies like Shopify have to impose a lot of restrictions on it to make it work at scale, which is silly. Just use a different language!
Now Swift may not be in this situation because it's added yet more characters to wrap this nonsense so it is possible to reason about, but it's still just unnecessary, and I will be adding a lint rule against it at work. I don't expect a lot of pushback if any.
jibal · 32d ago
Test names are just an example. There are other valid reasons to be able to use arbitrary strings as names--importing functions from other languages and names that clash with keywords, for example.
bbatsell · 32d ago
The HTTPStatus enum example is a good one, but the backtick syntax is _rough_. I would only ever use the Type.case form in practice. The test stuff is basically a way to create BDD-style test names, which is kind of just a preference thing. I can’t envision myself using it for anything other than weird case names (I already use case `default` quite a lot because it’s such a useful word), but maybe some interesting DSLs can come out of it? I would not have prioritized that change personally.
rTX5CMRXIfFG · 32d ago
The HTTP status enum example is a _terrible_ one. If you need to represent HTTP statuses and call them by their integer names, why not just pass the damn integer itself? It's exactly what you get in `HTTPURLResponse.statusCode`, and you can already `switch` against it. Already not looking forward to the code that undiscerning devs will mindlessly write just because someone with a huge following wrote a blog.
dagmx · 31d ago
You can’t exhaustively handle an enum with just an integer.
layer8 · 31d ago
You want to exhaustively handle all 500 valid HTTP status codes (cf. RFC 9110)?
dagmx · 31d ago
Exhaustive matching doesn’t necessarily mean you handle every case separately, but it means you aren’t going to get cases you don’t know about sneaking in. With a bare int you can get values outside a range and the compiler won’t help
rTX5CMRXIfFG · 31d ago
Either you’re unaware or you’re arguing in bad faith, but you can switch against integers and pattern-match within integer ranges. The consequences of receiving an unexpected status code is the same—you handle it in the default case, as you would when decoding to an HTTPStatus enum fails.
dagmx · 30d ago
Way to start of the comment by being uncivil. You could have made the exact same point without being a jerk about it.
But it’s common to only want to support specific response codes in a context, and people do use enums for that. It’s a fairly common paradigm, and an enum will do all those validations for you so you don’t forget.
layer8 · 31d ago
When you receive an HTTP response, it can contain a status value outside the valid range as well. So you have to handle those one way or the other.
Regarding the int type, a better solution would be to provide the ability to define a restricted integer type, so that the compiler can help.
dagmx · 31d ago
Okay? So you cast it to the enum and instantly know it’s not a case you support.
It’s built in validation.
tiltowait · 32d ago
The backtick syntax for enums is rough, and typing out the full Type.case form negates one of Swift’s niceties (the ability to just type .case if the compiler can tell which enum is in use).
90s_dev · 32d ago
I would not have even approved it. But that's just me.
seanmcdirmid · 32d ago
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.
SwiftyBug · 32d ago
That's how Zig tests work. This is basically a function with a different syntax.
test "strip html tags from string" {
...
}
hiccuphippo · 32d ago
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"
thedanbob · 32d ago
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.
Common Lisp allows it as well, though I don't think I've ever seen it done outside a demonstration that it can be done.
soegaard · 32d ago
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.
codr7 · 32d ago
Except people can also use arbitrary identifiers in their own code now?
int_19h · 32d ago
The other reason is interop with other languages, which might have their own rules for identifiers.
layer8 · 31d ago
You can always work with aliases in that case. No strict need to “contaminate” a language with foreign identifier syntax, in particular if it’s still not 1:1 due to the backticks (e.g. identifiers containing backticks).
codr7 · 32d ago
I'm trying and failing miserably to think of a single example of such a language.
akdor1154 · 32d ago
.NET allows pretty much anything except a space, i think?
codr7 · 32d ago
And you can call into .NET (I assume that means C#) directly from Swift?
It lessens the likelihood of a collision, but doesn’t remove it.
rcruzeiro · 32d ago
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.
90s_dev · 32d ago
A better solution is to have a testing framework that doesn't rely on functions to name tests, especially in a language that has anonymous functions.
rcruzeiro · 32d ago
We have Quick for this — and while this framework is still a reasonable choice of a testing framework, I personally feel like the new Swift Testing framework is much nicer to write my test cases with.
Why do you need both an identifier and a text? I have this test name 'testAddingNewCardDataResultsInProperlyCombinedCardDataButNoNewCardsUnlocksBecauseWeStillHaveUnlearnedCards', and even though it is much longer than my other ones, it is still perfectly readable, and even if it wasn't, the only time I actually have to read it, is if it fails.
Starlevel004 · 32d ago
Kotlin has this, but it's basically only ever used for tests. I've never seen a real world method with a backtick name.
codr7 · 32d ago
There's a lot I love about Swift, but I fear it's quickly becoming too complicated for its own good.
There are just so many ways to solve a problem now that it's more or less impossible for someone to be familiar with all of them.
favorited · 32d ago
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.
arecurrence · 32d ago
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.
storoj · 32d ago
IMO async/await and Combine are two completely different things.
What is the alternative to Combine's CurrentValueSubject or combineLatest()?
andrekandre · 32d ago
> What is the alternative to Combine's CurrentValueSubject or combineLatest()?
combine latest et al can be found in async algorithms from apple*
* though current value subject is not there its not hard to make one if you need it
lukeh · 32d ago
AsyncExtensions implements many Combine-like patterns in structured concurrency.
jimbokun · 32d ago
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.
90s_dev · 32d ago
So it's becoming C++?
codr7 · 32d ago
That's my feeling, and it makes me sad because I have largely given up on C++ for that reason.
Hashex129542 · 32d ago
It's becoming Rust.
metaltyphoon · 32d ago
For some reason, I find Rust much easier to understand. Swift has so many constructs and special syntax while Rust is much more "tidy" with the syntax.
codr7 · 32d ago
Which I never even bothered with, for that reason.
hirvi74 · 32d ago
Considering Swift was primarily written in C++, perhaps Swift was always destined to follow the same path?
rcruzeiro · 32d ago
So following this same reasoning Python should become C?
hirvi74 · 31d ago
I like how you think. I'm down for it. I have never liked dynamically typed languages.
codr7 · 32d ago
Makes some sense, since its developers probably thought C++ was a pretty good idea, it just needed some more features. Same mindset that killed Rust for me.
I gave up on C++ for good reasons, after spending roughly 20 years trying to make sense of it.
90s_dev · 32d ago
Why not just code in a small, sane subset of C++ that you understand perfectly? That's what I do with TypeScript and it works fine.
amichail · 32d ago
Is having too many ways to solve a problem an issue for solo indie developers?
jimbokun · 32d ago
It can be if you keep adding the new way of doing things and then need to debug code that jumps between all the different ways of doing things.
myHNAccount123 · 32d ago
Right? I don't get this persons sentiment and I don't understand how it relates to the post in particular.
codr7 · 32d ago
You still have to choose, and remember all the variants.
Coming back to a Swift codebase after a few months in different languages is surreal, I can't remember what half of it means.
myHNAccount123 · 32d ago
Alright, I think I know what you mean - swift does have a peculiar way of completing tasks but I would also say C++ and ObjC do too but I also don't think there are too many ways.
I find you can do apply java and javascript type thinking to swift but they're less preferred.
90s_dev · 32d ago
I have not looked at Swift since I last wrote some around maybe v3. I hear that it's generally not a competitor to Rust, and is only really useful within the Apple ecosystem. Why is it not more useful as a C++ alternative, since I think that's kind of what the initial goal was? Is it just that non-Apple support is new-ish and not yet matured? Or a more fundamental issue?
porcoda · 32d ago
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.
rcruzeiro · 32d ago
There is this belief that Swift is not really useful outside of the Apple ecosystem or is somehow clunky, and that could not be farthest from the truth. In fact, having written a few backends in Swift, I can say that the experience of writing a Swift backend on Linux was much more ergonomic than what I am used to with writing Swift for iOS.
afavour · 32d ago
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.
Knowing which parts of Foundation will explode on your face on Linux is most of the challenge of doing non-Apple Swift code.
jshier · 32d ago
None, if you stick to using the bits from swift-foundation instead of swift-corelibs-foundation. Confusing, but the new code is much better, and in production on Apple's platforms as well.
The problem is that people only think it’s generally useful in the Apple ecosystem.
ackfoobar · 32d ago
I don't use Swift not because I think it's not useful outside Apple, but because I believe its developer experience is poor. Some stories that formed my opinions:
Granted, my perception may be wrong, but trying it to know for sure costs time. Swift has not earned my time investment.
rcruzeiro · 32d ago
The second example is moot since, outside the Apple ecosystem, you don't even need to know Xcode exists.
ardit33 · 32d ago
They have stalled, and the concurency is making things harder to implement right.
Basically, Vapor has to be re-written as it is, in order to work will with swift 6+. Which kinda kills already any little moment it had.
Was looking to use it with a new project, as it is a nice framework, but going with GoLang on the server side due to all this in flux changes.
AnishLaddha · 32d ago
what advantages does swift offer over go/rust/js/java for server side programming? I always presumed the advantages of swift were native code compilation + top tier integration w/the apple ecosystem.
madeofpalk · 32d ago
In my little usage of it (and go and rust), Swift feels like a nice middleground between go and rust. Or, a better (safer) go.
I think Swift is vastly underestimated due to it's relation to Apple.
hocuspocus · 32d ago
I don't think people care about its relation to Apple, they care about the language ecosystem, roadmap and evolution that were shaped by Apple's needs for iOS and macOS before there was a real attempt at making Swift more general purpose and multi-platform. And now that it's somewhat there, there are better options in almost every dimension.
favorited · 32d ago
I have a few personal and professional Swift on server projects, in the wild and in the works. Code reuse is a big win – we can ~easily expose functionality of our client apps to other systems. Familiarity is another – there's an ocean of iOS (and, to a lesser extent, macOS) developers out there who are familiar with Swift. With a little bit of coaching, they can pretty quickly get up to speed with how services work.
It reminds me a lot of what it was like to ship Node.js software 15 years ago – the ecosystem is still young, but there are enough resources out there to solve 95% of the problems you'll face.
amichail · 32d ago
It's a high level language that doesn't get in your way.
rcruzeiro · 32d ago
In my experience, writing Swift for the backend feels a lot like writing TypeScript, but nicer — though that’s just a personal preference. You get the performance of a compiled language like Rust (though that’s rarely a bottleneck for backend applications), but Swift is significantly easier than Rust and has much faster compile times.
725686 · 32d ago
The advantage is obvious if you already use Swift.
viktorcode · 32d ago
Unlike Rust, it has some C++ binding, which is extremely useful.
Hashex129542 · 32d ago
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.
pkulak · 32d ago
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
favorited · 32d ago
> a language with a garbage collector (Swift)
You can certainly make the case that reference counting is a form of garbage collection, but it is absolutely false to say Swift has "a garbage collector." There is no runtime process that is responsible for collecting garbage – allocated objects are freed deterministically when their reference count hits zero.
The same thing is true of `shared_ptr` instances in C++, and there's certainly no "garbage collector" there, either.
pkulak · 32d ago
That reference counting is done at runtime. It’s a runtime garbage collector. It’s different than a generational GC, but it’s GC. Those cycles to increment and decrement a counter attached to every object at ever touch aren’t free. All the downvotes in the world won’t make that free.
favorited · 32d ago
> It’s a runtime garbage collector
What does "it" refer to? The function calls to _swift_release_()? Because if function calls are a "garbage collector," then free() is a garbage collector. And if free() is a garbage collector, then the term is too vague to have any useful meaning.
pkulak · 32d ago
Yes. Garbage collectors also call free. They call functions. They do all kinds of things. They even increment and decrement reference counters on your behalf. When there’s a system that manages your memory for you at runtime, that’s a garbage collector.
Swift is great. And reference counting is exactly the right kind of GC for UIs because there are no pauses. But GC it still is. And it wrecks throughput and is not appropriate for situations where you don’t want GC.
And in reference to `shared_ptr`, or Rc and Arc in Rust, that's manual memory management because you're doing it... manually. Swift is like C++ or Rust if you were never allowed to have a reference to anything that wasn't behind an Arc. Then it's no longer manual, it's automatic.
favorited · 32d ago
> Yes. Garbage collectors also call free. They call functions.
Ok, what is calling `free` here? Point to the garbage collector. Show me the thing that is collecting the garbage.
> And in reference to `shared_ptr`, or Rc and Arc in Rust, that's manual memory management because you're doing it... manually.
You're also doing it manually when you decide to make a type a class in Swift. You're opting in to reference counting when you write a class, or use a type that is backed by a class.
It also seems that our goalposts have gone missing. Before, "it" (whatever "it" is) was a garbage collector because it happened at runtime:
> That reference counting is done at runtime. It’s a runtime garbage collector.
shared_ptr, Rc, and Arc also manage their memory at runtime. But now, "it's" a garbage collector because the compiler generates the retain/release calls...
pkulak · 31d ago
The garbage collector is what wraps every reference to every object on the heap.
But fine, no GC. I wonder why every language in the world doesn’t use reference counting, since it’s not GC AND you don’t have to clean up any memory you allocate. I guess everyone who ever designed a language is kinda dumb.
astrange · 32d ago
> And reference counting is exactly the right kind of GC for UIs because there are no pauses.
That's not the reason it uses reference counting. The overhead of scanning memory is too high, the overhead of precisely scanning it (avoiding false-positive pointers) is higher, and the entire concept of GC assumes memory can be read quickly which isn't true in the presence of swap.
That said, precise GC means you can have compaction, which can potentially be good for swap.
throwup238 · 32d ago
> That reference counting is done at runtime.
I thought Swift uses ARC just like Objective-C? The compiler elides much of the reference counting, even across inlined functions. It’s not like Python or Javascript where a variable binding is enough to cause an increment (although IIRC the V8 JIT can elide some of that too).
I don’t disagree that it’s a runtime GC but there’s a bit of nuance to its implementation that resists simple categorization like that.
N years later, it doesn’t feel like there has been a step change in Apple software quality; if anything Apple software feels less solid, and looks cool “look what I did” extension points. I mean, some of the tings you could do with runtime categories, and runtime prototypes were really cool. Now when I work on my 2 apps that originally happily port to Swift/UIKit, I’m just left confused with how to make things work. I’m happy when it finally works, and don’t ever try to improve the thing, it’s too much work.
There’s lots of different variables at play here; I’m not trying to stretch inference too much. Heck, it could have been that with adding Swift to the mix, the forces that have contributed to reduced quality in Apples stuff would be even worse.
I’m just frustrated. When I work in Elixir, I’m like this is cool. When I work in Kotlin, I don’t feel like “Apples got a language like this too, but it’s got that extra special zing that used to make stuff Apple touched cool.”
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.
I have published a word game written entirely in SwiftUI [1], the effects and animations would have been much more difficult to do in UIKit, and the app itself would have been hairier to write and maintain [2]. I also track crashes, and this particular app has had four crashes in the past year, so I am very pleased with the stability
That said, there are definitely times, as you say, where you have to drop to UIKit. For the word game mentioned above, I had to drop down to UIKit to observe low-level keyboard events in order to support hardware keyboard input without explicitly using a control that accepts text input
SwiftUI is mature, it's pretty advanced — especially for graphics and animation heavy UI. It has limitations, particularly around advanced input event handling, as well as the application/scene lifecycle
I plan to continue to use both UIKit and SwiftUI where they make sense. It's easy enough to bridge between them with UIHostingController and UIViewRepresentable
[1] https://retrogram.app
[2] Specific examples include: image and alpha masking is trivial in SwiftUI, Metal Shaders can be applied with a one-line modifier, gradients are easy and automatic, SwiftUI's Timeline+Canvas is very performant and more powerful than custom drawing with UIKit. Creating glows, textured text and images, blurs and geometry-based transitions is much easier in SwiftUI
I haven’t used Swift UI in a couple of years, but I always thought the basics of it were excellent.
They got the declarative API foundations right I thought.
Shame it’s still flakey.
The preview used to crash constantly last time I used it.
She comes across bugs on the regular that I’ve never seen in 16 years of Mac use, but only when the other user account is logged in (i.e. quick user switching rather than a full log out).
Stuff that user accounts shouldn’t even make any difference to, like the menu bar disappearing or rendering too far up so it’s half off screen. Save dialogs stop appearing. Windows that are open but appear to be rendering off screen somewhere. It’s wild. This is on a < 1 year old MacBook Air running the latest OS. It’s an absolute shambles.
After over 20 years, I’m really unhappy with macOS. The last five years have have been a huge productivity regression.
I made a new user for Zoom screen share and was equally confused when my personal files and info would show up in searches and such. And it seems like most things install globally?
Ended up using a whole new computer to have a clean screenshare environment.
This could not be furthest for the truth. The entire process of proposing a new language feature to getting it implemented and shipped is out in the open for everyone to participate/see.
https://github.com/swiftlang/swift-evolution
https://youtu.be/Hu-jvAWTZ9o?si=PalSP6POofiRuj3a
I still feel like GUI programming hasn’t progressed in the years since this. Actually they’ve regressed in many ways.
But my impression watching from the outside is that he had a finger in every pie.
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.
Conversely, it's easier to debug an Objective-C app than a Swift app, simply because compiling and debugging is so much faster, and debugging so much more reliable
I don't know about a software quality drop being attributable to the migration to Swift. So many other things have also happened in that time — much more software that Apple produces is heavily reliant on network services, which they are not very good at. I find Apple's local-first software to be excellent (Final Cut Pro X, Logic, Keynote) and their network-first software is hit-or-miss
They have also saddled developers with a ton of APIs for working with their online services. Try to write correct and resilient application code that deals with files in iCloud? It's harder than it was to write an application that dealt with only local files a decade ago!
Swift is easy to blame, but I don't think it's responsible for poor software. Complexity is responsible for poor software, and we have so much more of that now days
(People have tried to come up with simpler languages that still preserve safety and low-level power, like Austral - but that simplicity comes at the cost of existing intuition for most devs.)
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.
It’s a set of tools intended to do just that.
https://skip.tools/
> Skip supports both compiling Swift natively for Android, and transpiling Swift into Kotlin. Read about Skip’s modes in the documentation.
https://skip.tools/docs/faq/#modes
https://skip.tools/docs/modes/
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.
You can have both. Rust feels "mature" and "finished" if you stick to the stable featureset, but it's still bringing compelling new features over time in spite of that. But this can only be achieved by carefully managing complexity and not letting it get out-of-hand with lots of ad-hoc special cases and tweaks.
In a sense, MacRuby was trying something similar, but the dependency on a GC doomed it.
I’m trying to imagine using it without the stream API just shuts my entire brain down. Records arrived pretty recently and are already essential for me.
You will always have to pay me to program Java, but you’d have to pay me 5x my current salary to do it in Java 8 or earlier.
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?
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.
I don’t mind Objective-C when I’m the one writing it and can ensure that the code is responsibly written, but it wasn’t unusual to have to work on existing Obj-C codebases littered with untyped data, casts, etc some amount of which was inevitably erroneous and only seemed to work correctly. Chasing down the origin points of data, fixing a laundry list of method selectors, and adding in checks always sucked with the compiler doing little to give you a hand. With Swift, even in codebases with poor hygiene fixing things is easier since the compiler will yell when something’s wrong.
Or was there issue more intrinsic to the design of the language itself?
You’d basically need to implement the Swift compiler in the Objective-C compiler to get similar type safety, but to make it work you would probably need to change various bits of syntax, drop inline intermixture of C and C++, and remove a lot of Obj-C’s dynamism, basically making it a new language. That’s why Swift was created, and in the past Obj-C’s bracketed smalltalk-like syntax had proven unpopular amongst newcoming devs, so they chose a more mainstream syntax instead.
I have to say Paul Hudson has almost single-handedly taken over communicating the essentials of Swift to the world; he’s fantastically reliable, brief but enthusiastic, guiding people around the many pitfalls.
[0] https://github.com/visfitness/reorderable/pull/2
No comments yet
If you want constrained numeric types in Swift, that's another problem to tackle. But `HTTPStatus.`404`` seems to be the least ideal way to go about it. It lets you do stuff like to declare `HttpStatus.`404`` with a value of 403 too.
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".
I'm not seeing why it's worth a whole language feature to avoid prefixing strange identifiers.
Not a fan personally, but Swift is littered with little "niceties" (complexities) like this.
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.
To clarify something I said earlier, I would rather have to stop what I'm doing to look at documentation (something that can be done within the IDE) than have to open up a browser and read through the specification to figure out what some magic-value means. Having a provided named-constant that tells me what 1003 means is very useful for me and for other maintainers or contributors to the project, and it can link to the spec for more information anyway. Just having raw magic-values is not great for maintenance. Likewise, having pretty names entirely detached from the actual close-code makes searching for places where that close-code is used much harder. Even just "1003_REFUSE" or "1003_CANNOT_ACCEPT" is so much better.
If you can't figure out what stripHTMLTagsFromString() does, you have way bigger problems than a lack of spaces.
— Chris Lattner, 2024
https://blog.jacobstechtavern.com/p/apple-is-killing-swift
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 really wish the entire Swift team would spend a quarter fixing bugs and improving the compiler speed, though. So many trivial SwiftUI cases trigger the "this is too complex for the compiler" errors which are so frustrating to fix.
I found myself awestruck that I *HAD* to use XCode or xcodebuild, and could not just run `swift build` and generate an iOS app.
In the end, I had to:
- compile the .app structure myself
- run codesign manually
- manage the simulator manually
- bundle xcAssets manually
- provide swift linker flags manually targeting the toolchain/sdk I needed
- manually copy an embedded.mobileprovision
It was a good learning experience, but what's the story here? Did Apple just give away Swift to the OSS community and then make no ongoing effort to integrate their platforms nicely into the non-xcode build tooling? Looking into https://github.com/stackotter/swift-bundler
If you ask me, those platform specific things should never be integrated part of the language.
As flawed as they are in my eyes, its dev tooling quality is something I appreciate and wish I saw here. There are two CLIs, one for the language (Dart) and one for the framework (Flutter). Some would say that the CLI equivalent would be xcodebuild, but that depends on the complex .xcodeproj/.xcworkspace structure and still requires XCode to be installed.
(I then separately complained at all the steps it took to get it running without XCode, as I didn't want to be locked into using it)
They're just shoveling stuff in to the language.
Individually, most items aren't so bad, but collectively they've got a mess and it's getting bigger fast.
None of the decision-makers seem to have the sense or incentive to say "no" to anything.
It's sad, because the language had such promise and there are some really nice things in there.
Well, at least it's relatively easy to avoid or ignore.
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.
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.
Why not? Does this mean I need to make a struct which wraps InlineArray and implements Collection? Why didn't they do that?
EDIT: found the answer (I still have concerns):
> While we could conform to these protocols when the element is copyable, InlineArray is unlike Array in that there are no copy-on-write semantics; it is eagerly copied. Conforming to these protocols would potentially open doors to lots of implicit copies of the underlying InlineArray instance which could be problematic given the prevalence of generic collection algorithms and slicing behavior. To avoid this potential performance pitfall, we're explicitly not opting into conforming this type to Sequence or Collection.
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.
Why the protocols are designed the way they are is until very recently all types were implicitly copyable, but most of the collection types like array and dictionary were copy on write; so the copies were cheap. I think in general, though, there are a lot of performance footguns in the design, mainly around when copies aren’t cheap. The future protocols will hopefully rectify these performance issues.
All of these “replace C++” projects have been quite disappointing. Where they tried to make big simplifications they often just didn’t understand the original problem and inherent complexity - or they made a good, but opinionated design choice which has been unable to survive bureaucratic demand for more features, etc.
As a developer it becomes so very hard to reason about code behaviour. This is especially true with concurrency, which was meant to simplify concurrent operations, but in actual fact is a nasty can of worms. In an effort to "hide the complexity" it just introduces a huge amount of unexpected & hard to grok behaviour. The new "immediate" Task behaviour & non-isolated async behaviours are good examples of this.
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.
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.
It's not even clear the perf gains are great. Everything locking all the time has killed a lot of performance.
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?
Swift is becoming more rust like but also safer
But that may change with swift getting more and more into safety and reaching the limits of how many keywords a language can have and remain descent. I honestly don't know what the feeling of learning swift would be like today.
And on the other hand, i don't see how the rust language can really get nicer without sacrificing on a few design decisions and goals (in order to keep the language extremely versatile).
Swift was my favorite programming language after C++/Java since 2014. I've been faced major updates few times happily. It was one of the most easiest language. But now,
I tried to update a project from Swift 5.x to 6.x which has 150+ source files itself and no external libraries which is written by my own use and it has almost all swift 5.x features. They made up Swift as super hard. I decided not to use Swift 6 anymore and yes I don't need to reduce debugging time, Even though I don't have powerful computer and debugging time isn't matter to me & development time is actual matter to me.
The language itself becomes Rust (the programming language using by aliens). I Hope Swift language is upgrading itself for Aliens or the Swift team is filled with Aliens. Now, I feel ObjC is super easiest language than Swift.
PS: I understand Swift is Corporate Product & upgrading towards SwiftUI than general purpose programming language. I never gonna use Swift 6 even I do use ObjC for my projects.
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.
In my experience, most XIB files were either so small and easy that it was simply easier to replicate it in ten lines of code. Or so giant an impenetrable that it took thousands of lines of code to replicate it with, and at that point most people prefer to work with code over a dense XIB file.
For Mac dev, AppKit is still fairly heavily weighted towards use of XIBs, but it’s not nearly as much of an issue there because on average each individual XIB isn’t as overloaded with controls because the UI is more split up.
I definitely prefer Compose these days though.
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.
Skill issue. *ViewRepresentable exists.
(makes easy things super easy, but harder/complex things harder).
It has some ways to go......
So true.
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.
Glad they are backtracking on this, and I hope they start remove features and simplifying things. Swift's enemy is its own self and the people steering int into just an academic exercise, rather than a practical and performant language that can be used in many domains. Server side Swift right now is dead due to all these insane changes.
Hopefully things get better on the server/other non ios domains, but the language needs to get simplified and become practical and fun to use.
maybe you're referring to structured concurrency?
“Due to these insane changes” Which changes?
Is this another asinine onChange()-style mechanism that actually means WILL change? In other words, it tells you BEFORE the value is set on the object, so you can't do jack squat with it much of the time.
That's the M.O. of onChange now, which is utterly brain-dead. Gee, I've been told that a value changed in this object, so let's recalculate some stuff. WHOOPS, nope, none of the other objects (or hell, even the affected object) can take action yet because they can't interrogate the object for its new contents.
Truly incredible that they not only defaulted, but LIMITED change-detection to WILL-change, the least useful of the two choices.
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 {
"This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI"
I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, because you're getting notified BEFORE that object has changed.
For example, if I have an object that represents a camera, and the user tweaks a value in the UI that changes its resolution, the camera might offer a different set of values for things like frame rate.
So if I get notified that the user changed the resolution, I can't then tell the Recorder object to recompute the remaining recording time based on the camera settings, because those settings will not have changed yet.
And incidentally, I've used startObservation() in places, and it's crippled by another idiotic design choice: It only works once. It reports the first change, and then never another one. So in the onChange closure, you have to re-start the observation. Every goddamned time.
It's another great example of serving only the most illogical and obscure use case. Who the hell would expect something called "startObservation" to just quit after one change? The stupidity is just galling.
The restart is there in my example, and it doesn't look too complex. And this aspect of observation is exactly what will be changed in Swift 6.2. Nice improvement, I'd say!
> I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, because you're getting notified BEFORE that object has changed.
If your model stores 2 interdependent states then you'll risk running into infinite update loop regardless of whether you've been notified from `didSet` or `willSet`. It can be fixed by changing the model.
To be fair I didn't understand your example with camera and resolution. In all cases you already know the new value and so the dependent code is good to go. The code shouldn't ever care where the value comes from: the main state, the future state, or some mock state.
Maybe I'm just really new at programming, but this seems like an absolutely bad feature, and the example actually perfectly proves it:
You really want to name a function "Hello World!" instead of helloWorld, just so your stack traces can pass a 5th grade English class exam?
I like that most languages seem to have reached consensus on backticks or other similarily awkward characters for this feature. Typing these identifiers is like hitting a speed bump, which seems to be enough to make devs avoid them except for very specific use-cases.
And apparently I never figured this out even after 3 years of Rust lol, thanks!
Although I still stress that it has never been an issue in Kotlin.
It's an important feature for FFI, as well as passing operator functions around. (It seems bizarre to me that you can't do `+` in Swift, but I don't know Swift so maybe there's another way to name such functions.)
Also, the Zig library now uses @"..." for variables with the same name as keywords, rather than using ad hoc naming conventions in those cases.
> foo["hello world!"]()
I'm halfway glad I've never needed to write C++ professionally, but it seems to me like all my TypeScript would probably transliterate to very clean C++31.
Yes, that is precisely why I don't like Ruby, it's actually impossible for tools to reason about many things that would make finding bugs before shipping feasible. Big companies like Shopify have to impose a lot of restrictions on it to make it work at scale, which is silly. Just use a different language!
Now Swift may not be in this situation because it's added yet more characters to wrap this nonsense so it is possible to reason about, but it's still just unnecessary, and I will be adding a lint rule against it at work. I don't expect a lot of pushback if any.
But it’s common to only want to support specific response codes in a context, and people do use enums for that. It’s a fairly common paradigm, and an enum will do all those validations for you so you don’t forget.
Regarding the int type, a better solution would be to provide the ability to define a restricted integer type, so that the compiler can help.
It’s built in validation.
test "strip html tags from string" {
Also I like the backticks better than what zig came up with: @"404"
Common Lisp allows it as well, though I don't think I've ever seen it done outside a demonstration that it can be done.
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.
https://github.com/royalapplications/beyondnet
https://github.com/Quick/Quick
There are just so many ways to solve a problem now that it's more or less impossible for someone to be familiar with all of them.
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.
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.
What is the alternative to Combine's CurrentValueSubject or combineLatest()?
https://github.com/apple/swift-async-algorithms
* though current value subject is not there its not hard to make one if you need it
I gave up on C++ for good reasons, after spending roughly 20 years trying to make sense of it.
Coming back to a Swift codebase after a few months in different languages is surreal, I can't remember what half of it means.
I find you can do apply java and javascript type thinking to swift but they're less preferred.
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)
[1] https://forums.swift.org/t/an-embedded-audio-product-built-w...
An example: https://vapor.codes/
The problem is that people only think it’s generally useful in the Apple ecosystem.
https://news.ycombinator.com/item?id=9947193
https://news.ycombinator.com/item?id=42803489
Granted, my perception may be wrong, but trying it to know for sure costs time. Swift has not earned my time investment.
Basically, Vapor has to be re-written as it is, in order to work will with swift 6+. Which kinda kills already any little moment it had.
Was looking to use it with a new project, as it is a nice framework, but going with GoLang on the server side due to all this in flux changes.
I think Swift is vastly underestimated due to it's relation to Apple.
It reminds me a lot of what it was like to ship Node.js software 15 years ago – the ecosystem is still young, but there are enough resources out there to solve 95% of the problems you'll face.
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.
EDIT: Yes, ref. counting is garbage collection, before the replies blow up. haha
You can certainly make the case that reference counting is a form of garbage collection, but it is absolutely false to say Swift has "a garbage collector." There is no runtime process that is responsible for collecting garbage – allocated objects are freed deterministically when their reference count hits zero.
The same thing is true of `shared_ptr` instances in C++, and there's certainly no "garbage collector" there, either.
What does "it" refer to? The function calls to _swift_release_()? Because if function calls are a "garbage collector," then free() is a garbage collector. And if free() is a garbage collector, then the term is too vague to have any useful meaning.
Swift is great. And reference counting is exactly the right kind of GC for UIs because there are no pauses. But GC it still is. And it wrecks throughput and is not appropriate for situations where you don’t want GC.
And in reference to `shared_ptr`, or Rc and Arc in Rust, that's manual memory management because you're doing it... manually. Swift is like C++ or Rust if you were never allowed to have a reference to anything that wasn't behind an Arc. Then it's no longer manual, it's automatic.
Ok, what is calling `free` here? Point to the garbage collector. Show me the thing that is collecting the garbage.
> And in reference to `shared_ptr`, or Rc and Arc in Rust, that's manual memory management because you're doing it... manually.
You're also doing it manually when you decide to make a type a class in Swift. You're opting in to reference counting when you write a class, or use a type that is backed by a class.
It also seems that our goalposts have gone missing. Before, "it" (whatever "it" is) was a garbage collector because it happened at runtime:
> That reference counting is done at runtime. It’s a runtime garbage collector.
shared_ptr, Rc, and Arc also manage their memory at runtime. But now, "it's" a garbage collector because the compiler generates the retain/release calls...
But fine, no GC. I wonder why every language in the world doesn’t use reference counting, since it’s not GC AND you don’t have to clean up any memory you allocate. I guess everyone who ever designed a language is kinda dumb.
That's not the reason it uses reference counting. The overhead of scanning memory is too high, the overhead of precisely scanning it (avoiding false-positive pointers) is higher, and the entire concept of GC assumes memory can be read quickly which isn't true in the presence of swap.
That said, precise GC means you can have compaction, which can potentially be good for swap.
I thought Swift uses ARC just like Objective-C? The compiler elides much of the reference counting, even across inlined functions. It’s not like Python or Javascript where a variable binding is enough to cause an increment (although IIRC the V8 JIT can elide some of that too).
I don’t disagree that it’s a runtime GC but there’s a bit of nuance to its implementation that resists simple categorization like that.