41–50 of 258 posts
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?
[flagged]
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.
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.
What is the alternative to Combine's CurrentValueSubject or combineLatest()?
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?
EDIT: Yes, ref. counting is garbage collection, before the replies blow up. haha
> 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…
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.
> 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…
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 lo…
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.
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?
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.
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.
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.
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.
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.
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.