[burakemir]

This is a false dichotomy. Language design choices are the causes of security and software vulnerabilites. It is possible to recognize the value of GC languages and have precise technical terminology at the same time. We can invent new words.

I believe everyone who cares about memory safety appreciates that certain bugs cannot occur in Java and go, and if the world calls that memory safe, that is ok.

There are hard, well-defined guarantees that a language and implementation must make, and a space of trade-offs. We need language and recognition for the ability to push the boundary of hard, well-defined guarantees further. That, too, is memory safety and it will be crucial for moving the needle beyond what can be achieved with C and C++.

No one has a problem with applications being ported from low-level to GC-ed languages, the challenge is the ones where this is not possible. We need to talk about memory safety in this specific context, and mitigations and hardening will not solve the entire problem, only pieces of it.

[tptacek]

You can invent whatever word you want, but "memory safety" is a term of art that very definitely includes GC'd languages.

[burakemir]

Did you read what I wrote up there?

There is art and there is science. What both have in common is that their protagonists do not intend to become obstacles of progress.

I'm afraid GC'd languages have been around for a very long time and yet we continue to talk about memory safety as an urgent problem. Now what?

How does pretending that low-level memory safety is not its own complex domain deserving of its own technical definitions help with anything?

[tptacek]

The urgent problem is the problem settings where GC'd languages are not a good fit, including kernels and userland-kernels (AKA browsers). The problem is not that GC'd languages are insufficiently memory-safe.