45 ms·
Zig has a pretty great type system, and sometimes languages like Rust and C++ are not great with preventing accidental heap allocations. Zig and C make this ver
by winrid 1y ago
Zig has a pretty great type system, and sometimes languages like Rust and C++ are not great with preventing accidental heap allocations. Zig and C make this very explicit, and it's great to be able to handle allocation failures in robust software.
- pjmlp 1y agoThat is the usual fallacy, because it assumes everyone has full access to whole source code and is tracking down all the places where heap is being used. It also assumes that the OS doesn't lie to the application when allocations fail.
- simjnd 1y agoZig make allocations extremely explicit (even more than C) by having you pass around the allocator to every function that allocates to the heap. Even third-party libraries will only use the allocator you provide them. It's not a fallacy, you're in total control.
- pjmlp 1y agoWhy, are you going to abort if too many calls to the allocator take place?
- simjnd 1y agoYou can if you want. You can write your own allocator that never actually touches the heap and just distributes memory from a big chunk on the stack if you want to. The point is you have fine grained (per function) control over the allocation strategy not only in your codebase but also your dependencies.
- pjmlp 1y agoAllocation strategy isn't the same as knowing exactly exactly when allocations take place. You missed the point that libraries can have their own allocators and don't expose customisation points.
- ulbu 1y agosure they can. but why would they choose to?
- pjmlp 1y agoBecause the language doesn't prevent them, and they own their library.
- ulbu 1y agothe question remains – why would they choose to?
- pjmlp 1y agoBecause they decided to do so, regardless of people like yourself thinking they are wrong.
- ulbu 1y agoand so why should he be forced to not do so? he can cook his own thing outside of what most people using this language will do, and they will just not use it, and nothing's wrong with that.
- simjnd 1y agoThey can, and they wouldn't be necessarily be wrong. However if the library is trying to be as idiomatic / general purpose / good citizen as possible, then they should strongly consider not doing that and only use the user provided allocator (unless there is a clear and documented reason why that is not the case). I don't think it would make sense to restrict this at the language level. As a developer it's up to you to exercise your judgement when you examine what libraries you choose to depend on. I appreciate the fact it's a common design pattern in Zig libraries and I also appreciate the fact I'm not forced to do it if I don't want to. If it matters to me then I'll consider libraries that are designed that way, if it does not matter to me then I can consider libraries that do not support this.
- dmytrish 1y ago> pass around the allocator to every function that allocates to the heap. what prevents a library from taking an allocator, saving it hidden somewhere and using it silently?
- renehsz 1y ago> It also assumes that the OS doesn't lie to the application when allocations fail. Gotta do the good ol' echo 2 >/proc/sys/vm/overcommit_memory and maybe adjust overcommit_ratio as well to make sure the memory you allocated is actually available.
- pjmlp 1y agoOS specific hack and unrelated to C.
- tredre3 1y agoYour comment was also OS-specific because Windows doesn't lie to applications about failed allocations.
- pjmlp 1y agoNot at all, rather there is no guarantee that the C abstract machine described on ISO C, actually returns NULL on memory allocation failures as some C advocates without ISO C legalese expertise seem to advocate.
- dmytrish 1y agoWhat's great about its type system? I find it severely limited and not actually useful for conveying and checking invariants.