Hacker News Reader

I can share my love of Swift

- Optional has made null pointer exceptions virtually non-existent. There are occasions where deserialization does result in a nil value where one is not expected, but that's rare. I think this is as massive as garbage collection was back in the day.

- The language is in a sweet spot between something convoluted and heavy like Java and something overly simplistic like PHP/Ruby/Python. It's perfect for software development and large code-bases with a low learning curve.

- There is no magic (methods, properties, etc). Everything is explicit but not wordy. This may change in the future but I hope it never does.

- It's more legible than Kotlin with fewer unnecessary language features. Speaking of which...

- It's a simple language and its syntax is straight forward

It's not a perfect language:

- The package manager needs a lot of work

- Extensions can lead to confusion (eg. in the case of conformance to protocols (interfaces)).

- I would like an optional garbage collection system for long-running processes (e.g. server-side applications)

- I would like it to perform even better

You can nitpick syntax anomalies with any language, but a language is defined by how easy it is to scale to multiple programmers, how applicable it is to a problem, how well it performs, how easy it is to read for someone new to the system, how it helps the programmer not commit mistakes, etc. Of all the languages I've written, none has been as successful in all regards as Swift.

> It's a simple language and its syntax is straight forward

Wha? It has about 100 reserved words — more than C++, now, I think. Even its own designer said [1]:

“You’re unlikely to run into anybody that says that Swift is a simple language. Swift is a complicated language.”

If you consider Swift simple, what language do you consider complex? Of all the languages I've written, none has been as complex as Swift.

[1]: http://atp.fm/205-chris-lattner-interview-transcript

Yes, it's simple from a user's perspective. Even the quote in your comment is then followed by Chris talking about how easy it is to learn Swift (e.g. `print("Hello world!")` is a valid program).

There are a lot of keywords in Swift, but that is not what makes a language complicated. They are all in English, after all. Symbols and unique concepts are what complicate a language because they are not explicit or unorthodox. For instance, using `:=` or `(setq x (1+ 2))` for assignment instead of `=`.

> - Reference counting is a bad compromise between the unpredictability of GC, and the burden of explicit memory management. It's mostly unobtrusive, but I've seen examples of code that require careful and non-obvious use of weak to avoid memory leaks, (sorry, I don't have the reference handy).

This is such a bizarre statement to me. I have to wonder if the commenter has ever dealt with production systems or code that uses GC? Because with years of writing and tuning Java servers, I've long since come to the conclusion that GC is largely a false economy.

You still have to deal with memory leaks but the cause this time is objects maintaining references they don't need. Sure GCs become cleverer at detecting unused forests of objects and so on but this largely makes another problem worse: so-called stop-the-world pauses for a full GC. It's still an issue you have to deal with on Java, Go and probably every GC language.

This isn't to say that ref-counting is a panacea (what is?). Particularly on servers the critical region for updating the ref-count itself can become hot and a bottleneck.

But this isn't really a problem on mobile app code. I've long said that iOS's uses of ref-counting (ARC since 5.0+) is a strategic and competitive advantage to Android's Dalvik/Java GC.

Google's Plan9 2.0 (ie Fuchsia) makes me sad (for many reasons). Just one is that they've embraced Dart/Flutter at the application level (which isn't required as anyone who works on it will tell you, yada yada yada) but Dart is such a strange choice because it still relies on GC. What's the point?

Oh and just to be pedantic, you list ref-counting as a negative of Swift compared to Objective-C. ARC is orthogonal to that. Like I said, ARC came about in iOS 5.0.

IDK about Java, but the GC characteristics of Go seem pretty ideal for UI code. I think they're at sub-1ms pauses on multi-GB heaps now. So even if you want to run at 100 fps it shouldn't be a big obstacle to making frame rate. Of course there's a throughput trade off, but same thing with reference counting.

Although I guess it doesn't matter much since the library ecosystem isn't there. I think it would have been an interesting choice for Flutter instead of Dart though.

For just memory management, I don't see the downside of GC (vs reference counting) if the latency is good enough. Sure you can still leak memory by maintaining references but at least it deals with cycles (and it's one less thing that any dependencies can screw up).

If GC latency is OK, the only remaining advantage of reference counting I can think of is the deterministic destruction of non-memory resources like file handles etc.

I've worked with production Java systems for many years, and have had to tune GC, implement suballocation schemes etc. It is definitely not a panacea, and I meant to say that it was not, in my original comment. But at least GC fixes mostly leave the source code alone (ignoring suballocation tricks). I find reference counting to be less intuitive, and I don't like the fact that fixing reference counting problems require modifications to source more often.

My Swift usage stopped in 4.x, so I'm unfamiliar with the 5.0 improvements.

I actually like Swift: advanced type system and compiler, clean syntax, very fast.

I think optionals are a great way of saying: “Hey developer, this value can sometimes be nil; be sloppy or not, your call.”

Any language you pick is an interplay of choices and compromises. No such thing as perfect.

> very fast

This is a common sentiment, but it rarely holds up to closer scrutiny (such as measurements...). Swift is both slow to run and very slow to compile. Both compile and runtime come with extremely high variance. Such unpredictability is arguably even worse than just plain slow performance.

In most of these benchmarks [1] Swift's performance comes pretty close to that of Rust. So yeah, I would call that very fast.

[1] https://web.archive.org/web/20190402100249/https://benchmark...

Try some JSON benchmarks with Codables in Swift vs serde in Rust. Rust smokes Swift, something like 20x.

Incidentally I've spent considerable effort on this problem, including writing a prototype faster JSON parser in Swift (still about 3x slower than Rust, but a huge speedup over what's there). I couldn't get anyone in the Swift community to care enough to motivate me to finish the work, which is indicative of a deeper problem: Swift just doesn't have "performance culture," the benchmark game results notwithstanding.

Hmm...when I look at those numbers, Swift only comes close in a very few, is significantly slower in most (50%-4x) and much slower in one (45x):

fannkuch / pidgins: essentially the same

binary-trees / fasta / Mandelbrot: ~ 1.5x slower

spectral-norm / reverse-complement: >= 2x slower

k-nucleotide / n-body: ~4x slower

regex-redux: 45x slower

Up until Swift 4, compilation took longer than with Objective-C according to my experience. Not sure how much Swift 5 has changed things.

- Optional is a nuisance.. People are going to fiddle with ? and !

And that is GOOD. This mean that wrong code look wrong:

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

and many instances of it mean something is badly wrong in the codebase, and the developer(s) haven't adapted to how must be done.

In contrast:

    bad.shit.happends

Good look with that...

- "let" is a mess

Overloading keywords have problems, but in this case the rules are simple. And is not that many context to worry about.

- I would much rather have = mean assignment

Agree. Overloading keywords are fishy, but operators are in another league!

Have some sense for maths but in other contexts is not worth the extra "feature".

- Reference counting is a bad compromise

You mean, ARC. Is not exactly the same, and the compromise is totally worth. I work with .NET for iOS/android and man, is heavy.

All is about what is default.

With GC, by default, eat memory and unpredictable destructors. With (A)rc only need to worry about break cycles. That not happened often enough to be a real problem

BTW, I have use obj-c, pascal, .net, python, rust. The ARC model is the best for most kind of code most do. I honestly have more unpredictable and unfixable problems with GC (mostly on android with underpowered devices), so I prefer to get something less automatic..

> [Using Optional] mean that wrong code look wrong

...as long as you don’t use any implicitly unwrapped optionals (which virtually all Mac/iOS code does), or use any frameworks that predate Swift (like AppLit/UIKit/Foundation), or wrap any C libraries (most third-party libraries in the world).

So basically that’s true for the 5-line samples showing how cool Optional is, and no real program I’ve ever written. It was a nice experiment but in practice I have more issues stemming from Optional than I ever did with nil.

> In contrast: bad.shit.happends

Do you not read any Swift forums? There are newbies posting every single day asking why "a.b.c" crashed in Swift.

> There are newbies posting every single day asking why "a.b.c" crashed in Swift.

That is fair. And totally show why optionals are the right thing. Because obj-c and others NOT have it the world suck MUCH more. That is why nulls are the billon dollar MISTAKE with capital letters.

The solution is to more and more languages, libraries and frameworks embrace the idea of algebraic types, not just declare "interfacing with old codebases with this huge MISTAKE is not nice, so why bother??".

What rust make nice is declare stuff as UNSAFE. I wish this was the case with swift and obj-c so make clear to everyone that you have entered the realm of nasty things and must be more careful...

Objective-C has "optionals": every object pointer can be `nil`. What it gets right is that it doesn't implicitly treat a `nil` as a logic failure.

That is not optionals, at all.

I wonder if you have real experience with swift or you’ve just been looking at the language from a distance, because i disagree with pretty much every point you made.

Optional is the best thing that could happen to a language that allows nil values ( the only other option being not allowing them at all, but that’s not common).

If let ( and guard let) is an elegant idiom for unwrapping optionals safely, but that’s about the only cass you’re going to see a let in something that looks like an expression. The only complain you could have in that part in the language is between let and var, but that’s actually quite useful in practice for self documenting code.

Operator overloading could become dangerous, but it seems that it is used very sparingly in the swift ecosystem. Standard library doesn’t overuse it, so people don’t as well.

Reference counting to me has quite the same drawback as GC : it makes you forget about memory cycles and ownership. But apart from rust who tried something very different ( and is scaring a lot of developers), once again i don’t see a lot of other options.

I do have some experience, playing with an iOS app for several months, through various versions of the language (3.x, 4.x). But this was as a hobby. I liked Optionals when I learned about them, and less as I started using them. I found that libraries sometimes changed return types, e.g. T to T? (or vice versa). The feature struck me as having some drawbacks similar to Java checked exceptions: the rigor required ran counter to clean and easy to understand code. Did I just not get the design of the feature? Perhaps, but I did find it very difficult to avoid tweaking code with ? and !.

I have no problem with var vs. let. I like that distinction. And I do understand that let is used only sparingly in expressions. But that's what bugs me about it, it is so limited. It is not an "orthogonal" feature, (usable in any expression). An expression is ideally functional (no side effects). Let definitely does have a side effect, declaring and binding an identifier. I find it awkward to mix the two ideas. This may be many years of mental baggage, from C, C++, and Java, but it is there, and I think that the introduction of such a major side-effect into the world of expressions is a genuinely bad idea.

GC vs. reference counting: GC really does allow you to forget about memory management. Until you start running into problems requiring GC tuning. But then, the fixes tend to leave the code alone completely. With reference counting, tuning requires more intrusion into code. Yes, this is subjective. Just explaining my reasoning.

Lots of misunderstanding of how optionals are designed to work in this comment!

Whether there is misunderstanding by the grandparent post or not, in practice there are a lot of people who do just play with ?/! until they manage to get code to compile and then hope for the best.

You can see it all over the place in code people write, posts on Stack Overflow, etc. The Apple Swift book does a poor job explaining the rationale and benefit of using option types.

Genuine question - does this not highlight a problem with the language on some level?

If a developer is just fiddling with optional-related operators until the compiler is happy -- in any language, not just Swift, e.g. Kotlin -- instead of actually understanding what they are doing at any fundamental level, that's not a language problem.

I wouldn't want to work with someone like that I doubt anyone else would, either.

I would believe it's an education problem, in that we teach things like recursion and local variables (the fact that the same variable can have different values in a nested call to a function) in intro CS classes but we don't really teach how post-NULL languages handle optionals (Option, Maybe, etc.). But it's something that should be part of an effective programmer's knowledge. It's not too unlike buffer overflows—all the people writing UNIX until 1988 were skilled, educated, experienced people, but at the time none of them were really aware just how bad buffer overflows were.

I never learned those in university, so I don’t think that’s a sufficient excuse. Any developer should understand, or want to understand, the fundamentals of the language they are using.

It highlights some of challenges of bridging Swift with ObjC APIs.

Fully Swifty UIKit or whatever it is that eventually replaces UIKit can’t come soon enough. As Swift has matured, UIKit/AppKit has quickly become the weakest link in the Apple platform dev experience.

Yes, which Apple has done with some success (Toolbox -> Carbon -> Cocoa) but we've also seen how WPF, etc have gone down. The hard challenge is the migration path, and you can't commit until the language and tooling is ready.

Optionals when used right really cleans up code that deals with a lot of deeply nested data structures. There is a learning curve though. When you are not used to them so there’s a lot of frustration and sometimes forced unwrapping until it clicks.

Is it only the developers fault when critical parts of a programming language are hard to grasp?

I suspect that might be a sympton of excessive complexity and parent's example of C++ seems spot on.

But optional is very simple concept.

However, break from the old habits is hard. I was there moving to f# and the first month or so I try to bend the rules.

Same now with rust. I try to mold it as a OO language, and get SUPER annoyed with how rust is so different. But you embrace algebraic types and pattern matching and suddenly a lot of other hidden problem simple disappear forever.

Proper optional use is indeed a habitual thing. When I was first transitioning from ObjC to Swift I found them to be an annoyance, but after using Swift for the past few years I find myself wondering how my ObjC code ever ran as well as it did without them. I’m now reluctant to use languages that lack option types.

> I would much rather have = mean assignment, and use function call notation when I really want functions to run.

And then you end up with Java where you have to write so many boilerplates for getters and setters, even if they are only plain attribute access, just in case you want a function later.

I agree that a very common Java pattern is to create getters/setters for every private field. Which is just stupid, might as well have the members be public. To use the popular phrase, Java classes like that have a "bad code smell". It tells me that the author of the class doesn't really understand how it should be used. I think a well-designed class will have private members and public member function interfaces that don't resemble each other very much.

From your comment looks like you do not get Swift anf that prevents from getting why it is loved. There is no need to "fiddle" with ? and ! Optionals are not that complex. And there is nothing wrong with let. It has nothing to do with optionals.

"if let x = someOptional" unwraps the optional, no?

And "let x = someOptional" doesn't, right?

So the first form does have something to do with Optionals, and it is true that the two forms of let behave differently with respect to them.

(I have moved on from Swift, so if things have changed since Swift 3.x and 4.something, my apologies.)

I agree that's confusing coming from an imperative context. The core misunderstanding here is that `let` is a binding, not a variable declaration. It's binding a name to a value, not creating a variable which can be modified. Therefore the `if let` example is saying "if we can bind the value inside the optional to a name", while the regular let example is just saying "bind the optional to x"

I get all that, but in one case the type of the value bound to the declared identifier is T, and in the other case it is T?. To me, that violates The Law of Least Astonishment, but that is admittedly subjective.

Actually, in `if let x = someOptional`, you should rather see it like this: `if (let x = someOptional)`. If that second part were a function, it would be `() -> Optional<T>`.

That is to say, the if statement is satisfied if the "result" of the "function" (if you follow me; clearly I don't mean it's actually a function in the implementation) returns .some(T) (not nil) rather than .none (nil).

That we can do an assignment with `let` is just syntactic sugar for:

    if someValue != nil {
        let x = someValue!
    }

Basically, we want to know if the value is non-nil. There are instances where the result can be nil, and if so, nothing gets assigned. For example:

    protocol Fruit { }
    protocol SeededFruit: Fruit { }
    protocol SeedlessFruit: Fruit { }
    struct Mandarin: SeedlessFruit { }

    let mandarin = Mandarin()
    
    if let someFruit = mandarin as? SeededFruit { }

Okay, so the compiler will actually disallow this, but you get the basic idea: `mandarin` is not a SeededFruit, the cast will always be false, therefore someFruit will be nil, therefore the "result" of the "function" will be nil, which is counted as false.

The thing is, this isn't specific to the `let` keyword, either. You could just as easily define a new variable with the `var` command.

So `let` and `var` don't mean different things in different contexts and never have. Swift just allows them to be used as syntactic sugar in if statements.

Just a late addition to anybody who sees this, I tend to think of `if let` and `if var` statements in Swift as syntactic sugar for:

    switch someOptional {
        case .none:
            // whatever
        case .some(let x):
            // do stuff with x
    }

I don't think there is a 'love' so much as it's the future of iOS platform.

Swift is just too much, too many things, and yes, they kind of dorked optionals. To me it's just trying to hard.

I'm glad I'm not the only one who feels this way. I used to absolutely love writing Objective C, like totally get into a zone and lose track of time. I've never managed to achieve that same feeling with Swift.

This is what most people seem to totally miss.

You want to solve interesting problems. You do not want interesting tools getting in the way. A boring, old, flawed tool would often work better for solving the problem without interruptions.

> This is what most people seem to totally miss.

No, they don't 'miss' it. I think what you're missing is that is perfectly possible to 'get' optionals and be as, if not more, productive than in ObjC. Not all people get the Swift model and for them it may be unintuitive, but many do get it.

I find it distressing that some developers just want to bang out code as fast as possible and any tool that tries to impose a bit of good software engineering in between that is seen as 'evil'.

I've seen similar sentiments expressed about Rust i.e. 'I'd rather take my memory leaks and data races over the borrow checker'. That's fine, but please be aware that I'll try my best to not let you execute any code on my machine if that's how you approach the craft.