4 ms·
As you point out, the use of ARC is correlated with languages used in high-performance code. You think it's because ARC is a better way of managing memory, but
by t8sr 3y ago
As you point out, the use of ARC is correlated with languages used in high-performance code.
You think it's because ARC is a better way of managing memory, but that's false. Rust is not fast because it uses ARC, it uses ARC because Rust is fast. Rust is fast because it has a good ownership model for memory, because it encourages patterns that mostly get rid of the need to dynamically manage lots of heap objects. These qualities make it cache-friendly, among other things. What's left is generally small enough that even a poor GC strategy like ARC is good enough. A state-of-the-art GC wouldn't be worth the extra complexity in Rust. (And would probably conflict with other features.)
Go needs a state of the art GC, because it wants to hide "stack vs heap" from the programmer, and so it puts a lot of things on the heap. If it used ARC, it would be unusable.
To people who have worked on programming languages, saying "ARC is good, actually" is either a sign that you're about to present a very nuanced argument informed by decades of experience, or, more likely, that you have no idea what you're talking about.
If you're going to make a claim that lies this far outside the mainstream, I'd say the onus to present a good argument is on you, not me.
With age, I've found it good to moderate my fervor in proportion to how much I know about a subject. If people learn that you're someone who talks with confidence only about things you know, you'll have an easier time getting them to listen.
- kaba0 3y ago> Go needs a state of the art GC It needs, but unfortunately it doesn’t have. That category is won by Java multiple times.
- t8sr 3y agoInteresting - I would be really interested in an apples-to-apples comparison between the two of them, but such a thing must be hard to do. I'd fully expect the amount of investment in JVM to have produced a way better result, but I can't find any good articles about it.
- kaba0 3y agoNot an article, but a good “measuring stick” might be the binary trees benchmark: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... This one stresses the GC quite a bit (so it doesn’t make much sense for non-managed languages that can “cheat”), and there is only Haskell as a managed language that could get ahead of Java (but it is not really apples to oranges due to the different execution model), and in other’s case it is not even close. Go is particularly bad in this benchmark, though it sort of makes sense as it optimizes for low latency, which is fundamentally at odds with throughput.
- neonsunset 3y agoAlso the cost of write barriers. Looking at the benchmark code, it may actually benefit the languages with non-moving, simpler GC implementations because they would have cheaper write barriers or complete lack of thereof. With that said, it's a good demonstration of the quality of OpenJDK HotSpot JIT and GC. This is an area where .NET has still some ways to go - it has precise write barriers but they are not inlined so performance in scenarios bottlenecked by the cost of assigning object reference to a new heap location will vary a lot depending on WKS vs SRV GC and its configuration + exact CPU model and arch being used (more so than regular code). It does, however, use .NET 7 which is a shame.
- igouy 3y ago> managed language that could get ahead of Java Here's a different reading: https://news.ycombinator.com/item?id=29323468 https://news.ycombinator.com/item?id=29323468
- pjmlp 3y agoOn top of that, many seem to forget that Objective-C's ARC is the outcome of a project failure. Apple did not add ARC to Objective-C because it was a great design, rather they failed to add a tracing GC in Objective-C 2.0 that wouldn't crash left and right due to the underlying C semantics, thus they settled with the 2nd best option, having the compiler automate Cocoa's retain/release calls (similar to VC++ extensios to deal with COM AddRef/Release). Then sold the failure as a success, and improvement, in typical Apple's fashion. Likwise, Swift had to adopt a similar approach if it was to stay compatible with Objective-C's runtime, otherwise it would need a complicated interop layer like .NET has with COM (RCW/CCW).
- steveklabnik 3y agoDon't forget that Rust's Arc is not Swift's ARC.
- pjmlp 3y agoI know, although I am quite curious as language nerd, if the Swift ARC alongside the new Swift 6's memory ownership won't be a much productive approach than dealing with the borrow checker and manually having to type .clone() instead of lettting the compiler do it. Not that is matters much outside Apple's ecosystem, though.