> memory unsafe language
That's the implementation thing, not the language. You can implement an ANSI Forth standard like GForth in a memory safe way without a lot of issues. Even the memory allocation words[0] are easily implemented in a garbage collected language. Of course that makes it useless for embedded purposes which is where Forth usually works well, but that's not an issue as you are not doing that here.
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 !
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?
I am reminded about a quote attributed to Keith Martin (mathematician): "Theory is important, at least in theory"