Hacker News Reader

Comment by setpatchaddress | Hacker News Reader

I certainly don't disagree that there's too much C++ in Swift (the Swift architects write C++ for a living, not ObjC, so it's hardly surprising) but it's not due to trendiness. Most of the features you mention derive from direct experience with Objective-C. Function arguments, property accessors (get/set/didSet), extensions (categories), etc. Every one of these things solves a real problem in the field.

I don't understand your comment about reference counting being intrusive. Apple's implementation, ARC, used in Swift and modern ObjC, is essentially invisible to you if you're using native objects.

View on HN

>I don't understand your comment about reference counting being intrusive.

It's intrusive because you can never really stop thinking about it if you want to write correct code. Here's an example from a very interesting article by Mark Sands [1]:

How quickly can you tell whether or not this piece of code has a reference cycle?

    class ServiceLayer {
        // ...
        private var task: URLSessionDataTask?

        func foo(url: URL) {
            task = URLSession.shared.dataTask(with: url) { data, response, error in
                let result = // process data
                DispatchQueue.main.async { [weak self] in
                    self?.handleResult(result)
                }
            }
            task?.resume()
        }

        deinit {
            task?.cancel()
        }
    }

In my view, reference counting does not combine very well with heavy use of closures.

[1] This is an interesting read: http://marksands.github.io/2018/05/15/an-exhaustive-look-at-...

> How quickly can you tell whether or not this piece of code has a reference cycle?

I'm curious. Does it? I would have guessed the "weak self" would have prevented it.

> In my view, reference counting does not combine very well with heavy use of closures.

It's one of the area where one has to be careful for sure! C++ with smart pointers and callbacks exhibits the same problem. And GC based languages make the pattern easier for sure. However I think this is not even the most critical error source in callback based designs. I think threading issues due to callbacks being executed on different threads cause the most trouble.

Therefore I think languages like Javascript and Dart - which only offer a single thread AND GC - are the the easiest to use for callback based designs.

Yes, there's still a reference cycle because the outer closure implicitly captures self as well. The article explains it in greater detail.

I agree that threading is another big gotcha, arguably a bigger one. Rust has some mitigations against that sort of thing.

I don't agree that get/set/didSet solve actual problems. Languages without property accessors do just fine, but then they don't overload the getting and setting of variables. I would much rather right thing.setField(123), and have setField do whatever actions need to accompany the assignment; than write thing.field = 123, and then have the actions be hidden. What is so f'ing special about x = thing.field and thing.field = x syntax? Why is it so important to stuff additional semantics into that syntax?

As for reference counting: I'm referring to capture lists, and the "unowned self" hack needed with closures. E.g. https://www.raywenderlich.com/966538-arc-and-memory-manageme.... And it gets more complicated with @escaping. I sure don't view all these subtle interactions of closures and ARC to be invisible. This stuff is subtle. Get it wrong and you have leaks.

I agree. Here's an article that has really opened my eyes on how subtle reference cycles can be:

http://marksands.github.io/2018/05/15/an-exhaustive-look-at-...

I have pasted the most egregious example here: https://news.ycombinator.com/item?id=21919728

Reply on news.ycombinator.com