Hacker News Reader

Comment by the_duke | Hacker News Reader

Swift is a really cool language. Quite similar to Rust, but easier to use. ( GC, no borrow checker, no multi-threading safeguards, ...)

I just wish cross platform support was a real priority. The Ubuntu packages are all there is, and much of the ecosystem is centered around (Mac/i)OS.

View on HN

I don't really see how "quite similar to Rust" and "GC, no borrow checker, no multi-threading safeguards" can both be true at the same time.

They're both highly influenced by ML family of languages.

They both have similar goals as far as mitigating certain classes of runtime errors through static checks. Both have nice type systems, and features like explicit mutability and nullability.

Like you say the approach is pretty different: when it comes to the tradeoff between safety/performance and developer ergonomics Rust leans toward the former where Swift leans toward the latter.

It's quite similar to Rust... if Rust literally used Arc<Mutex<T>> everywhere. And Arc<Mutex<T>> everywhere might actually have lower throughput than tracing GC! (Though it's arguably preferable for low-latency code, so it might make some sense for the typical use cases of ObjC and Swift.)

That's not entirely true, it would be similar to `Arc<T>` everywhere, because the Swift compiler and the language are by default not concurrency safe (there're runtime features to detect issues here, similar to RefCell though). This means that Rust has to use `Arc<Mutex<T>>` in order to satisfy the compiler, Swift gets away with `Arc<T>` (and I'm currently not sure, but it might even be only `Rc<T>`) because the compiler doesn't prevent it.

The advantage of ARC is that the cost of deallocating is very constant and always happens at the same moment. This helps enormously when you are doing performance sensitive stuff like scrolling over a list of complex cells.

With the Java style of GC the minimum and maximum cost and timing of GC are just not so predictable so in real-world scenarios ARC based apps feel more fluent.

It's like playing games. You'll notice the 10FPS dips more than the difference between 50FPS or 60FPS on average.

Not really.

Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs.

If the way destruction is triggered does not take this into account, stack overflows are bound to happen.

Finally it introduces slowdowns in shared data structures used across threads.

Herb Sutter has a very good CppCon talk about these issues.

EDIT: Forgot to mention that Swift was the loosing language at CCC talk about implementing device drivers in memory safe languages. All the ones with tracing GC had a better outcome.

I think nothing of what you just wrote undermines what I just said.

> Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs.

Which is simply difficult for every language. But even then still more predictable than Java "we'll do it when we feel ready for it" approach.

Yet all the languages with a tracing GC wipe the floor of Swift's reference counting implementation.

"35C3 - Safe and Secure Drivers in High-Level Languages"

https://www.youtube.com/watch?v=aSuRyLBrXgI

https://github.com/ixy-languages/ixy-languages

The subject of Herb's talk was actually going through all the reference counting problems to introduce in the end a lightweight implementation of deferred pointers, which isn't nothing more than basic tracing GC.

https://www.youtube.com/watch?v=JfmTagWcqoE

Well if you think a driver is somewhat similar to a front-end implementation to begin with then it's OK. If "wiping the floor" means what I see on a day by day basis comparing JVM based UI's versus the same thing built in Swift you're probably talking about something different to begin with.

I'm talking about predictable performance and guaranteed minimum performance. I don't think you're speaking about the same thing.

The video seems to be interesting anyway, so thanks for that.

Actually it is, that network packet is not going to wait.

"Wiping the floor" means getting last place against all tracing GC languages used to research the mentioned paper.

Yes, many JVM based UIs do suck, mostly because the authors didn't bother to learn how to use Swing properly by reading books like Filthy Rich Clients.

The thing with Swift UIs, is that they are actually C and C++ UIs, given that those are the languages used to implement Core Graphics, Core Animation and Metal. Additionally Cocoa is still mostly Objective-C, with performance critical sections making use of NSAutoreleasePool like in the old good NeXTSTEP days.

Coming back to Java, factory automation and high integrity systems are perfectly fine with it.

https://www.aicas.com/cms/

https://www.ptc.com/en/products/developer-tools/perc

Well try to use C++ without the C part, see how that goes. C is a part of Objective-C and you can write Swift code that will compile byte for byte into code as performant as C. It's ugly, it's unsafe but it's part of the language and if you need it it's there.

You sound like those people that complain that Objective-C is so slow compared to C because NSArray is much slower than it's C counterpart. Objective-C is always exactly as fast as C since you can always write C in Objective-C.

And if all Java based UI's suck despite the fact that it's the most popular programming language and despite the fact that it powers the most popular operating system you might start suspecting there's something wrong with it, but nope, you've read a paper and saw a video. About a kernel driver. OK.

The funny part is that the languages with tracing GC that wipe Swift's memory management on the paper aren't even Java, rather OCaml, Go and C#.

Your focus on Java, without spending one second reading the paper benchmarks, from a well respected researcher in the CCC community, just demonstrates a typical defensive reaction among reference counting proponents.

Using C++ without the C part is the whole point of modern C++ and the Core Guidelines. In fact there are several benchmarks where the C++ version gets better optimized.

As for Android, it isn't Java as we know it, and any travel through /r/androiddev will teach Google might have tons of PhDs, but they certainly don't work on Android, given how a lot of things are implemented.

I'm kind of baffled you never got back to the first statement I made. It's like you got totally lost in your mission to prove that Swift sucks. I never claimed magic performance in Swift, I said ARC might be slower but it's a lot more predictable with a better minimum performance.

The only thing I see is "here's a ton of text and video to slough through made by people smarter than me", nothing concrete that undermines my original statement in any way.

And yes C++ cannot exist without C as it is an extension to C. You can write pure C in a C++ file and it will still work. You can write pure C in an Objective-C file and it will still work. You can write some ugly bastard syntax version of C in Swift and it will still work.

I'm very much willing to accept Swift's performance for a device driver (possibly the first device driver ever written in Swift) is worse than in many other languages if you stick to the safe bits of Swift. It just doesn't have much to do with what I wrote.

Kotlin/Native might turn out to be that, but it depends pretty much where JetBrains is willing to take it.

In any case, as rule of thumb, systems languages that come with an OS/platform usually win in the long run.

If GC means garbage collection here, Swift definitely doesn't have that.

Sure it does, reference counting is a GC implementation algorithm from CS point of view.

The Garbage Collection Handbook, chapter 5.

http://gchandbook.org/

Just one key CS reference for compiler writers among a few others.

When people say GC in computer science, they don’t typically mean reference counting. Reference counting is an automatic memory management scheme along side GC, not inside it. One way to think of it is that if it lacks a separate GC phase and can’t deal with cycles, it isn’t GC.

Nah, that is mixing GC with tracing GC, because it is too much to type/say an additional word.

Lay people also use wrong terms when talking about other scientific fields, that doesn't make them right by quantity of use.

I don’t think McCarthy had reference counting in mind when he coined the word garbage collection. I think it’s more likely that people say garbage collection when they actually mean the more general term of automatic memory management. No one would ever mistake arena based memory management as a form of garbage collection, for example, even though it is obviously a form of automatic memory management.

By that measure C++ and Rust are a GCd languages because they have smart pointers.

Yes and no. "No GC" means "no mandatory GC when data isn't shared between threads".

No because in Rust and C++ using smart pointers is an explicit choice that is applied manually when required and is present both in the type signature everywhere a reference counted type is used, and in the construction of values.

In Swift the reference counting is a implementation detail of automatic and transparent memory management. (that you only really have to care about when you have cycles)

That's why Swift definitely counts as a GC language for me.

Sure, if you put things behind a Arc<T> or shared_ptr you use reference counting in C++ and Rust, but it is not an inherent feature of the language.

ARC only applies to reference types. The programmer has acess to value types, and manual memory management if they want it.

In Rust, using smart pointers is not much of an "explicit choice" - it's simply the idiomatic thing to do when something might be kept around by more than one parent object.

Rc<T> basically means that there are multiple sources of control over T's lifetime, but these are all within a single thread; and Arc<T> signals that the control might extend to multiple threads. It's not "mere implementation" that we're dealing with here; it's the very semantics of the code as it relates to Rust's expanded take on the well-known RAII pattern.

Swift simply lacks an equivalent to either the Rc<> specifier or e.g. Rust's Box<>, which expresses the semantics of an object which is heap-allocated and accessed via an indirection, and verifiably has at all times a unique "owner" controlling its lifetime (as per usual RAII).

You can argue it’s an explicit choice because you can often choose to structure your code in a way that doesn’t require Rc. Of course, it exists because sometimes, you do have to or want to, but those cases are pretty rare in my experience.

This is why I say memory management isn't "either GC'ed or manual", because it's a continuum between "fully manual" (runtime hands you a slab of bytes, you do the rest) and "fully automatic" (you never worry about anything, not even cycles in the values, and it all "just works"). Between those two extremes there's a lot of gradation, not to mention the fact that all schemes can generally be mixed within a single program, language/runtime permitting.

Thus, arguing whether some particular middle point is or isn't "garbage collection" isn't anywhere near as useful as people seem to suppose, especially if it's being argued in a context where "GC is morally bad in all forms" or something like that. It's all a bunch of tradeoffs and there is no single perfect answer to all problems.

Note that even most "manually allocated" languages don't actually fall into my manual extreme; generally something more granular and automatic than that is offered. However, while nothing except arguably raw assembler defaults to that "fully manual" allocation, it's a useful last-ditch option in a lot of places, often wrapped up with just a touch more automation into something called "arena allocation", where you don't care about where the arena lives in RAM per se and it integrates with the rest of your allocator otherwise, but is just a big slab of bytes otherwise. Even in the GC'd languages I've seen "just give me a big slab of bytes and go away" used, even if it has no formal support.

Personally, I'd consider "reference counting" as a "garbage collection" scheme if the references are counted automatically, and as manual memory management if you're in a context where you have to manage them manually, but YMMV. I break it down that way mostly because in the automatic case, you get the general advantages of automation, in that it's largely correct but often somewhat slower (because it can't elide anything), and managing them manually permits more sophisticated schemes but also is massively error prone (to the point I wouldn't use it for anything anymore; the benefits are available from other techniques and the costs are insanely high). So personally I'd go with smart pointers being an embedded method of garbage collection in a language/runtime that generally is written for manual memory management. It doesn't make the outer language a GC'ed language, nor is it some sort of betrayal of the manual memory management ethos or whatever. Real programs in C++/Rust at scale will tend to use lots of memory management techniques, many of them with high degrees of automation, but the language and runtime themselves are generally manually-managed. It doesn't matter how many smart pointers your program uses, arena allocation is always an option for your next bit of code.

> in the automatic case ... it's largely correct but often somewhat slower (because it can't elide anything)

Not entirely true; in the case of ARC in Swift/ObjC a lot of effort was put in to optimizing retains and releases wherever possible. The de facto standard platform for ObjC (Apple's) had a strong set of conventions around memory management already. They were formalized in such a way that some of the defensiveness required in manual retain/release could actually be proved unnecessary in ARC code. (A few semantic changes were made to ObjC as well to support ARC.) Not in all cases, of course, but also not in none.

I guess that effort is still not good enough.

"35C3 - Safe and Secure Drivers in High-Level Languages"

https://www.youtube.com/watch?v=aSuRyLBrXgI

https://github.com/ixy-languages/ixy-languages

Interesting, thanks! Added to my to-read list.

>, reference counting is a GC implementation algorithm from CS point of view. The Garbage Collection Handbook, chapter 5.

Yes, that GC book always gets cited to educate everyone on terminology but it never resolves or finalizes how "garbage collection" is actually discussed in regular conversations. I made previous comments on why citing that book just adds to the confusion of how people typically communicated that rc != gc before that GC book was published.

https://news.ycombinator.com/item?id=11764887

https://news.ycombinator.com/item?id=7866732

There are plenty of CS papers referring to reference counting as a GC implementation algorithm since Lisp exists.

Swift doesn't actually use garbage collection, it uses a variant of Objective-C's Automatic Reference Counting (ARC) which was introduced a few years prior to Swift.

If we’re being pedantic, Automatic Reference Counting is a form of garbage collection.

Reply on news.ycombinator.com