weiwenhao

I'm currently using Nature to replace Tauri for developing desktop applications, which will allow me to conduct more thorough testing later. Since the linker succeeded in linking, it indicates that all symbols were successfully located. Both libruntime and libuv are highly complex code systems. The fact that the scheduler and coroutine system are already running successfully confirms that all core functions are functioning properly.

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 am a core developer of the nature programming language, welcome to talk to me!

For package management software that is rarely used, free is the biggest motivation.

Very nice, my nature-lang references the old ruby design, now maybe I can reference the new one.

So far it does, just inspired by golang, which doesn't support FFI and calling golang related code is not an easy task.

But the situation will improve soon, in order to make nature more useful, I've decided to translate nature into readable golang code and parse the golang code to utilize the golang code.

Your write-up is so detailed that I even feel like I could implement a complete golang scheduler myself