All I’ve seen is there is literally no programmer smart and careful enough to never create a use after free or out of bounds read in a sufficiently complex codebase.

The state of computer security has moved on from the old model of just patching bugs when you find them. To now where we need to systematically prevent them from happening to begin with.

▲

allknowingfrog 2 hours ago | parent | next [-]

Have you heard of TigerBeetle? Being smart enough doesn't seem to be the primary factor. It's about having a strategy and the discipline to follow it. No type system will ever free you from the burden of doing the actual engineering.

	▲	woodruffw 29 minutes ago \| parent \| next [-]
		I find TigerBeetle very impressive. One of the impressive (and correct) decisions it made was to use an allocate-up-front pattern, which makes certain classes of temporal memory corruption harder to write. At the same time, TigerBeetle can do this because it’s solving a specific shape of problem that’s amenable to that allocation strategy. Binding a third-party runtime written in C++ (TMU, this is what Bun is) is a pretty differently shaped problem that doesn’t easily admit that style. In other words, discipline isn’t always enough (although you do certainly need it). Sometimes the shape of the problem makes environmental constraints (like the kind Rust offers) important.
	▲	throwwwll 2 hours ago \| parent \| prev [-]
		[dead]

▲

pseudony 2 hours ago | parent | prev [-]

- types rarely catch the interesting errors

- any GC'ed language can manage memory for you if you want

- My first rust project (a gui app in GTK) managed to segfault just fine in spite of Rust (no unsafe blocks on my part, not deliberately trying to break anything).

- I think the state of computer security has moved on still, we now rely on LLMs armed with various tools to pick apart and try to break our code AND to generate our code -- it is not at all obvious to me that banging your head against the borrow checker is a worthwhile tradeoff in this new world.