DeVault: Announcing the Hare programming language [LWN.net]

DeVault: Announcing the Hare programming language

Posted May 2, 2022 10:17 UTC (Mon) by atnot (guest, #124910)
In reply to: DeVault: Announcing the Hare programming language by roc
Parent article: DeVault: Announcing the Hare programming language

> Out of 58 zero-days, only 17 were use-after-free, i.e. about 30%

I was looking at the percentage of memory corruption vulnerabilities, which is 54%. But both are very big numbers.

> Of course, I agree with you that encouraging people to write systems software in a language that doesn't prevent UaF --- when Rust is an option --- is a mistake.

I don't think Rust's answer has to be the only option here. There's a lot of options, between Rust's lifetimes, go style escape analysis, zig's allocator shenanigans, Google's MiraclePtr, etc. What I think is unfortunate however is saying "it's hard so we shouldn't try" and releasing a language in 2022 where UAF, the #1 memory corruption issue in modern systems, is not even a consideration. That's just very disappointing.

to post comments

DeVault: Announcing the Hare programming language

Posted May 2, 2022 10:27 UTC (Mon) by roc (subscriber, #30627) [Link] (1 responses)

I agree.

I'm not saying Rust is the only answer to UaF. E.g. Go or Java GC is another fine answer for many applications. I mention Rust only because it is the most likely to be compatible whatever scenarios people dream up.

(And FWIW I don't think Zig's allocator shenanigans are a realistic answer to preventing UaF in production.)

DeVault: Announcing the Hare programming language

Posted May 2, 2022 11:41 UTC (Mon) by khim (subscriber, #9252) [Link]

> (And FWIW I don't think Zig's allocator shenanigans are a realistic answer to preventing UaF in production.)

I also don't think so. But at least they have honestly tried to do something (even if that something is not very good).

To say that we haven't even tried? In 2022? Gosh.