Ask HN: From Unikernels and JVM to Forth: A New Paradigm for Cloud Computing?

3 points by spaintech ↗ HN
I’ve recently been in a deep discussion exploring various computational models for efficient cloud computing. We began by introspecting Unikernels, which offer single-purpose OS instances tailored for specific applications, resulting in rapid boot times and minimal resource consumption. The discussion moved to considering a hypothetical “bare metal” JVM or BEAM Machine that provides an OS-like abstraction layer for applications. The idea was to have an environment where developers can focus on application logic, while the underlying system efficiently manages hardware resources.

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 ] thread
Back in the days of 8080 CPUs, I built a number of projects in Forth,including a "discovery system" which adapted patterns from the late Douglas Lenat's Eurisko project, as well as a trading system which, on paper, could have been successful.

From 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

Thank you, yes I’m am aware of the HW CPU forth.

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.