Nature vs Golang: Performance Benchmarking | Hacker News Reader

Nature vs Golang: Performance Benchmarking

nature-lang.org

3 pointsweiwenhao5 comments

Impressive benchmarks. As a developer focused on high-performance C++ systems, I’m always on the hunt for languages that can match C++'s predictability without the manual overhead.

I noticed Nature's performance is quite competitive with Golang. I'm curious about the 'long-tail' stability. In my current project (a high-frequency engine built with Modern C++), I've managed to achieve a state where memory footprint actually stabilizes and shrinks—from 13.6MB down to 11MB after a week of uptime on Win10, thanks to strict RAII and zero-leak idioms.

How does Nature's runtime/GC handle memory fragmentation and predictability over extended periods (e.g., 100+ hours of uptime) compared to Go's scavenger? That's usually where the 'real' performance gap shows up in production.

Nature's runtime architecture draws heavily from Go, with its GC similarly referencing Go's allocator and collector approaches. However, the use of mark-and-sweep GC inevitably leads to memory fragmentation issues. Virtual memory usage tends to advance progressively. In contrast, the span-based memory allocator avoids significant fragmentation problems during frequent memory releases and allocations.

---

I also believe predictable memory management is crucial. An arena-based supplementary memory allocator could be the next key feature.

That’s a solid roadmap. Moving towards span-based management is progress, but the real challenge for any new language is achieving true Zero-Cost Abstractions.

In my work with Modern C++, I've come to realize that predictability isn't the result of a single feature like a scavenger or an allocator. It’s the cumulative integrity of every primitive—from a simple string to complex containers—all meticulously engineered to ensure the developer never pays a 'runtime tax' for what they don't use.

A great example of this rigor is why we still don't have Reflection in the standard: the committee refuses to compromise until a solution exists that adds zero overhead at runtime.

For Nature to truly bridge the gap, it shouldn't just aim for 'high performance,' but for that level of uncompromising zero-cost integrity. When the language's abstractions are so refined that the runtime effectively disappears, you reach a state where system behavior becomes perfectly deterministic. That is the standard C++ has set for decades.

Go's allocator draws from the Hoard work as do most modern alloc/free implementations. Similar C/C++/Rust flavor implementations do not seem to "inevitably leads to memory fragmentation issues". Perhaps this fragmentation concern is a myth carried over from earlier malloc/free or gc algorithms.

I am a core developer of the nature programming language, welcome to talk to me!

Reply on news.ycombinator.com