Hacker News new | past | comments | ask | show | jobs | submit login

It takes a while to understand allocations in Go. There are obvious ones like `make()` and `new()` and `append()` (though this one doesn't always allocate depending on the capacity of the thing you pass to append, I think). There are less obvious ones (if you don't have experience thinking about it) like string appending and "casting" between `string` and `[]byte`. I think it's also tricky to figure out when escape analysis goes wrong and you're accidentally heap allocating things you didn't need to.

You develop an awareness of these aspects if you do performance-sensitive code in Go. But in Zig all allocations are explicit so you can't really accidentally have allocations.

On the other hand, you have to manually manage memory in Zig. Unlike Rust, Zig has no builtin atomic reference counting. So memory management in Rust and Go are "easier" if you don't want to be aware of memory allocations. Memory management in Zig is "easier" if you need to be aware of memory allocations.

And neither Zig nor Go are as strict as Rust about ownership so it's "easier" to express internally-mutable datastructures in Zig or Go (see "Entirely Way Too Many Linked Lists" [0]). Whereas it's easier to be sure you haven't screwed up ownership in Rust compared to Zig. In Go you don't have to worry since the GC will not let ownership be a problem.

[0] https://rust-unofficial.github.io/too-many-lists/




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: