4 ms·
I'm going to be pedantic here, but this merely means that Go can't fill Zig's niche. Zig can (in a lot of situations) presumably easily fill Go's role. Both la
by TwentyPosts 3y ago
I'm going to be pedantic here, but this merely means that Go can't fill Zig's niche.
Zig can (in a lot of situations) presumably easily fill Go's role. Both languages have a focus on simplicity and explicit syntax.
In other words, Zig is in fact a decent alternative to Go. Go just isn't a good alternative to Zig.
- littlestymaar 3y agoZig isn't memory-safe, and you're not going to pay for the development overhead of manual memory management if you're doing regular back-end stuff.
- memefrog 3y agoPeople did for decades and a lot of that "regular back-end stuff" is in C++ at the moment. If you wanted to move it to a different language, you might currently choose to move it bit-by-bit to Go. But you could also move it bit-by-bit to Zig, and it wouldn't be an unreasonable choice. Zig is in that sense an alternative to Go, IMO.
- littlestymaar 3y ago> People did for decades Yes, but it was before the invention of mobile phone… Since Java came out, the majority of back-end has been written in memory-safe language, for good reasons. > you might currently choose to move it bit-by-bit to Go Not even Google, the home of Go, has been doing a C++ to Go conversion. Backend services that are still in C++ in 2023 are probably so for good reasons, most likely because they either have: 1. really high performance requirements, hence no Go. 2. low budget, and are mostly maintained as it is, hence no rewrite. In any case, those are only a fraction of the total backend code, which is mostly PHP, Java, and Nodejs.
- deleted 3y ago[deleted]