Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> It's another "C but better" language.

This is actually a surprisingly underserved field. There's relly very few language that actually tries to be just C but better.

Go: Uses garbage collection, not very applicable

Rust: Too complex, more like C++ but better. Bit too cumbersome to write "unsafe" code

D: More like Java/C++, although they have a "better C" mode, but feels like an afterthought

Nim: Uses garbage collection.. like D they're kind of trying to reach down into the plain C usecase, now with some nice reference counting stuff. Also relatively complex

Some actual attemps that I know of: C2, Odin

Some reasons why Zig is a better attempt at "C but better":

- Complexity of the language is just a little higher than C, and mostly in ways that resolves issues with C that leads to its own complexities (Like, the C pre-processor is simple, but solving problems with it can be surpringly complex. Or how you may have to resort to compiler extensions/pragmas to solve real problems)

- The Zig compiler is also a fantastic C compiler

- C headers can be imported and used directly in many cases

- Significant parts of the language is dedicated to excellent interop with C (even has syntax for 0-terminated strings)

- Cross-compilation is a highly prioritized use-case (C is very popular in embedded programming, where cross-compilation is essential)



I don't think it's fair to dismiss some of those, like Rust. That project very explicitly wants to be viable as a safe tool for writing systems code, and the fact that it's accumulated a lot of complexity doesn't take away that intent (or the fact that it's being successfully used in that capacity).

That said, I am super excited about the Zig project, and it hits a sweet spot for me in a way that none of the other "C but better" projects have. Calling it another "C but better" language wasn't an attempt to disparage the project, but to classify it.


> That project very explicitly wants to be viable as a safe tool for writing systems code

Right, but that's a (slightly) different goal from being a C replacement. There are other systems languages besides C, and C is used beyond systems programming.


I guess we're disagreeing about the semantics of "C but better" then. Your position seems to be that a contender would need to be able to replace (and improve) C generally, and I don't totally agree (not that you need to be convinced, but I'll elaborate on my interpretation anyway).

E.g., if somebody came along and said that C would be bloody perfect if it just had a garbage collector then that alternative language would be totally unsuitable as a replacement for C in many contexts, but for a ton of other scenarios it'd still be "C but better," and I don't know that it should be disqualified just because it isn't a full replacement.


Don't forget Ada!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: