Very fast (faster than naive assembler) but not at all high-level; having to look after the stack is a bit of a pain. Writing your own FORTH is fun - it doesn't need to be in assembler - I once wrote a FORTH-like scripting language in C++.

> Very fast (faster than naive assembler)

Every Forth that uses conventional threaded-code interpretation pays a considerable performance penalty, execution times are likely to be very roughly quadruple the equivalent assembly. [0]

Forth's runtime performance can be competitive with C if 'proper' compilation is performed, though. [1]

[0] https://benhoyt.com/writings/count-words/

[1] (.fth file with their results in comments) http://www.mpeforth.com/arena/benchmrk.fth

but it's also very extendable. It's ability to slap on new control structures and DSL's is on par with Lisp. I'd say it's very low level and much higher level than the most languages simultaneously.

> Very fast (faster than naive assembler)

Depends on how naive the assembler programmer is, and, I would think rarely, if ever, on modern hardware because the many subroutine calls kill branch prediction benefits. Also, on lots of old 8-bit hardware, defaulting to 16-bit integers will kill performance relative to native assembly in cases where 8-bit integers suffice.

(Of course, you can fairly easily replace hot loops by assembly or (more difficult) change the forth compiler to compile parts to native code, fuse words, etc)