211–220 of 258 posts
"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.…
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 backtrackin…
“Due to these insane changes” Which changes?
Earlier quoted context omitted.
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 DS…
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.
Earlier quoted context omitted.
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 { } sy…
Have you tried Skip Tools yet? It’s a set of tools intended to do just that. https://skip.tools/
Earlier quoted context omitted.
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…
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.
In a sense, MacRuby was trying something similar, but the dependency on a GC doomed it.
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 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.…
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…
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.
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.
Earlier quoted context omitted.
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.
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…
Or was there issue more intrinsic to the design of the language itself?