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.
strongpigeon · 1h 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.
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.
trevor-e · 1h 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 · 29m 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 · 17m 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
Hashex129542 · 8m 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.
amichail · 3h ago
Do you try to put everything on the main actor to dramatically reduce your debugging time?
trevor-e · 2h ago
Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.
favorited · 1h 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.
hn-acct · 3h ago
Everything probably already is or should be
90s_dev · 3h 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?
Starlevel004 · 3m 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.
90s_dev · 3h 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 · 1h 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 · 1h 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.
bbatsell · 3h 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.
90s_dev · 1h ago
I would not have even approved it. But that's just me.
seanmcdirmid · 3h 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 · 3h ago
That's how Zig tests work. This is basically a function with a different syntax.
test "strip html tags from string" {
...
}
soegaard · 2h 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.
int_19h · 1h ago
The other reason is interop with other languages, which might have their own rules for identifiers.
codr7 · 2h ago
Except people can also use arbitrary identifiers in their own code now?
thedanbob · 3h 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.
hiccuphippo · 3h 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"
codr7 · 2h 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 · 1h 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 · 2h 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 · 1h ago
IMO async/await and Combine are two completely different things.
What is the alternative to Combine's CurrentValueSubject or combineLatest()?
lukeh · 46m ago
AsyncExtensions implements many Combine-like patterns in structured concurrency.
90s_dev · 2h ago
So it's becoming C++?
codr7 · 1h ago
That's my feeling, and it makes me sad because I have largely given up on C++ for that reason.
hirvi74 · 2h ago
Considering Swift was primarily written in C++, perhaps Swift was always destined to follow the same path?
amichail · 1h ago
Is having too many ways to solve a problem an issue for solo indie developers?
myHNAccount123 · 3m ago
Right? I don't get this persons sentiment and I don't understand how it relates to the post in particular.
90s_dev · 3h 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 · 2h 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.
afavour · 3h 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.
The problem is that people only think it’s generally useful in the Apple ecosystem.
ackfoobar · 1h 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.
AnishLaddha · 3h 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 · 3h 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 · 13m 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.
amichail · 3h ago
It's a high level language that doesn't get in your way.
favorited · 2h 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.
725686 · 2h ago
The advantage is obvious if you already use Swift.
pkulak · 1h 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 · 1h 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.
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
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.
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
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.
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.
test "strip html tags from string" {
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.
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.
Also I like the backticks better than what zig came up with: @"404"
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()?
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.
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.
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.