[HN Gopher] What's new in Swift 6.2
___________________________________________________________________
What's new in Swift 6.2
Author : ingve
Score : 180 points
Date : 2025-05-09 20:20 UTC (1 days 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.
| favorited wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 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.
| hocuspocus wrote:
| 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 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.
| rcruzeiro wrote:
| 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.
| ackfoobar wrote:
| 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.
| rcruzeiro wrote:
| The second example is moot since, outside the Apple
| ecosystem, you don't even need to know Xcode exists.
| ardit33 wrote:
| 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.
| 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)
| rcruzeiro wrote:
| Knowing which parts of Foundation will explode on your face
| on Linux is most of the challenge of doing non-Apple Swift
| code.
| jshier wrote:
| 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.
| 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.
| rcruzeiro wrote:
| 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.
| 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
| favorited wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| _> 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.
| lukeh wrote:
| 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...
| Hashex129542 wrote:
| 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.
| viktorcode wrote:
| Unlike Rust, it has some C++ binding, which is extremely
| useful.
| 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.
| tiltowait wrote:
| 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).
| rTX5CMRXIfFG wrote:
| 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 wrote:
| You can't exhaustively handle an enum with just an
| integer.
| layer8 wrote:
| You want to exhaustively handle all 500 valid HTTP status
| codes (cf. RFC 9110)?
| dagmx wrote:
| 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
| layer8 wrote:
| 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.
| nulld3v wrote:
| 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 wrote:
| 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 wrote:
| 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!
| jibal wrote:
| 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.
| raydev wrote:
| > 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.
| 90s_dev wrote:
| 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 wrote:
| The issue is that it's not a problem in the first place.
| jibal wrote:
| 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.
| 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?
| int_19h wrote:
| The other reason is interop with other languages, which might
| have their own rules for identifiers.
| codr7 wrote:
| I'm trying and failing miserably to think of a single
| example of such a language.
| akdor1154 wrote:
| .NET allows pretty much anything except a space, i think?
| codr7 wrote:
| And you can call into .NET (I assume that means C#)
| directly from Swift?
| neonsunset wrote:
| Kind of? :)
|
| https://github.com/royalapplications/beyondnet
| layer8 wrote:
| 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).
| layer8 wrote:
| It lessens the likelihood of a collision, but doesn't remove
| it.
| Starlevel004 wrote:
| Kotlin has this, but it's basically only ever used for tests.
| I've never seen a real world method with a backtick name.
| rcruzeiro wrote:
| 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 wrote:
| 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 wrote:
| 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.
|
| https://github.com/Quick/Quick
| wingerlang wrote:
| Why do you need both an identifier and a text? I have this
| test name 'testAddingNewCardDataResultsInProperlyCombinedCard
| DataButNoNewCardsUnlocksBecauseWeStillHaveUnlearnedCards',
| 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.
| 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?
| rcruzeiro wrote:
| So following this same reasoning Python should become C?
| codr7 wrote:
| 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 wrote:
| 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.
| codr7 wrote:
| That's my feeling, and it makes me sad because I have largely
| given up on C++ for that reason.
| Hashex129542 wrote:
| It's becoming Rust.
| codr7 wrote:
| Which I never even bothered with, for that reason.
| metaltyphoon wrote:
| 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.
| 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()?
| lukeh wrote:
| AsyncExtensions implements many Combine-like patterns in
| structured concurrency.
| andrekandre wrote:
| > What is the alternative to Combine's CurrentValueSubject
| or combineLatest()?
|
| combine latest et al can be found in async algorithms from
| apple*
|
| https://github.com/apple/swift-async-algorithms
|
| * though current value subject is not there its not hard to
| make one if you need it
| amichail wrote:
| Is having too many ways to solve a problem an issue for solo
| indie developers?
| myHNAccount123 wrote:
| Right? I don't get this persons sentiment and I don't
| understand how it relates to the post in particular.
| codr7 wrote:
| 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 wrote:
| 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.
| jimbokun wrote:
| 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.
| favorited wrote:
| 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.
| jimbokun wrote:
| 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.
| 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 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > case _401 or case error401.
|
| I'm not seeing why it's worth a whole language feature to avoid
| prefixing strange identifiers.
| sedatk wrote:
| I don't think it's the sole reason, but I find that example
| odd for sure.
| iamcalledrob wrote:
| 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.
| DidYaWipe wrote:
| 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.
| Defletter wrote:
| > 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.
|
| 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.
| 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.
| strongpigeon wrote:
| 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
| hudsonator wrote:
| As someone who has worked with him, no he is not a nice guy.
| He is the opposite of a nice guy.
| strongpigeon wrote:
| I'd love to believe you, but you're not giving us much to
| go on with
| dkga wrote:
| The last sentence is exactly how I would describe Paul Hudson,
| as a HwS reader/user.
| rockbruno wrote:
| 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 wrote:
| 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.
| 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.
| catapps wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| yep Swift build Works magnificently but only for Mac so far
| tough wrote:
| ohh gotcha, well hoping it gets linux/win support soon
| too, it's great!
| marcellus23 wrote:
| 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.
| viktorcode wrote:
| 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.
| Hashex129542 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| saagarjha wrote:
| FWIW Android's XML layout is actually pleasant to use
| (though Jetpack Compose is also quite good).
| cosmic_cheese wrote:
| 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.
| rcruzeiro wrote:
| 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 wrote:
| 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.
| wingerlang wrote:
| 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.
| ardit33 wrote:
| 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.
| Hashex129542 wrote:
| > but instead it ended up being hydra/monster with too many
| pardagimns, and none of them are good.
|
| So true.
| myHNAccount123 wrote:
| > 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 wrote:
| 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 wrote:
| Many developers have no issue achieving their desired
| designs with Representable or just swiftui.
| viktorcode wrote:
| 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.
| Hashex129542 wrote:
| Yes, https://stackoverflow.com/questions/79589648/actor-
| isolated-...
| travisgriggs wrote:
| 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 wrote:
| 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 wrote:
| > 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
| msie wrote:
| Too many cooks!
| codr7 wrote:
| And no Steve Jobs to pull them down to earth.
| saagarjha wrote:
| Steve Jobs, of course, was always involved in the details
| of programming languages targeting his platform.
| flohofwoe wrote:
| 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.
| codr7 wrote:
| 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.
| elcritch wrote:
| He really was involved. As I understand it Obj-C was
| championed by him. NextSTEP was largely software related:
|
| 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.
| mdhb wrote:
| Conversely, Dart does the exact same thing and is
| probably the best designed language I've ever come across
| SpaghettiCthulu wrote:
| Best designed? Really? Support for something as basic as
| consistent integer types across platforms is non-
| existent.
| elcritch wrote:
| 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 wrote:
| 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.
| ardit33 wrote:
| 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 wrote:
| Seems like another case of the general trend in software
| development of easy things becoming easier and hard things
| becoming harder.
| firecall wrote:
| 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.
| krzat wrote:
| What baffles me the most is testability of SwiftUI. It
| simply does not exist.
| interpol_p wrote:
| 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
|
| [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
| cevn wrote:
| 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 wrote:
| No one tests multi-user functionality, afaict.
| crossroadsguy wrote:
| Has Apple been _testing_ anything in the last many years?
| 90s_dev wrote:
| How much they can get away with.
| deergomoo wrote:
| 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 wrote:
| 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.
| frizlab wrote:
| 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.
| cosmic_cheese wrote:
| 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 wrote:
| 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.
| dlachausse wrote:
| Have you tried Skip Tools yet?
|
| It's a set of tools intended to do just that.
|
| https://skip.tools/
| cosmic_cheese wrote:
| 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 wrote:
| From the FAQ...
|
| > 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
| vips7L wrote:
| The ?.let syntax is terrible. I don't see how anyone thinks
| it's better than doing a normal if != null check.
| jimbob45 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| WD-42 wrote:
| This might just be the long term effects of a platform
| dominated by people who generally value hardware over software.
| panic wrote:
| 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.
| ksec wrote:
| 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.
| saagarjha wrote:
| Objective-C being stuck in the 1990s forever was not
| necessarily a good thing.
| moltopoco wrote:
| 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 wrote:
| 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 wrote:
| 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.
| zozbot234 wrote:
| > 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.
| lenkite wrote:
| 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 wrote:
| 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.
| lenkite wrote:
| 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.
| zozbot234 wrote:
| 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.)
| interpol_p wrote:
| 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
| JimDabell wrote:
| It's easier to write more robust code with Swift, but if Apple
| don't prioritise quality, the language can't fix that.
| jmull wrote:
| 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.
| donatj wrote:
| 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?
| ardit33 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| monkeyelite wrote:
| > 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 wrote:
| There's a section in the proposal about this:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| DidYaWipe wrote:
| "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 wrote:
| > 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() } } }
| hn-acct wrote:
| There is a two parameter onChange modifier btw
| finalfantasia wrote:
| "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
| singularity2001 wrote:
| how can the next great language avoid the trap of syntax bloat
| while providing the same extraordinary functionality
| brainzap wrote:
| By not providing them. Say "sorry, here is an ugly
| workaround, generate this xy code."
| aatd86 wrote:
| I wonder why the author left Go out of his list of examples of
| language stewardship.
| viktorcode wrote:
| 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 wrote:
| 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 wrote:
| which is better?
| singularity2001 wrote:
| Swift started from beautiful syntax rust has ugly syntax
|
| Swift is becoming more rust like but also safer
| viktorcode wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| synergy20 wrote:
| read news about rust and swift these days, it seems modern c++
| might keep its dominance for the future
| metaltyphoon wrote:
| Rust doesn't keep adding features like Swift is. There is a lot
| of stabilization happening.
| jmull wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| viktorcode wrote:
| Spans and inline arrays are the two missing pieces of performance
| puzzle Swift needed. I'm super hyped for the release!
| xmorse wrote:
| does it really matter if it takes 1 hour to compile?
___________________________________________________________________
(page generated 2025-05-10 23:01 UTC)