Most (naive) VMs are defined as Forth-like stack machines as it's hard to reckon ways to map high-level instructions to load/store register semantics, but much

Most (naive) VMs are defined as Forth-like stack machines as it's hard to reckon ways to map high-level instructions to load/store register semantics, but much easier to think in terms of stack push/pop. In that sense, Forth lives everywhere, it's just not formally acknowledged as such because it's a compilation target, so you only see it when you go debug the VM in terms of its instruction set. A way to think about Forth is not as a solution, but a strategy: build the smallest abstraction that works, then build a second abstraction that refines things slightly closer to the domain problem, but explicitly compiles to the semantics of the previous one. If you do this several times you can get a very powerful environment quickly. But it takes time to reinvent the world from scratch, and shipping a project still usually leads to taking on dependencies. "Pure" Forth is just a matter of applying the approach directly to the hardware, resulting in a barebones, loose-cannon system that is clearly very powerful, but too dangerous to use out of the box. Traditional compiler technology, in contrast, exchanges a big set of dependencies(a compiler, a build system, a module system, etc.) for a predefined semantics, type system, error checking, etc. These things are really useful for applications, but such languages can never be quite as direct since they are general-purpose. The Forth approach is still useful always.