On Sun, Feb 6, 2022 at 7:17 AM Larry McVoy <lm@mcvoy.com> wrote:

While I _can_ do all the malloc/free stuff myself (and have decades of
working code to prove it), it's become harder and harder to find other
people who can.

While it's not too bad to do malloc/free in userspace in single threaded

programs, it gets harder for multi-threaded where you have multiple objects

holding references to an object you might want to free. And to get things

to run fast, you have to use increasingly sophisticated "locking" primitives

to get performance: RCU, lifetime flexibility, etc. Those methods are

hard to get right, which is why most of them include extensive run-time

proofing / asserts to try to catch leaks and other problems.

For kernel work, that adds a whole other level of complexity as well.

I'd love to have all this stuff automatically optimized and correct.

However, the state of the art for alternatives to C aren't there today

for the kernel context. While rust in Linux is a thing, it's not in the

fast path yet. Time will tell if it can grow up to do that or not, and

I'll stop there since it's a rapidly developing area and I'm sure

anything I say about the state of the art when I last looked will

be wrong in some way.

Warner