[potro]

A quote from the article:

> A distinctive feature of Zig is that it does not deal with memory allocation directly in the language. There is no malloc keyword like in C/C++. Instead, access to the heap is handled explicitly in the standard library.

I guess it is all you need to know about the article quality.

[loeg]

The point that paragraph is trying to make but articulates imperfectly is that you explicitly pass an Allocator to the stdlib routines that allocate -- rather than having them allocate on the heap implicitly.

[hawski]

Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function. You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.

[coldtea]

>Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function.

Yes, but it doesn't argue that it's not the same in C. Just that it's not the same as languages who do the memory allocation themselves.

>You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.

You could do anyting in C, even write Zig in it. And vice versa, you co do malloc in Zig. But allocators are how Zig is designed/used, whereas C opts for malloc.

[cztomsik]

You could, but it's not idiomatic in C. Zig is basically built around this.

[hawski]

Their standard libraries are built around the notion, but I would argue that putting allocation in their respective stdlibs instead of a part of the language makes it possible to be flexible if needed. There are non-trivial and semi-popular C programs that do not use the C stdlib at all.

I agree that the culture is different and that is significant, but I do not see it in the notion of the language itself (without its stdlib).

Also what is idiomatic for Zig does change as it is not a mature language. Though the allocator passing is expected to remain. Odin did an interesting thing and the allocator is put in a 'context' which is an actual part of the language.

[unwind]

It would be hard for a replacement with the purpose of modernizing a way of working to be idiomatic at the same time. It would be an explicit attempt to update what is idiomatic, and of course not be the same as what was before.

It's actually a rather interesting idea, if I had the time for a C-focused side project that sounds really fun! :)

[jenadine]

So you have coloured functions? The red that can allocate, and the blue that cannot?

[flohofwoe]

It's not quite as clear-cut, some stdlib modules take an allocator when an 'object' is created (containers mostly work like this), others on each function call that needs to allocate (but crucially, one way or another, an allocator needs to be passed in).

In any case it's not nearly as limiting as the 'red-blue' async-await color split in other languages, and I can't think of a single downside of explicitly passing allocators into stdlib modules instead of having a hidden global allocator.

The approach to always pass allocators isn't all that Zig specific either, it's also a good library design practice in pretty much all other languages which allow explicit memory management.

[loeg]

No, I wouldn't describe it like that. It's more that there isn't an ambient, implicit Allocator lying around for stdlib to use. It is explicitly provided by callers.

[throwawaymaths]

If you want to think of it that way, the stdlib `voluntarily` colors its functions by allocator. You can do whatever you want in your own functions, including always using a global allocator and never passing it anywhere.

[kps]

Well, you have expicit allocators. A popular branch of the field calls this ‘dependency injection’. It's true that the current standard library never allocates implicitly, because that would be bad on constrained projects, but there's nothing stopping you from writing code that does so, or presumably even using libc.