4 ms·
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 languag
by GeekyBear 5y ago
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.
Both efforts failed for performance reasons.
- vips7L 5y agoGo 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.
- jatone 5y ago> 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?
- pjmlp 5y agoWrong, Longhorn failed because WinDev sabotaged the project. https://news.ycombinator.com/item?id=30486727 https://news.ycombinator.com/item?id=30486727 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. And then there is Android.
- GeekyBear 5y agoThe leaked builds of Longhorn took forever just to boot on the hardware of the era. That's a performance issue. However, the internal politics of Microsoft certainly didn't help either. The stated reasons for removing the Go portions of Fuchsia and rewriting them in another language were also firmly based in performance.
- pjmlp 5y agoOf course debug builds aren't the prime example of performance, that is to be expected. Performance problems get sorted out when people actually care to solve them instead of driving their own agenda.
- GeekyBear 5y agoSorry, but debug builds weren't the only builds that leaked. The performance was just never there.
- pjmlp 5y agoNaturally 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.
- GeekyBear 5y agoMicrosoft handed out builds at PDC. It's difficult to take claims that it didn't have massive performance issues seriously.
- pjmlp 5y agoNo one is claiming that performance problems did not exist on an alpha version of Longhorn. Performance problems get sorted out, instead we got management chaos, https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a https://hackernoon.com/what-really-happened-with-vista-4ca7f...
- GeekyBear 5y agoJim Allchin, who ran Windows development at the time, didn't send an email to Gates and Ballmer warning about management issues. He told them that Longhorn was a pig and he didn't see any solution to that issue. Just before the code base was abandoned.