Nature vs Golang: Performance Benchmarking

Nature vs Golang: Performance Benchmarking(nature-lang.org)

3 points by weiwenhao 169 days ago | 5 comments

AlanLan 169 days ago |

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.

weiwenhao 169 days ago | |

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.

AlanLan 168 days ago | | |

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.

_rlh 166 days ago |

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.

weiwenhao 169 days ago |

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