News for hackers. Stuff that matters.
Re:Why Zig over C for Systems Programming by variadix on Friday November 13, 2026 @11:24AM (#50485795)
I’ve settled on a dialect of C++ for systems programming after using C for a long time. It’s mostly C-like and I disable exceptions, RTTI, etc. but I do use templates, overloads, methods, lambdas, etc.

I have my own object system with constructor methods that all return a status code so you don’t need exceptions, my own stdlib for containers, buffered I/O, networking, hashing, math, threading, async, etc.

C++ gives you all the features to effectively build your own language, and you can use first class tooling since C++ is widely supported. LLMs also make it much easier to build out and test an entire stdlib on your own.

Re:Why Zig over C for Systems Programming by jandrewrogers on Friday November 13, 2026 @12:07PM (#50486434)
I've essentially done much the same. One of the more under-rated features of C++ is being able to build a new language environment based on a different set of composable idioms from the low-level primitives on up.

C++ is as much a tool for building nice systems DSLs as it is a systems language. The heavy investment in compile-time expressiveness has really paid off for the language over time.

Re:Why Zig over C for Systems Programming by jimbob45 on Friday November 13, 2026 @12:10PM (#50486490)
What are you using for a build system?
Re:Why Zig over C for Systems Programming by faresahmed on Friday November 13, 2026 @12:29PM (#50486737)
Agreed. I'd not ditch the STL completely, but only use its freestanding subset. Implementations contain some very fast SIMD-accelerated code[1]. +The STL works without exceptions.

[1]: https://github.com/microsoft/STL/blob/main/stl/src/vector_al...

Re:Why Zig over C for Systems Programming by pjmlp on Friday November 13, 2026 @01:11PM (#50487426)
This is the way, take what suits your use case, using C++ doesn't mean taking the whole feature list.
Re:Why Zig over C for Systems Programming by bbkane on Friday November 13, 2026 @01:19PM (#50487531)
And don't work with anybody who has a different favorite subset of C++!
Re:Why Zig over C for Systems Programming by pjmlp on Friday November 13, 2026 @02:15PM (#50488347)
Well, that is what coding style guides are for, machine enforced. :)
Re:Why Zig over C for Systems Programming by lilbigdoot on Friday November 13, 2026 @02:39PM (#50488642)
I'm imagining a humanoid hitting me with a spray bottle like a cat every time I break the style in code review
Re:Why Zig over C for Systems Programming by lilbigdoot on Friday November 13, 2026 @02:37PM (#50488620)
I don't write much C or C++, but I like writing transpilers and got pretty far with an F# to C backend a while ago, and it was pretty difficult for me (granted it was my first codegen project)

I tried it again with C++ out of curiosity and C++ is ridiculously featured for making it into your own and little domain languages or something that feels like a new feature. Genuinely kind of awesome for transpilers and it definitely gave some insight to the "C++ is awesome, but you have to pick the 20% of features you like" wisdom I've heard

LLMs were fun for exploring C++ patterns as well. I could ask it techniques for approximating some construct in another language and get a full page of toys to try out. It definitely made me want to explore templates in my own language in addition to runtime generics

Re:Why Zig over C for Systems Programming by adsharma on Friday November 13, 2026 @02:46PM (#50488710)
The reason why I prefer a GC based compiled language with types vs Rust or Zig is that they put memory allocation front end center in the language.

Sometimes I want to think about algorithms and memory management separately.

  scores = {"alice": 100, "bob": 85}
  scores["charlie"] = 92
Try translating to zig.

This is why we need natural language -> pseudo code -> GC typed -> Low level systems.

Both Zig and Rust are fine as the last stage of this software development pipeline with different trade-offs. Problems arise when people try to use them earlier in the process.