Now try Swift outside that hardware stack.
While Swift’s approach may be slower in theory, is it actually slower in practice? Just a thought.
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.
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.
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?
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.
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.
Performance problems get sorted out when people actually care to solve them instead of driving their own agenda.
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.
Performance problems get sorted out, instead we got management chaos,
https://hackernoon.com/what-really-happened-with-vista-4ca7f...
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.
In any case, the top level manager for Windows development asserts his failure to make the team make it happen, looks like management issues to me.
The coach failed the team.
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.
https://web.archive.org/web/20210427171552/http://blog.seatt...
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.
The team's failure has a direct relation with the management failing to act upon the issues until it was too late to actually try to sort them out.
So yeah, management failure in all its glory.
The anti-trust trial was decided in 2001, Longhorn was developed from middle 2001 up to 2006, nice try.
I'm not sure how you can spin your way around that and be taken seriously.