4 ms·
> I hope in the future I can use Zig as a Go replacement I've only scratched the surface of Zig myself, but my impression is that replacing Go with Zig will pr
by oconnor663 4y ago
> I hope in the future I can use Zig as a Go replacement
I've only scratched the surface of Zig myself, but my impression is that replacing Go with Zig will probably be painful in most cases. I think of the stereotypical Go project as a backend API service, where memory is relatively plentiful, and "make a copy of this string" is something you do all the time without thinking twice about it. It seems like Zig wants you to be more thoughtful whenever you're allocating memory, which makes a ton of sense for low level libraries or kernel code, but which sounds painful for typical large applications.
- mirekrusin 4y agoStrings are immutable in go so they don't need to be copied? https://go.dev/play/p/o-ly05_Q46E https://go.dev/play/p/o-ly05_Q46E
- oconnor663 4y agoYes I know :) Equally importantly, the Go GC will keep a string alive as long as you have a reference to it, so different objects can hold a pointer to the same string without worrying about who's going to free it or whether one of those pointers might become dangling. Python and Go (and others?) get a lot of mileage out of making strings shared and immutable, but languages with manual or destructor-based memory management don't really have that option.