Hacker News Reader

Comment by ppeetteerr | Hacker News Reader

I have been writing code for over 10 years and I can comfortably say that Swift is one of the best languages today than many other languages at a much later stage in their life (hey there Java!). I'm not talking about the standard lib, I'm talking primarily about the language and how well one can express their ideas with it without shooting oneself in the foot.

The only reason I suspect that Apple is not all over Swift is that many of their programmers are the type of coders who like falling back to C when they feel they need a performance boost. Perhaps they like the message-like nature of ObjC. Dunno. I can say that I've been able to get apps to 0 fixable crashes with Swift (some crashes are system level), not something I've ever done with ObjC, let alone Java for Android.

View on HN

It was a couple years ago, but I spoke with one of their engineering managers about Swift adoption within the company. His response was that it was being used for new apps/projects, but not so much for existing codebases.

Having worked on a large Obj-C codebase that began adopting Swift, there are definitely some headaches involved in Obj-C/Swift interop, and you often aren't getting many benefits of Swift unless your new code has few to no dependencies on / is not depended on by Obj-C code, unless you can refactor it into Swift.

Given how quickly it seems they've been forced to ship, I can understand not wanting to deal with these issues, or not having the time to address them.

There are three advantages that I saw immediately upon switching to Swift:

- It was easier to hire developers

- Code was less prone to null pointer exceptions

- There were fewer assumptions when deserializing JSON into a struct/object

We moved a very large iOS app over to Swift, and the first two benefits are really huge. I know people have opinions on these things, and both sides are right, but the really strong typing and enforced nullability have been hugely important to getting junior engineers contributing to the codebase.

Not saying that it's an unsolvable problem elsewhere, it's just an anecdotal benefit we got

Android I've done for embedded apps, by using immutable data flows only, Optionals everywhere, and very careful debugging for memory leaks. Go to a screen, force gc, go back, force gc, memory before and after should be the same, we'd find leaks of as little as 4kb this way, and it was every bit as excruciating as it sounds.

It's weird using Swift and realizing how much of that trouble we went through is avoided just by not using a GC'd language

I worked in Swift for just over a year. Love the language. But unfortunately you can still get reference cycles that leak memory. And they can be basically unsolvable with a large enough app. Merely avoiding GC doesn't fix all your problems!

Isn't reference counting just a different style of garbage collection? I see lots of articles saying that swift both is and isn't garbage collected, and I'm curious what the proper answer is here.

Not quite the same as garbage collection. When an object has a pointer null'ed, that object's reference count is reduced by 1. When the reference count reaches 0, that object is remove from memory. You could still cause memory leaks like so:

```

struct Node {

  var next: Node?

  var prev: Node?

}

var a = Node(next: nil, prev: nil)

let b = Node(next: nil, prev: a)

a.next = b

```

These two objects will persist in memory for the entire life of the app even when all reference to a and b are gone, except for their references to one another.

Yes, but the overhead is much smaller compared to other techniques, and it's simpler to predict runtime behavior because there is no nondeterminism when ignoring the runtime which would otherwise be introduced by collector behavior.

with all those differences, reference counting is not garbage collecting, it's like calling free in c garbage collecting, which is incorrect.

https://en.m.wikipedia.org/wiki/Garbage_collection_(computer...

Reference counting is listed as a strategy to achieve garbage collection. Broadly speaking, garbage collection is the process of automatically managing the lifecycles of objects in memory, which reference counting certainly achieves.

I've gotten the impression (and that's all it is, could be totally wrong) that Apple's a little hesitant to go all in until ABI stability arrives in Swift 5. Even after that, I doubt they'll do much rewriting of old stuff; but I bet we'll see most new stuff being in Swift then.

> many of their programmers are the type of coders who like falling back to C when they feel they need a performance boost

Question for anyone who knows: what percentage of Apple's application-software programmers double as system-software/kernel programmers? Because I expect that'd color their preferences for a daily-driver language quite a bit.

Reply on news.ycombinator.com