3 ms·
> It’s a very appealing language to the modern low-end (and not only) applications Current $work language is Go, which is so painful to use. I often look wistf
by kbd 4y ago
> It’s a very appealing language to the modern low-end (and not only) applications
Current $work language is Go, which is so painful to use. I often look wistfully at all of Zig's features that improve on what Go does (particularly with regard to error handling). I hope in the future I can use Zig as a Go replacement and not just a C/C++ replacement.
- 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.