12 ms·

What’s new in Swift 6.2

• synergy20 1y ago
  read news about rust and swift these days, it seems modern c++ might keep its dominance for the future
  • metaltyphoon 1y ago
    Rust doesn't keep adding features like Swift is. There is a lot of stabilization happening.
• amichail 1y ago
  Do you try to put everything on the main actor to dramatically reduce your debugging time?
  • hn-acct 1y ago
    Everything probably already is or should be
  • trevor-e 1y ago
    Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.
    • favorited 1y 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.
  • klabb3 1y 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 1y 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.
  • Hashex129542 1y 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?
• 90s_dev 1y 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?
  • jonny_eh 1y ago
    Apparently Arc Browser is written in Swift: https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc_using_swift_programming_language_under/ https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc...
  • briandear 1y ago
    Generally only useful within the Apple ecosystem is definitely inaccurate. An example: https://vapor.codes/ https://vapor.codes/ The problem is that people only think it’s generally useful in the Apple ecosystem.
    • AnishLaddha 1y 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.
      • amichail 1y ago
        It's a high level language that doesn't get in your way.
      • madeofpalk 1y 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.
        • 1y ago
• 90s_dev 1y 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?
  • seanmcdirmid 1y 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 1y ago
      That's how Zig tests work. This is basically a function with a different syntax. test "strip html tags from string" { ... }
  • 90s_dev 1y 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."
    • bbatsell 1y 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.
• codr7 1y 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.
  • 90s_dev 1y ago
    So it's becoming C++?
    • hirvi74 1y ago
      Considering Swift was primarily written in C++, perhaps Swift was always destined to follow the same path?
      • rcruzeiro 1y ago
        So following this same reasoning Python should become C?
        • hirvi74 1y ago
          I like how you think. I'm down for it. I have never liked dynamically typed languages.
      • codr7 1y 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 1y 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.
    • 1y ago
• meisel 1y ago
  [flagged]
  • msie 1y ago
    Seriously, smart people making dumb decisions.
    • 90s_dev 1y ago
      I can't help but think some of the Swift leads just really like Haskell.
      • trealira 1y ago
        Haskell names can't have spaces in them, though. Names with spaces is much more reminiscent of Algol 68, or old-style Fortran.
      • hocuspocus 1y ago
        Escaping symbols with backticks to circumvent illegal characters and reserved keywords is a feature coming straight from Scala actually.
        • msie 1y ago
          Cool. I was smitten with Scala for a while but it was getting too complex after a while. Like Swift and C++.
          • hocuspocus 1y ago
            I think it's genuinely simpler than Swift or Kotlin that have seen an explosion of grammar, keywords and features. The modern Scala ecosystem has mostly converged towards one style even though it's fully compatible with the more questionable Java/JVM constructs like runtime reflection, annotation processing and so on. Sure you have to understand a few FP concepts that might be alien at first, but there's a fairly straight and clear path unlike hybrid languages that evolved in too many directions at once. Meta-programming features have also been completely overhauled with Scala 3 and are more approachable, especially if you're just an end user that needs a library doing generic derivation for instance. Odersky is also on a crusade against monadic effect systems and we might get something like algebraic effects, direct-style.
• sedatk 1y 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.
  • jshier 1y 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`
  • hombre_fatal 1y 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 1y 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 1y ago
    > case _401 or case error401. I'm not seeing why it's worth a whole language feature to avoid prefixing strange identifiers.
    • sedatk 1y ago
      I don’t think it’s the sole reason, but I find that example odd for sure.
• w10-1 1y 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.
  • strongpigeon 1y 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. [0] https://github.com/visfitness/reorderable/pull/2 https://github.com/visfitness/reorderable/pull/2
    • hudsonator 1y ago
      [flagged]
      • strongpigeon 1y ago
        I’d love to believe you, but you’re not giving us much to go on with
  • dkga 1y ago
    The last sentence is exactly how I would describe Paul Hudson, as a HwS reader/user.
  • rockbruno 1y 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.
• trevor-e 1y 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 1y 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 https://github.com/stackotter/swift-bundler
  • seankit 1y 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 https://github.com/swiftlang/swift-build
    • tough 1y 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 1y ago
        yep Swift build Works magnificently but only for Mac so far
        • tough 1y ago
          ohh gotcha, well hoping it gets linux/win support soon too, it's great!
• Hashex129542 1y 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 1y 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.
    • rcruzeiro 1y 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 1y 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.
• travisgriggs 1y ago
  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 1y 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.
    • rcruzeiro 1y 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. https://github.com/swiftlang/swift-evolution https://github.com/swiftlang/swift-evolution
• ardit33 1y 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.
  • andrekandre 1y 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?
  • danielscrubs 1y 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.
  • ak_111 1y 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?
  • hn-acct 1y 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?
• deleted 1y ago
  [deleted]
• monkeyelite 1y 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.
  • adamwk 1y ago
    There’s a section in the proposal about this: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0453-vector.md#sequence-and-collection https://github.com/swiftlang/swift-evolution/blob/main/propo... 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 1y 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).
      • 1y ago
• DidYaWipe 1y 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 1y 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: func startObservation() { withObservationTracking { print(store.state.toggle) // Here we have the new value (+ it is called once before any change) } onChange: { Task { startObservation() } } }
    • DidYaWipe 1y 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.
• finalfantasia 1y ago
  “Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff…” — Chris Lattner, 2024 https://blog.jacobstechtavern.com/p/apple-is-killing-swift https://blog.jacobstechtavern.com/p/apple-is-killing-swift
  • singularity2001 1y ago
    how can the next great language avoid the trap of syntax bloat while providing the same extraordinary functionality
    • brainzap 1y ago
      By not providing them. Say "sorry, here is an ugly workaround, generate this xy code."
  • aatd86 1y ago
    I wonder why the author left Go out of his list of examples of language stewardship.
  • viktorcode 1y ago
    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.
• bsaul 1y 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 1y ago
    which is better?
    • singularity2001 1y ago
      Swift started from beautiful syntax rust has ugly syntax Swift is becoming more rust like but also safer
    • viktorcode 1y 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.
    • bsaul 1y 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).
• nhojb 1y 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 1y 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.
• jmull 1y 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.
  • tempaccount420 1y 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.
  • myHNAccount123 1y 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 1y ago
      People like this just complain. Without pointing to anything real or saying anything meaningful. You just have to ignore them like spam.
• viktorcode 1y ago
  Spans and inline arrays are the two missing pieces of performance puzzle Swift needed. I'm super hyped for the release!
• xmorse 1y ago
  does it really matter if it takes 1 hour to compile?