1 77918b00 2024-03-07 o From: Oliver Lowe <otl@apubtest2.srcbeat.com>
 2 77918b00 2024-03-07 o Date: Wed, 6 Mar 2024 14:03:33 +1100
 3 77918b00 2024-03-07 o To:  <henfredemars@infosec.pub>
 4 eec64935 2024-03-16 o CC: "Programming" <programming@programming.dev>, <starman@programming.dev>, <otl+followers@hachyderm.io>
 5 77918b00 2024-03-07 o In-Reply-To: <https://infosec.pub/comment/7135766>
 6 77918b00 2024-03-07 o Subject:
 7 77918b00 2024-03-07 o 
 8 77918b00 2024-03-07 o > It's a nice thought, but the White House encouraging
 9 77918b00 2024-03-07 o > memory safety seems like a relatively insignificant push. It's the
10 77918b00 2024-03-07 o > weight of legacy code and established solutions that will hold us back
11 77918b00 2024-03-07 o > for a long time.
12 77918b00 2024-03-07 o 
13 a00f14b4 2024-03-18 o Absolutely. Memory-safe languages have been around for decades. The
14 a00f14b4 2024-03-18 o reason there is so much poor code - including ones with manual memory
15 77918b00 2024-03-07 o management bugs - out there is not a technical problem. There are
16 77918b00 2024-03-07 o hordes and hordes of programmers, managers, companies etc. who would
17 77918b00 2024-03-07 o love to get paid to port this stuff. They'll do it for 10% of the
18 77918b00 2024-03-07 o price those stupid lumbering tech consultancies do it for.
19 77918b00 2024-03-07 o 
20 77918b00 2024-03-07 o But who gets the contracts in the end?
21 77918b00 2024-03-07 o Give me a f'ing break!