Hacker News Reader

Comment by cageface | Hacker News Reader

Overall I like Swift and it's certainly a massive quality of life improvement for Mac/iOS devs.

But I don't see as much upside for enterprise development. Server side tooling and deployment is still TBD, reference counting adds non-negligible cognitive overhead vs GC in an environment where the downsides of GC matter much less. They will have to build a complete ecosystem of server-side libraries from scratch. And unlike on iOS/OSX, there are already a lot of good and much more mature alternatives.

I wouldn't be unhappy if Swift became a real contender on the server but it seems unlikely to me that it will.

View on HN

Meanwhile, developers are flocking to contribute to the most popular server-side Swift frameworks, like Perfect, Vapor and Kitura. I have followed the development closely, and for such a new language the enthusiasm around these projects are surprisingly big. I think the potential of server-side Swift is underestimated. Of course there's still several features lacking at this point, but that is to be expected of such a new language and will only improve. But yeah, large enterprise deployments are probably too early.

Can you elaborate on the cognitive overhead vs a GC language like golang or java? (With regards to memory)

To me sure there is things you think about but generally memory performance is less of a mental burden.

Also, swift 4 is supposed to support a rust like memory model. Not sure if it's opt in or how it will work but my impression is that it's memory model is about to support some new use cases to make it appropriate for more memory critical tasks.

Speaking only for myself, avoiding or breaking retain cycles is a noticeable problem in Swift code that simply isn't there in languages with a proper garbage collector. Among newer iOS programmers, it's a big point of confusion to figure out when a callback closure should use [weak self] versus capturing self strongly, for example. I've seen a lot of people struggle to understand, completely fail, and end up dogmatically using [weak self] everywhere whether it's needed or not (and sometimes where it's actually harmful).

It is much easier than in either C++ or Rust.

Don't C++ and Rust offer the same facilities? C++ has std::weak_ptr and Rust has std::rc::Weak.

Yes, but they are library calls without any help from the compiler.

How does that make them any more difficult to use?

You have to manually optimize away unnecessary reference counting without help from the compiler.

That is true, but a totally different issue from breaking or avoiding retain cycles.

I have never seen unnecessary reference counting be a problem in Rust. That's because not manipulating the reference count requires an explicit action—.clone()—and borrowing is so expressive that you rarely need to manipulate the counts.

I guess that's because in Rust you never need defensive reference counting thanks to the borrow checker.

Rust's borrow checker actually helps with this a lot- you can hand out references to the Rc-ed data without modifying the count, and the compiler will enforce that the count is not decremented until the references are dead. Combined with the fact that plain references are more idiomatic than Rc/Arc, this leads to pretty similar results.

The compiler can provide better error messages and guide the user, whereas with library types, at least on C++'s case it requires help from external tooling.

With Rust, while you can make use of the type system, it is harder for the compiler to provide such guidance, unless the types are somehow blessed.

What sort of guidance does Swift provide here? And nothing prevents Rust or C++ compilers from becoming aware of these types and providing specialized diagnostics for them.

I said it can, not that it does it already.

My Swift experience is constrained to the GNU/Linux version, so I don't know if XCode is already doing something in this direction.

Sure one can have blessed library types that the compiler knows about, but then from language design point of view it creates a decision between those types and others written by developers, but with similar semantics.

Since you said it's easier than these other languages, I thought you were referring to how the languages work now.

There's nothing wrong with special treatment for stuff in the standard library. C and C++ already do this with many things (e.g. many compilers understand calls like memcpy and will emit optimized code based on the standard library semantics) and Swift gives special treatment to built-in types like Optional.

The distinction here is fairly blurred. The Swift implementation of weak pointers is mostly in the runtime library already, it's just that the compiler hides it a bit so you don't write the names of the calls directly.

Sure, I was more thinking about the language geek point of view.

Thanks for clarifying.

Understood. If you have any ideas for cool diagnostics or other guides, I'd be interested in hearing. I couldn't think of anything offhand, but that's probably just my lack of imagination. I would love to see some static analysis help for finding retain cycles and recommending how to break them, but I'm not sure if that's practical.

Technically true, but very misleading in Rust's case. In Rust you rarely have to break retain cycles in the first place, simply because you don't use reference counting much. Things like "weak self" are not a problem, because closures aren't reference counted unless you explicitly make them so (and in fact I don't think I've ever seen a reference counted closure in practice).

I agree.

I only mentioned Rust, because of ergonomics, since the compiler cannot guide the user unless the types are known.

Or is already something in place to make use of intrisics for better error messages in such cases, instead of just giving a type error?

With @nonescaping becoming the default, this might become a bit simpler. Not too much, but a bit.

Reference counting has upsides and downsides. If you look at the lengths that some Java based projects like Spark have to go to in order tame the GC, then you have to question whether tracing GC is the right choice in the age of hundereds of GBs of memory.

On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. Swift's own collection interface changed massively between 2.x and 3 and I believe the main reason for the redesign was that the old design required too much reference counting. (I'm not completely sure this is an accurate reflection of their thinking though)

> On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden.

This is very wrong on both points. Reference counting has a lot less mental burden compared to GC, because it's predictable. You can rely on destructors to actually work and be useful. For example, you don't have to keep track of whether you closed your file descriptor or not, but in GCd languages you have to do that manually, sometimes even with the same reference counting, but hand-written and explicit. Reference counting is also very fast, with the exception of concurrent decades old implementations, that are irrelevant today.

I don't disagree on the benefits of RAII at all. I love it. It's a much cleaner and more general resource management idea than a tracing GC.

But incrementing/decrementing an atomic value in a tight loop apparently creates a performance problem that is severe enough for the Swift team to redesign their API. That wasn't decades ago:

"Code that handles indices has to perform atomic reference counting, which has significant overhead and can prevent the optimizer from making other improvements."

https://github.com/apple/swift-evolution/blob/master/proposa...

I wouldn't use Swift anywhere that I didn't have to until the terribly klunky and overly verbose Strings API is fixed - https://news.ycombinator.com/item?id=10519711

This is a typical Apple product to me - they obsessed over their idea of correctness and ended up with something that is difficult to use and completely alien. Meanwhile every other language offers convenience without even stopping you from doing anything else that you might need to do with Unicode...

To me, the Strings API is one of the best things about Swift. Strings are complicated and as Mike Ash says in that very article, "Swift doesn't sugar-coat it, but instead shows you the reality of what's going on. This can be difficult, but it's no more difficult than it needs to be."

Assembly is complicated too. I want it sugarcoated most of the time though. There are very few times when I need to drop down into assembly.

I don't accept assembly as a valid analogy.

I don't accept your non-acceptance of assembly as a valid analogy except I'll actually tell you the reason why - you didn't give any reasoning whatsoever.

This is a perfectly valid analogy. Visible characters in a strings are to Unicode code points as high-level functions in high-level code are to assembly commands.

Furthermore, even without using an analogy I'm quite comfortable in saying, again, that I want Strings sugarcoated because 99.9% of the time I don't give a fuck about some bullshit ivory tower corrected view of things that makes the common scenario more difficult than it needs to be.

Reply on news.ycombinator.com