(评论)
(comments)

原始链接: https://news.ycombinator.com/item?id=43940539

这篇 Hacker News 讨论帖围绕 Swift 6.2 展开,反应褒贬不一。一些人对新增功能,例如测试中的自由格式标识符,表示质疑;另一些人则赞赏诸如所有权模型更新和异步 API 等改进。人们担心语言变得过于复杂,类似于 C++ 或 Rust,并且关注点正在从通用编程转向 SwiftUI。 讨论还涉及 Swift 在 Apple 生态系统之外的实用性。一些人认为它可以作为 Linux 或嵌入式系统上的 C++ 替代方案,另一些人则指出文档不足以及 Apple 明显的关注点。关于 Swift 在服务器端开发中相较于 Go、Rust 或 Java 等语言的优势,存在争议,有人指出其在 Apple 环境中的代码复用优势以及 iOS 开发人员的熟悉程度。最后,讨论还涉及 Swift 是否使用了垃圾回收器(它使用确定性引用计数)。

相关文章
  • Swift 6.2 的新特性 2025-05-10
  • 雨燕6 2024-09-18
  • (评论) 2025-03-14
  • (评论) 2024-06-13
  • (评论) 2025-04-18

  • 原文
    Hacker News new | past | comments | ask | show | jobs | submit login
    What’s new in Swift 6.2 (hackingwithswift.com)
    90 points by ingve 4 hours ago | hide | past | favorite | 57 comments










    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.”



    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.



    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



    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.



    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.



    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



    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


    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.



    Do you try to put everything on the main actor to dramatically reduce your debugging time?


    Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.


    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.


    Everything probably already is or should be


    > 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?



    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."


    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.



    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.


    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.


    I would not have even approved it. But that's just me.


    Kotlin has this, but it's basically only ever used for tests. I've never seen a real world method with a backtick name.


    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.


    That's how Zig tests work. This is basically a function with a different syntax.

    test "strip html tags from string" {

      ...
    
    }


    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.



    The other reason is interop with other languages, which might have their own rules for identifiers.


    Except people can also use arbitrary identifiers in their own code now?


    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.


    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.



    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"



    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.



    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.



    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.



    IMO async/await and Combine are two completely different things.

    What is the alternative to Combine's CurrentValueSubject or combineLatest()?



    AsyncExtensions implements many Combine-like patterns in structured concurrency.


    So it's becoming C++?


    It's becoming Rust.


    That's my feeling, and it makes me sad because I have largely given up on C++ for that reason.


    Considering Swift was primarily written in C++, perhaps Swift was always destined to follow the same path?


    Is having too many ways to solve a problem an issue for solo indie developers?


    Right? I don't get this persons sentiment and I don't understand how it relates to the post in particular.


    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?


    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.


    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)



    Apparently Arc Browser is written in Swift: https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc...


    Also using it in an embedded Linux project [1]. 75% of code written for this project is Swift. The rest is Dart and C/C++. It’s a productive language.

    [1] https://forums.swift.org/t/an-embedded-audio-product-built-w...



    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.



    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:

    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.



    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.


    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.



    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.


    It's a high level language that doesn't get in your way.


    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.



    The advantage is obvious if you already use Swift.


    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



    > 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.



    [flagged]



    Seriously, smart people making dumb decisions.


    I can't help but think some of the Swift leads just really like Haskell.


    Escaping symbols with backticks to circumvent illegal characters and reserved keywords is a feature coming straight from Scala actually.


    Haskell names can't have spaces in them, though. Names with spaces is much more reminiscent of Algol 68, or old-style Fortran.






    Consider applying for YC's Summer 2025 batch! Applications are open till May 13


    Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact



    Search:
    联系我们 contact @ memedata.com