Hacker News Reader

Comment by cies | Hacker News Reader

I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.

Zig OTOH is clearly, to me at least (opinion alert), a "better C". It even compiles C!

I expect LLMs to be really good at converting C to Zig.

> There is also the issue of will people actually code by then.

LLMs don't take responsibility. So even if code is generated, a human will have to assess it. I think assessing Zig is easier than assessing C, which gives this language a selling point that holds out in the AI assisted programming future.

View on HN

I've been coding in Zig for nearly 2 months straight now.

Or should I say, I've not written a single line of Zig because I've been managing AI's coding in Zig.

Turns out Zig is a fantastic language to "centaur" on. (Reference is to "centaur chess" and which is also sort of becoming a term indicating close code design cooperation with an LLM.)

All of that C code that the LLM trained on ends up helping it work out algorithms in Zig, except that Zig has waaaay more safety guarantees and checks. And is often faster compiled code than the equivalent C, which is astonishing.

I like that I can easily smell bad Zig by looking at it, but I'm notoriously bad at smelling bad C.

> I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.

The same can be said about Zig's comptime. It's entirely unlike anything C, C++ or Rust has to offer.

> I expect LLMs to be really good at converting C to Zig.

While it's possible to translate C to Zig code - and you don't need an LLM for that, it's a Zig compiler/build-system feature - the result will be quite different from a project that's developed in Zig from the ground up since the translation output wouldn't make use of Zig's unique features (and Zig isn't really unique as 'C translation target', C can also be translated to unsafe Rust, or even to Javascript - see early Emscripten versions).

Also, the 'C compatibility' of Zig is implemented via a separate compiler frontend, Rust toolchains could do exactly the same thing by integrating the Clang frontend into the Rust compiler.

Using the same language for compile-time and run-time programming is compelling, but doing it properly requires using the same approaches that dependently typed languages use. Comptime is a bit half baked.

It's not just about writing imperative code that runs at compile time, the actual interesting comptime feature in Zig is that "types are comptime values", e.g. you can inspect types and build new types with regular (comptime) code. This is very different from the template/trait systems in C++ and Rust. What Zig's comptime system is missing is the ability to build functions bodies at comptime (e.g. some sort of comptime AST builder).

"You can inspect types and build new types at compile time" is a key affordance of dependently typed languages.

I agree. I am not terribly convinced by C++ or Zig's comptime. You should be able to do this at run-time, and then just be able to make it a constant.

Zig's comptime is an addition. You don't have to use it. And some C-macros may translate quite cleanly to it.

OTOH going from C++ (OO) to Rust (not OO, borrow checker) is a big leap.

Not all C++ is OOP, and Rust does support OOP as per CS literature, so much so that I have had no issues rewriting Raytracing Weekend tutorial from C++ into Rust, while keeping the same OOP architecture from the tutorial.

Reply on news.ycombinator.com