Live data from Hacker News

What’s new in Swift 6.2

hackingwithswift.com

151–160 of 258 posts

Re: What’s new in Swift 6.2

#151
post #123
post #116

Earlier quoted context omitted.

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…

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 hopefu…

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.

Re: What’s new in Swift 6.2

#152
post #142

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 ca…

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 fram…

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

Re: What’s new in Swift 6.2

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

Re: What’s new in Swift 6.2

#154

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 ca…

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.

Re: What’s new in Swift 6.2

#155
post #142

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 ca…

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 fram…

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.

Re: What’s new in Swift 6.2

#156
post #132

Earlier quoted context omitted.

And no Steve Jobs to pull them down to earth.

Steve Jobs, of course, was always involved in the details of programming languages targeting his platform.

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.

Re: What’s new in Swift 6.2

#157

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 ca…

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 act…

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

Re: What’s new in Swift 6.2

#158
post #131

Earlier quoted context omitted.

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

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 ap…

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

Re: What’s new in Swift 6.2

#159

Earlier quoted context omitted.

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 indi…

FWIW Android's XML layout is actually pleasant to use (though Jetpack Compose is also quite good).

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.

Re: What’s new in Swift 6.2

#160
post #142

Earlier quoted context omitted.

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 fram…

Objective-C being stuck in the 1990s forever was not necessarily a good thing.

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.
Post reply on HN