[HN Gopher] What's New in Swift 6.2?
___________________________________________________________________
What's New in Swift 6.2?
Author : ingve
Score : 69 points
Date : 2025-05-09 20:20 UTC (2 hours ago)
(HTM) web link (www.hackingwithswift.com)
(TXT) w3m dump (www.hackingwithswift.com)
| amichail wrote:
| Do you try to put everything on the main actor to dramatically
| reduce your debugging time?
| hn-acct wrote:
| Everything probably already is or should be
| trevor-e wrote:
| Main actor by default is a decent strategy. It's usually pretty
| obvious when something needs to happen off the main actor.
| 90s_dev wrote:
| 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?
| jonny_eh wrote:
| Apparently Arc Browser is written in Swift:
| https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc...
| briandear wrote:
| Generally only useful within the Apple ecosystem is definitely
| inaccurate.
|
| An example: https://vapor.codes/
|
| The problem is that people only _think_ it's generally useful
| in the Apple ecosystem.
| AnishLaddha wrote:
| 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.
| amichail wrote:
| It's a high level language that doesn't get in your way.
| madeofpalk wrote:
| 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.
| favorited wrote:
| 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 wrote:
| The advantage is obvious if you already use Swift.
| afavour wrote:
| There's a level of self fulfilling prophecy here: people don't
| use Swift off Apple platforms because there isn't a critical
| mass of people using Swift off Apple platforms.
|
| But that said it can be frustrating. A lot of the documentation
| and tutorials you find out there assume you're on an Apple
| platform where, e.g. Foundation APIs are available. And the
| direction of the language, the features being added etc, very
| clearly serve Apple's goals.
|
| (Side note: IBM was an early adopter of Swift off-platform but
| then stepped back:
| https://forums.swift.org/t/december-12th-2019/31735)
| porcoda wrote:
| 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.
| pkulak wrote:
| 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
| 90s_dev wrote:
| > 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 wrote:
| 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."
| bbatsell wrote:
| 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 wrote:
| I would not have even _approved_ it. But that 's just me.
| hiccuphippo wrote:
| 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 wrote:
| 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.
| Jtsummers wrote:
| https://tio.run/##S87JLC74/18jJTWtNE@hJiM1JydfoTy/KCelRkFDk0.
| ..
|
| 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.
| seanmcdirmid wrote:
| 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 wrote:
| That's how Zig tests work. This is basically a function with
| a different syntax.
|
| test "strip html tags from string" { ...
| }
| soegaard wrote:
| 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 wrote:
| Except people can also use arbitrary identifiers in their own
| code now?
| codr7 wrote:
| 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.
| 90s_dev wrote:
| So it's becoming C++?
| hirvi74 wrote:
| Considering Swift was primarily written in C++, perhaps Swift
| was always destined to follow the same path?
| codr7 wrote:
| That's my feeling, and it makes me sad because I have largely
| given up on C++ for that reason.
| arecurrence wrote:
| 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 wrote:
| IMO async/await and Combine are two completely different
| things.
|
| What is the alternative to Combine's CurrentValueSubject or
| combineLatest()?
| amichail wrote:
| Is having too many ways to solve a problem an issue for solo
| indie developers?
| sedatk wrote:
| 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 easily 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.
| w10-1 wrote:
| 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.
| trevor-e wrote:
| 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.
___________________________________________________________________
(page generated 2025-05-09 23:00 UTC)