Re:Mitigating Memory Safety Issues in Open Source Software
by tptacek on Friday February 19, 2021 @11:31AM
(#26194816)
No, I don't see how you get there from what I said.
Re:Mitigating Memory Safety Issues in Open Source Software
by pjmlp on Friday February 19, 2021 @01:43PM
(#26196397)
> Stuff is going to get rewritten in Rust.
Yes it definitely will, but not only, specially among groups where not using a GC is more of a religious issue than an actual technical impediment.
Re:Mitigating Memory Safety Issues in Open Source Software
by tptacek on Friday February 19, 2021 @02:22PM
(#26196897)
I'm not making a value judgement. I prefer GC'd languages. I'm saying: if they're not GC'd now, when there are multiple excellent choices for managed-runtime languages, it ain't gonna be GC'd. And obviously, it's not going to be C++.
Re:Mitigating Memory Safety Issues in Open Source Software
by pjmlp on Saturday February 20, 2021 @06:38AM
(#26203422)
Ok there I agree with you, however in some domains the choice is made by who is calling the shots and not due the technical merits of some sorts.
Windows is a good example of this politics game actually.
Joe Duffy mentioned on his Rustconf keynote that even with the system running in production, the Windows team couldn't be argued against.
A system that even powered parts of Asian Bing infrastructure.
Likewise they clearly sabotaged the Longhorn efforts, to replace them with COM, and yet UWP, mostly written in C++, happens to usually run slower than traditional .NET applications on Win32, or any other compiled GC'd language on Windows for that matter.
As for the other platforms, and what Google is paying for, lets see where the bribe drives people into, after all from your point of view Google should rewrite gVisor and everything k8s as well.