I did not find gforth or factor to be very easy to get up and running with.

If you want to learn forth concepts, you can build one yourself easily in any language (lots of examples), but Assembly or C are the most idiomatic as they allow you to get to a much lower level.

Every forth system is different, but they share a lot of design fundamentals. There are almost too many to count.

If you're okay with closed source, 8th has a very nice free version if you just want to get a hang of writing forth code in it. I usually recommend that one check out 8th as it comes with all the niceties of modern scripting languages and can cross-compile to a lot of systems, has GUI support, bluetooth, iPhone/Android, modern data structures, database support...etc.

It's also a bit confusing that most Forth systems were traditionally for embedded work. There are a few commercial offerings (SwiftForth and VxForth) for that. It used to also be extremely common to bootstrap new hardware with Forth as you got a full REPL so you could interactively interact with the hardware and test out each piece before a compiler like C could be ported to the system. I'm not sure how common that is now, but there are a lot of Forth systems that are pretty barebones compared to modern languages. You have to look around.

Probably the most straightforward thing to do is to learn and implement your own based on an early Forth like FIG Forth or Forth 83: http://www.forth.org/fig-forth/contents.html

http://forth.sourceforge.net/standard/fst83/

There are certain cosmological nuances of Forth that come through by the time you get to where you have bootstrapped IF ELSE - and while later Forths add more features(which is great for production uses) they aren't the essence of Forth, which is in the minimalism.

Factor is also so much different that it deserves another category, despite syntactic resemblance.

A few comments follow; note that I'm not unbiased :)

RetroForth is smaller and easier to build than gforth or Factor. I actively use it and seek to improve it, and I've been told the documentation is good, though I still feel I have a long way to go on that front. It's not a traditional Forth, but it works well for me. I borrow things from traditional Forth, colorForth, Factor, 8th, and other languages when I think they make sense for my needs. Releases are quarterly, with daily snapshots provided.

Gforth is big and I find it to be difficult to build from source. If you need or want a traditional/standard Forth, it's probably what I'd recommend if using one of the commercial ones isn't an option. Definitely build it from source though; the releases are infrequent and the development versions have a lot of bug fixes and improvements.

Factor is big, has lots of interesting stuff, but apart from stacks and colon decisions, really doesn't feel like Forth to me. It is under active development, but releases other than snapshots are very infrequent (last in 2018). Building from source isn't something I've done with this in years, and platform support is more limited (Linux, Windows, macOS, on x86 or x86-64). I've borrowed some ideas and terminology from Factor over the years and would consider it worth learning from.

Factor is higher level with built-in support for lambdas (called "quotations") and a garbage collector and a ready made library. If traditional Forths are like C than Factor is like C#. You'll still get many of the same concepts but without the low-level friction that'll hamper you making fun things.

I recommend studying a simple Forth implementation. rwmj wrote a tutorial/x86 implementation, now widely called Jonesforth:

Main x86 source to bootstrap minimal interpreter/compiler: https://github.com/nornagon/jonesforth/blob/master/jonesfort...

Further Forth definitions: https://github.com/nornagon/jonesforth/blob/master/jonesfort...

rwmj gave some background in comments on the HN story: https://news.ycombinator.com/item?id=10187248