Memory safety issues are not always an issue. What I mean is that having memory safety is not everything, since a system that is memory safe can still contain bugs, and vice versa a system with memory related issue can function perfectly for years, because they are corner cases that are difficult to get into.

Of course there are cases where memory safety issue cause security problems, but not in all cases. If for example by a very uncommon sequence of keypress on my washing machine I cause a buffer overflow, worse case scenario the microcontroller hangs and I have to unplug it and plug it back in again (but hopefully there is a watchdog that resets the processor automatically). A lot of C programs don't even have an user interface, because for example are embedded in device that has no external input (for example a microcontroller that manages the operation of a power supply).

Even ignoring memory safety, C allows a lot of footgunning. I've found another source of grief to be weak typing and operators priority. I was very surprised to find bugs in the Linux kernel examples.

> My take is that there are two types of programmers: those who admit they can't avoid making memory safety mistakes, and real programmers, who don't make such mistakes, and happily keep programming in C/++.

I absolutely agree. There's a class of programmers that would rarely if ever make such mistakes (e.g., Torvalds), and to them, C is freeing.

For the rest of us lesser programmers, the handrails of a borrow checker are necessary.

He was referencing https://www.cs.utah.edu/~elb/folklore/mel.html

I'm pretty sure that was sarcasm.

Mind sharing what is the project that you picked?