3 ms·
I'm tempted to spend a good while studying Zig just because it says "Zig competes with C instead of depending on it" and folks here are not thrashing it ('Why c
by gota 8y ago
I'm tempted to spend a good while studying Zig just because it says "Zig competes with C instead of depending on it" and folks here are not thrashing it ('Why compete with C at all?' would be my guess of general reaction)
- jschwartzi 8y agoBased on what other posters are saying about the language design and the interface design, it's built in such a way that you don't have to do a ton of boilerplate to integrate Zig code with C/C++ projects. That, in turn, means that you can start new sections of your code base in Zig and gradually start eating your legacy C/C++ code until you have a project written in Zig instead of C. And it seems like it does this by not being too opinionated about your use of memory, unlike Rust. I would be really interested in using it if I had more Clang support in bare metal systems. I think the consensus among embedded developers is that we would all really, really like a modern language with modern type-safety and type-checking, but we also still want to do crazy crap with memory at times. It doesn't matter so much that there's a way to do something, but it matters a great deal how you are expected to do it. Keeping it simple matters, and Zig looks pretty simple compared to other compiled systems languages that I've seen, so that's wonderful.
- AndyKelley 8y ago> you can start new sections of your code base in Zig and gradually start eating your legacy C/C++ code until you have a project written in Zig instead of C. http://tiehuis.github.io/iterative-replacement-of-c-with-zig http://tiehuis.github.io/iterative-replacement-of-c-with-zig
- tom_mellior 8y ago> not being too opinionated about your use of memory That's a bit hard to tell, isn't it? When I checked out the docs after last week's Zig thread, the entire section on memory allocation was a big fat TODO.