Nature vs Golang: Performance Benchmarking(nature-lang.org)
nature-lang.org
Nature vs Golang: Performance Benchmarking
https://nature-lang.org/news/20260115
5 comments
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.
---
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.
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!
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.