News for hackers. Stuff that matters.
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.

Re:Mitigating Memory Safety Issues in Open Source Software by tptacek on Sunday February 21, 2021 @12:21AM (#26211034)
Somehow I think ISRG is not going to try to secure funding to rewrite core Windows components.