Collapse OS – Why Forth?
Postedabout 2 months agoActiveabout 2 months ago
collapseos.orgTechstory
calmmixed
Debate
20/100
ForthCollapse OSProgramming Languages
Key topics
Forth
Collapse OS
Programming Languages
The article discusses why Collapse OS is built using Forth, sparking a discussion about the trade-offs of using a threaded interpreted language versus native code compilation.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
7m
Peak period
2
3-4h
Avg / period
1.3
Key moments
- 01Story posted
Nov 11, 2025 at 8:10 AM EST
about 2 months ago
Step 01 - 02First comment
Nov 11, 2025 at 8:17 AM EST
7m after posting
Step 02 - 03Peak activity
2 comments in 3-4h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 11, 2025 at 2:33 PM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45886883Type: storyLast synced: 11/20/2025, 1:30:03 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
If you use Indirect or Direct (ITC, DTC) threaded code, there's no way out: you're going to call every word. You can use Subroutine Threaded Code and inline some code (that's what I do in Dusk OS), but you still have to choose the words you're going to inline. Typically, you're going to end up with words that "calls" more than your typical C code.
And then, you might very well realize that being fast as C everywhere isn't all that important and that all the inlining you've been placing everywhere isn't worth the tradeoff, so you'll scale back on it and keep speed optimizations for bottlenecks.
So, again, yes it's possible, but the path to it is narrow. I don't know of a Forth that can say that it compiles code expressed as Forth (as in ": foo bar baz ;") that compiles native code that can compete with C, speed wise. Do you?
On some of the older platforms, certain implementations were very low level. There are Forth implementations for the 6800, 6809, 6502, 8086 (CP/M, DOS, and embedded) where all the core words are precompiled and all expansions to the library get iteratively replaced with their definitions until they’re also native code. There are probably a few for the 8080 and Z80 too.
Absolutely not everything needs to be as fast as C or hand-tuned assembly (which these days is also sometimes not as fast as C that’s been through an optimizer). The ratio of the difference between C and some other solution can have wildly different bounds, though, which is my main point.
There are a lot of languages that get acceptably close to C, but as you get into more demanding tasks that list gets shorter. Fortran, Pike, C++, Rust, OCaml, Ada, and a few others are in that list for a lot more scenarios than CPython or Ruby. Perl has a big startup time, but for long-running tasks is acceptably close on its opcode VM. Many Forths would be too, and many Lisps. Both of those languages have native compilers here and there, though, that get you even closer.
: square dup * ;
is going to generate a square word that does 2 calls, regardless of whether "dup" and "*" are native words or not.
The equivalent in C:
int square(int x) { return x*x; }
will generate code that contains no call, even if your C compiler is not a very optimized one.
With STC, it becomes possible for an elaborate Forth to inline "dup" and "*", but STC is less popular on the 8-bit architectures you mentioned because it's much less compact.
It's in that context that I mention that threaded code entails a speed tax. It's those 2 calls.
Of course, in your Forth system, you could rewrite "square" in native code to get rid of the penalty, but then it's not threaded code anymore, it's native code.
Most Forths I’ve dealt with also offer inline assembly as part of a word definition, so I suppose you could do it that way if really desired. I can see what you mean though about the penalty being completely acceptable, because it shouldn’t be super large.
But all it all, I agree that this tax is far from being a deal breaker. That's why I don't say that in my article :)