[gpm]

Not really.

All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs.

There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes the low hanging fruit to improve computer reliability.

[dcsommer]

> basically fine

How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.

[gpm]

Are you counting ones that involve running malicious code in a sandbox and not just trusted code on untrusted input? Because then I'd agree, but that's a much harder and different problem.

My impression is that for the trusted code untrusted input case it hasn't been that many, but I could be wrong.

[bigyabai]

It depends, what language was the sandbox written in?

[gpm]

Sandboxes are difficult independent of language, see all the recent speculation vulnerabilities for instance. Sure, worse languages make it even harder, but I think we're straying from the original topic of "python/ruby" by considering sandboxes at all.

[zahlman]

How many ways to cause a segmentation fault in CPython, that don't start with deliberate corruption of the bytecode, are you aware of?

How is "type confusion" a security issue?