I agree with the sentiment, but does Swift actually see any usage outside of Apple’s own hardware? I think Swift’s reliance on such an optimization is justified since the hardware this optimization is applied to is the main target.
While Swift’s approach may be slower in theory, is it actually slower in practice? Just a thought.
Hardly, but having to design hardware to fix ARC performance, proves the point how much "better" it is.
Depends how much one cares about performance beyond iOS GUI apps, specially when Swift's original goal was to become the main language across the whole Apple stack.
Swift has been used to write parts of MacOS that are used on Intel today.
The good faith efforts to write parts of a consumer OS in a garbage collected language that I can remember are Microsoft's effort to write Longhorn in C# and Google's effort to write part of Fuchsia in Go.
Likewise, Midori was powering Asian Bing cluster for a while, and even that wasn't good enough for WinDev.
And in Fuchsia, same thing happened, the parts in Go were only taken away when the Go advocates that driven those modules were no longer around to argue for their implementations.
Politics are more relevant than technical limitations.
Finally, Azure Cloud OS and Windows together have surely more lines of C# powering them than Apple has been doing with Swift.
Naturally you would answer that, from an OS that never had a certified GA build, great proof indeed.
Yet the same group that sabotaged Longhorn, was quite keen in doing exactly the same stuff using a mix of .NET Native and C++/CX, which only failed due to the lack of migration path from Win32, and not much love for the sandboxing.
It's one of the internal emails made public as part of the Microsoft antitrust trial.
>LH is a pig and I don’t see any solution to this problem. If we are to rise to the challenge of Linux and Apple, we need to start taking the lessons of “scenario, simple, fast” to heart.
Sorry, but the person who was in charge of Windows development at the time did not agree with you. Longhorn failed due to performance issues that Jim Allchin believed were unsolvable.
Go has a bad GC. Go relies on the compiler to do escape analysis and allocate on the stack. Once you actually start heap allocating you hit massive pauses. It’s why Go does so bad on the binary tree benchmark.
> Once you actually start heap allocating you hit massive pauses.
citation needed. go afaik has millisecond pauses at most. maybe you're thinking of throughput losses due to forcing more CPU to be spent on collecting?
