Aye, and it lives up to that claim as well in my opinion, despite being still relatively young and pre-1.0. My favorite thing about Zig is that it has managed to stay simple and solve many of the problems of C without resorting to greatly increased complexity like Rust (which is much more of a C++ replacement than a C replacement in my opinion).

IMO the marketing as Rust as a C/C++ replacement is a bit misplaced. I think it's more accurate to consider it an alternative systems language. The tools/languages used in this space are a bit broader than C-family languages.

That's true, though systems programming is in practice dominated by the C ABI (great post on that here by the way https://drewdevault.com/2020/03/03/Abiopause.html). Zig does something quite special that puts it ahead of the crowd in this space; It can import and use C libraries as easily as C does (no bindings required), and it can itself be built into a C library, auto-generating the required C headers.

You are absolutely correct on the point of the C ABI. It's definitely the systems lingua franca.

Just finished reading the Zig cc article and I must say I'm also quite impressed. I'll be keeping an eye on the next Zig release--being able to eventually use it as a `cc` or `mvsc` replacement would be a big game changer. Having recently run the study of trying to cross compile a few C++ and GTK apps, I can really see the appeal.

Rust is not a C++ replacement, nor a C replacement. It targets its own niche (embedded, realtime, correctness-oriented). It's a totally different development culture. Zig, OTOH, is absolutely a C replacement.

My day job is maintaining the toolchains for a popular safety-certified realtime embedded operating system. I have never once been asked to provide a Rust toolchain. Fortran, yes. Ada, yes. Python and Go, yes. By and large it's just C (and more and more C++).

Rust seems to be mostly something "full stack developers" and "back end developers" embrace for server-side toys and hobby projects.

Python, on a realtime embedded operating system? Rust isn't really there for embedded development yet. It's great for low-level code on full-blown processors/OSs though

Python: customers ask, I deliver.

Top-end embedded processors have GPUs and hypervisors these days and run AI algorithms to, say, detect lane changes and do parallel-parking maneuvers. These days AI means code written in Python and Fortran.

Rust does not target correctness-oriented code at all. Neither do standard C or C++, for that matter, but there are derivatives of C that can (and are) used for it.

> It targets its own niche (embedded, realtime, correctness-oriented).

I don't know of anyone who actually uses Rust in that niche.

Everyone who uses Rust is using it because of "C++ is hard, let's go shopping instead" syndrome.

I.e., at this point it's a language for beginners to ease themselves into programming without training wheels and eventually graduate to real big boy programming languages.

This is a strange sentiment. I think 99/100 people who know rust would not categorize it as "for beginners"

It's pretty much irrelevant what people feel emotionally about Rust.

The real-world fact is that Rust is, as of March 2020 at least, an entry-level systems programming language. It's used as a stepping stone by former PHP/Python/Go programmers, who are very intimidated by C++, to get into performance-oriented coding.

Nobody actually writing embedded or sensitive code (airplanes, nuclear power stations, etc.) is doing it in Rust.

This makes zero sense and it's not about emotion.

The language is young and you don't certify a software solution every two days or don't rewrite your nuclear power station code every day.

Very experienced programmers switched to Rust because it makes it possible to build large scale industrial programs both efficient and reliable. They won't switch to C++ just because they think they're good enough to live dangerously.

(btw I work on plant control and yes I write parts in Rust)

> Very experienced programmers switched to Rust because it makes it possible to build large scale industrial programs both efficient and reliable.

This never happens in the real world; not unless the 'very experienced' bit is experience only in languages like PHP or Python.

It's true that a lot of PHP/Python/Go programmers look to Rust rather than C++ when getting into performance-oriented code. But it's not really a stepping stone, because you never have to leave.

It's true that not a lot of people are using Rust for embedded software. That's a much harder nut to crack because so many of the toolchains are proprietary (and embedded support in Rust is still missing quite a few things).

> ...because you never have to leave.

You kind of do if you ever want to work on anything other than pet personal one-man projects.

Not for technical reasons though.

Also: I've used Rust at work. In fact, I learnt Rust because I was processing a lot of data at work, and needed a fast language to do so in a reasonable amount of time.

I know it's not as complicated as C++ but it sure seems like they're in a rush to get there :) . Modern (post c++14) covers most of my criticisms of c++ for my daily driver. I still poke at Rust because I really love statically typed languages :)

I've been very surprised by Rust's complexity. Some of it seems to be being hidden over time (as well as adding new features) but its syntax at any given moment is generally more complex than C++.

Really? I would consider its syntax to be of similar complexity but of higher consistency. What parts of it do you find complex?

When you happen to have generics coupled with lifetime annotations for example.

I’m not being contrarian, but I have only been following Zig in passing. Can you give a few example of the increase in complexity, I am genuinely curious. Zig seems, to my eyes at least, to have done an admirable job of remaining simple when compared to the behemoth that is C++, of any vintage (but especially post C++03).

I wonder how much it would cost to sponsor compiles-via-c support. I'd love to use zig-the-language but I need to compile for platforms that LLVM does not support, so I would need to use the native C toolchain (assembler/linker at the least, but using the native C compiler seems easier).

There is a semi-maintained (perhaps more accurately “occasionally resurrected”) C backend for LLVM: https://github.com/JuliaComputing/llvm-cbe

Thanks; I was aware of this but last I checked it only supports a subset of LLVM (whatever Julia needed).

I am still not sold on its security story, usage of @ and module imports.

Can you elaborate on the security story story?

Manual memory management, we have already learned that isn't the way to go, when security is part of the requirements in a connected world.

Still no way to catch use-after-free.

https://github.com/ziglang/zig/issues/3180

Clear, good point, thanks.

I don't know... To me, zig does not look like C at all. IMO, go and zig are as similar to each other as they are dissimilar to C.

I mean, is this C-like?

  fn add(a: i32, b: i32) i32 {
      return a + b;
  }

Yes: https://godbolt.org/z/72Dvpe

Simple stuff like this looks very similar to Rust: https://godbolt.org/z/spkKai

Rust quickly becomes harder though, while Zig is much easier to grasp.

The fact that they compile to the same assembly instruction does not make them similar source code.

The languages are similar enough that the Zig tool-chain can translate C source into Zig source. There's mostly a one-to-one correspondence.

It could hardly be more C-like. Are you getting distracted by the syntax?

When we talk about something being "C-like", the syntax is what we're talking about. Being "distracted by the syntax" doesn't make sense when the syntax is the entire point of the statement being made.

Admittedly it's been decades since I've done any C (literally since 1999, except for an LD_PRELOAD shim I wrote about 5 years ago) but being someone who prefers C and other ALGOL-syntax derivates I find the syntax to be relatively easy to grok. One advantage over C is that the confusing pointer/array/function pointer thing has a well-defined order in Zig, there's no "spiral order" nonsense going on.

There is no spiral. C's pointer declaration syntax is arguably backwards ("declaration follows usage") but fundamentally follows normal precedence rules. The so-called spiral is total nonsense misinformation.

That's exactly my point. It's confusing enough that someone e made a bullshit claim that was totally wrong and confused noobs for years. That won't happen with zig.

That won't happen with any sane systems language all the way back to Algol dialects.

The only thing that C has taken from Algol, was structured control and data.

What about this do you find disagreeable? http://c-faq.com/decl/spiral.anderson.html

The spiral rule works if "pointer to" and "function returning"/"array of" alternate but it breaks if they don't, i.e., if you have arrays of arrays or pointers to pointers.

    int** arr1_of_arr2_of_arr3_of_ptr_to_ptr_to_int[1][2][3]

In this case, spiraling between [1], ×, [2], ×, [3], int is obviously wrong, the correct reading order is [1], [2], [3], ×, ×, int. (Edit: read × = *)

The Right-Left Rule is quoted less frequently on HN but it's a correct algorithm for deciphering C types: http://cseweb.ucsd.edu/~ricko/rt_lt.rule.html

I would name that algorithm "inside-out" instead of "right-left" if my understanding of its behavior is correct.

Aren't you supposed to treat multiple array or pointers as a group?

The fact that it's wrong if you try to generalize it beyond the examples given?

Does it? Here's one that I grabbed from cdecl.org:

  char * const (*(* const bar)[5])(int )

And its translation:

  declare bar as const pointer to array 5 of pointer to function (int) returning const pointer to char

This seems like what I'd get from the spiral technique.

They are both close-to-the-metal, few-abstractions, procedural, imperative Systems programming languages with explicit memory management and layout.

When "we" talk? I suggest that in the future if you mean syntactically similar you say syntactically similar.

But then, of course, it wouldn't have much to do with Zig's "appeal as better C than C", which prompted this whole discussion.

Exactly. I would appreciate an explanation what makes zig c-like if its syntax is nothing like c? What does "c-like" even mean then?

It's about 50% C-like. Which is giving people a That Dress experience answering yes or no to the question.

On a first glance, it does look like a simpler version of Rust, and I say it without demeaning Zig. Looks very promising, I'll be keeping an eye for it.