[astrobe_]

Half correct. It's true that you can improve the safety that way, but what proponents of memory safety consider a no-go is pointer arithmetic and crafting - basically not what C allows.

You can forbid yourself to do these things and implement a "safety layer" for string handling, array handling with bound checking etc. but at the end of the day, it's more a a cultural thing than a technical thing. IMO this era wants to build reliability from lots of unreliable parts, and that include developers; cowboy programmers who could make reliable things by themselves have been retired.

Well, you see the result: smartphones that can't make emergency calls when you need it etc. But hey, it's written in a memory safe language and our bus factor is 0.00004 !

[tluyben2]

You can do fake pointer arithmetic which won't hurt this use case (server-side web framework); if you implement Gforth as an interpreter on the JVM/CLR or running it with Emscripten, there is no issue for server-side web frameworks like this while being safe.

That's been done for C a few times (this [0] and there are a few others); if you don't depend on the actual physical memory addresses you are using (which, in embedded, you often are counting on, but not in a server-side framework).

> it's more a a cultural thing than a technical thing.

I agree with that

> IMO this era wants to build reliability from lots of unreliable parts, and that include developers; cowboy programmers who could make reliable things by themselves have been retired.

Not sure what this means?

[0] https://chrisseaton.com/plas15/safec.pdf