Why Zig when there is already C++, D, and Rust?

Re:Why Zig when there is already C++, D, and Rust? by potatochup on Friday January 15, 2021 @06:21PM (#25797965)

I was interested by this statement made in the article: "The entire concept of the heap is strictly in userspace"

Is that just an analogy between Kernel and userspace from operating systems? Or is it an actual term used for programming languages, when abstract from an operating system?

If I was running zig on a bare-metal embedded device, and wrote my own heap allocator, is it appropriate to call that a "userspace" heap allocator?

[ Parent | on HN ]

Re:Why Zig when there is already C++, D, and Rust? by sobeston on Friday January 15, 2021 @06:46PM (#25798208)

The concept of the heap is in the userspace of the language. This terminology is confusing to someone thinking of usermode/kernelmode - this is instead talking of userspace versus language-space. As in, users implement code to reason about heap memory; the language does not know or care what heap is.

At a language level, zig does not have a "new" or a "malloc" or anything of the sort.

[ Parent | on HN ]

Re:Why Zig when there is already C++, D, and Rust? by kristoff_it on Friday January 15, 2021 @07:14PM (#25798450)

It means that it's a feature that can be implemented without special language-level support. As an example, Go 1 has maps and slices which are "magic" generic types that a 3rd party library author would not be able to recreate.

[ Parent | on HN ]