Ask HN: From Unikernels and JVM to Forth: A New Paradigm for Cloud Computing?
This line of thinking brought forth an intriguing proposition: Could Forth, known for its interactive and intimate relationship with hardware, be an innovative foundation for cloud and serverless environments? Here are some focal points:
- Interactive System Access: Forth allows for direct memory inspection and modification, potentially streamlining debugging and profiling.
- Minimal Attack Surface: With its compact footprint (often <100KB), Forth’s attack surface is reduced, suggesting enhanced security.
- Parallel Execution Potential: By statically analyzing the Forth dictionary, one could assign specific words or tasks to individual CPU cores, reminiscent of the thread-per-core approach, and potentially bypass traditional thread management overheads.
Given these traits, might Forth be a suitable base for crafting highly efficient, secure, and parallelized systems for specialized cloud applications? Are there pitfalls or challenges I might be overlooking in this approach?
Mindful, this will be a new kind of Forth, one built for Big Iron servers, and where HW resource are prime real state, this could be a very interesting approach to hardness more of the potential on “bare metal”.
I’m eager to gather the community’s insights on this intriguing prospect.
2 comments
[ 5.3 ms ] story [ 23.6 ms ] threadFrom that experience, I tend to agree with your intuitions.
Now that we have 64-bit CPUs, it's tempting to revisit Forth. What might be missing is he massive collection of libraries we have in other languages.
Forth, BTW, historically, has been pushed directly to Silicon in at least two instances, the first one by Chuck Moore [1], the second one designed by Philip Koopman [2]
"forth chip" now gives pretty good google.
[1] https://news.ycombinator.com/item?id=8860786
[2] https://vfxforth.com/flag/jfar/vol6/no1/article1.pdf
Drawing from my own experiential intuition, there’s a significant cost overhead—roughly 30% on hardware (CPU and Memory)—attributable to utilizing OSs that were originally architected to facilitate human interaction and inherently embody extensive code bases. This scenario is further “complexified” when we overlay multiple OS layers (like VM’s or containers) libraries, and additional software to execute applications. Considering the financials, an average server incurs an expenditure of 15-20K, with an additional 20K annually on software to execute applications, and another 10K annually to account for footprint costs. The potential savings here are substantial—around 10K a year per server.
Scaling this to a substantial enterprise operating, for instance, 500 servers, the financial implication is pronounced. The Return on Investment (ROI) is likely even more compelling, considering the accumulated savings in various other domains, and this holds true even if the performance efficiency achieved is merely on par with current systems.