←back to thread

Zig is hard but worth it

(ratfactor.com)
401 points signa11 | 1 comments | | HN request time: 0.207s | source
Show context
helen___keller ◴[] No.36150396[source]
My main issue with Zig is that I’m scared to invest time in writing something nontrivial to see the community/adoption flounder then regret not using Rust or C++ later

The language itself is fun. The explicit-ness of choosing how allocation is done feels novel, and comptime is a clean solution for problems that are ugly in most languages.

Aside from lack of community I’d say the biggest nuisance is error handling in nearly everything including allocations. I get that allocation can fail but the vast majority of programs I write, I just want to panic on an allocation failure (granted these aren’t production programs…)

Edit: in retrospect, allocator error handling verbosity is probably necessary due to the power the language gives you in choosing allocators. If I use the general purpose allocator then my edge case is PC out of memory; if I use a fixed buffer allocator, a failed allocation is a code bug or a common error case, so we might want to handle the failed allocation and recover

replies(5): >>36150507 #>>36150918 #>>36151708 #>>36155513 #>>36158163 #
kuroguro ◴[] No.36150507[source]
I suppose you could write a few line wrapper that panics :)

But yeah, most of the time I don't even want to think which allocator to use let alone handle it's errors.

replies(2): >>36150581 #>>36153145 #
1. chrsig ◴[] No.36153145[source]
I think for the problem space zig is trying to fit in, it's pretty essential to have custom allocator support thoroughly baked in.

It's the sort of thing that lets a data structure be used on both a gpu and cpu, allocation out of shared memory, or ensure that no dynamic allocations are happening at all.

Most programs don't have those concerns - so zig may not be the best choice for them. For the programs that do have those concerns, forethought about allocators is pretty important. Right tool for the job, and all that.