I don't know if there is any other programming environment at all where you can have a extensible programming language, editor, compiler, interpreter, debugger, libs, and interactive shell in a few KB.
uLisp [0], 2kb of RAM, and 32kb to store the interpreter in. You can write programs at the REPL, and burn them into the EEPROM.
TinyBASIC [1], since dead, is a port of the version of BASIC that used to run on the Altair 8800, which was an even more constrained system than most PETs! Altair BASIC could run on 4kb of RAM.
Python-On-A-Chip [2], is a subset of Python. At a guess, from the supported platforms, it can run on around 2kb of RAM.
iArduino [3], is a C interpreter that can run in 2kb of RAM.
MicroPython is looking to come to the ESP8266 [4], which is much, much bigger at 512kb. Which basically makes it the fattest of these, and impossible to run on something like the PET.
Bitlash is a completely new language [5], and can run on 2kb of RAM, and takes up surprisingly little storage space.
All of these languages offer at least a REPL, as well as compatibility with a wide range of libraries, and most have at least traceback and exception support.
This is not to say Forth is a bad choice! It works great in tiny memory, with better support for a full language specification than many other languages.
But not everyone wants a Forth... And there are plenty of choices out there.
[1] http://hackaday.com/2011/08/28/basic-programming-on-an-ardui...
[2] https://github.com/jsnyder/python-on-a-chip
[3] http://n.mtng.org/ele/arduino/iarduino.html
[4] https://github.com/micropython/micropython/tree/master/esp82...
Maybe one day I'll get my dream of having a forth or lisp with the type system of haskell.
> The Kitten Programming Language
> Kitten is a statically typed, stack-based functional programming language designed to be simple and fast. It is a concatenative language, combining aspects of imperative and pure functional programming. There is an introduction available and a tutorial in progress.
[0] http://evincarofautumn.blogspot.se/search/label/Concatenativ...
[1] http://www.codecommit.com/blog/cat/the-joy-of-concatenative-...
http://www.codecommit.com/blog/cat/the-joy-of-concatenative-...
http://www.codecommit.com/blog/cat/the-joy-of-concatenative-...
[2] https://en.wikipedia.org/wiki/Joy_(programming_language)
http://www.arestlessmind.org/2009/02/03/intro.html
Of course, since Forths are built around a REPL, to do type checking you need to keep the type objects around at run time, so it may not be suitable for very small systems.
For exploratory programming, dynamic type systems are nice. For building reliable long-running systems or ones where failure is extremely costly, I like static.
[1] Related: I can't actually even find the documentation on what's precisely changed between the LX6 (ESP32) and the LX106 (ESP8266), other than the basics on the datasheets - I don't know of any documentation on e.g. any different architectural details. Maybe you have to ask Espressif. Or Cadence. Anyone have any idea?
[0] https://www.espressif.com/sites/default/files/documentation/...
[1] https://leanpub.com/ESP8266_ESP32
[2] https://leanpub.com/kolban-ESP32
edit:
More information about the differences: http://www.cnx-software.com/2016/03/25/esp8266-and-esp32-dif...
As a side note, there are quite a few options to do safe micro controller system programming for those that prefer AOT compiled languages without C like unsafety.
http://www.mikroe.com/mikropascal/
I think Forth is much more suitable here. You can implement a lot of features in 512K. You can extend the code (and language!) at runtime, you can debug remotely, and do other nice things.
However the ESP8266 is built around Tensilica's Xtensa, not ARM's Cortex. There currently is no support whatsoever for Xtensa in LLVM (let alone in Rust).
Current microcontroller work is on MSP430[3] with work being planned for Amtel AVR[4] since the AVR branch was merged into LLVM in November 2016. Xtensa is quite literally nowhere[5].
[0] guaranteed to build & binaries provided but tests are not automatically run
[1] supported in the codebase but no guarantees that it even builds
[2] only Core, no standard library
[3] https://github.com/rust-embedded/rfcs/issues/20