Comment by VerifiedReports | Hacker News Reader

Comment by VerifiedReports | Hacker News Reader

Parent Full thread

VerifiedReports

I started using it around 2018. After being reasonably conversant in Objective-C, I fully adopted Swift for a new iOS app and thought it was a big improvement.

But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes."

But then: "Have one source of truth." Um... you can't do that when every data structure is COPIED on every function call. So now what? I spent so much time dicking around trying to conform to Swift's contradictory "best practices" that developing became a joyless trudge with glacial progress. I finally realized that a lot of the sources I was reading didn't know WTF they were talking about and shitcanned their edicts.

A lot of the crap in Swift and SwiftUI remind me of object orientation, and how experienced programmers arrived at a distilled version of it that kept the useful parts and rejected dumb or utterly impractical ideas that were preached in the early days.

I think Swift was developed to keep a number of constituencies happy.

You can do classic OOP, FP, Protocol-Oriented Programming, etc., or mix them all (like I do).

A lot of purists get salty that it doesn’t force implementation of their choice, but I’m actually fine with it. I tend to have a “chimeric” approach, so it suits me.

Been using it since 2014 (the day it was announced). I enjoy it.

No Swift was developed as a strategic moat around Apple's devices. They cannot be dependent on any other party for the main language that runs on their hardware. Controlling your own destiny full stack means having your own language.

Apple already had that "strategic moat" with Objective-C. It was already a language you could effectively only use on Apple platforms (the runtime and the standard library only run on Darwin) and for which Apple controlled the compiler (they have their own fork of Clang).

I suspect that it was developed, in order to make native development more accessible. SwiftUI is also doing that.

They want native, partly as a “moat,” but also as a driver for hardware and services sales. They don’t want folks shrugging and saying “It doesn’t matter what you buy; they’re all the same.”

I hear exactly that, with regard to many hybrid apps.

Prefer structs over classes != only use structs.

There are plenty of valid reasons to use classes in Swift. For example if you want to have shared state you will need to use a class so that each client has the same reference instead of a copy.

Yes, that's what I said.

> But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes."

This is the same way that C# works and C and C++ why is this a surprise?

Neither C++ nor C pass classes by reference by default (what even is a C "class" other than a struct?).

You are correct - it’s been ages since I’ve done C. The distinction is in C#.

> when every data structure is COPIED on every function call

Swift structs use copy on write, so they aren’t actually copied on every function call.

They are, as far as "Have one source of truth" is concerned. That is what parent is talking about.

They don’t, by default. That’s something you have to implement yourself.

It’s a common misconception that comes from the standard library data structures, which almost all do implement CoW

Nowhere does it say structs provide “one source of truth”. It says the opposite actually- that classes are to be used when unique instances are required. All classes have a unique ID, which is simply it’s virtual memory address. Structs by contrast get memcpy’d left and right and have no uniqueness.

You can also look at the source code for the language if any it’s confusing. It’s very readable.

You're re-stating his exact problem while trying to refute him.

No, I’m not. OP is conflating multiple guidelines for different purposes and attempting to use them all simultaneously.

> OP is ... attempting to use [multiple guidelines] simultaneously.

No, he's literally explaining why the guidelines can't be used simultaneously.

They aren't supposed to be used simultaneously, which is literally what my comment was explaining. Different guidelines to solve different problems.

Have one source of truth is a universal guideline.

Prefer structs over classes is a universal, if weak, guideline.

It's funny how people can be all hung up on composability of things like type systems, and then completely blow off the desire for composability of guidelines.

Reply on news.ycombinator.com