The Road to Zig 1.0 - Andrew Kelley

You have pretty explicitly framed Zig as a C replacement yourself, e.g.: ▶ this video More broadly, I think the observation tends to get repeated because C and Zig share a certain elegance and simplicity (even if C's elegance has dated). C++ is many things, but it's hardly elegant or simple. I don't think anyone denies that Zig can be a C++ replacement, but that's hardly unusual, so can many other languages (Rust, Swift, etc). What's noteworthy here is that Zig is almost unique in having the potential to be a genuine C replacement. To its (and your) great credit, I might add. >> At its core Zig is marketed as a competitor to C, not C++/Rust/etc, which makes me think it's harder to write working code that won't leak or crash than in other languages. Zig embraces manual memory management as well. @GP: This is not a great take. All four languages are oriented around manual memory management. C++ inherits all of the footguns of C, whereas Zig and Rust try to sand off the rough edges. Manual memory management is and will always remain necessary. The only reason someone writing JS scripts don't need to worry about managing their memory is because someone has already done that work for them.

in “Anthropic acquires Bun” · View on HN

> I do not understand your criticism of [N]. This gives compiler more information and catches errors. This is a good thing! It only does sane thing in GCC, in other compilers it does nothing and since it's very underspec'd it's rarely used in any C projects. It's shame Dennis's fat pointers / slices proposal was not accepted. > warrant the additional complexity IMHO In zig case the comptime reduces complexity, because it is simply zig. It's used to implement generics, you can call zig code compile time, create and return types. This old talk from andrew really hammers in how zig is evolution of C: ▶ this video

in “Low-Level Optimization with Zig” · View on HN

the constexpr stuff has been around since the beginning[0]. concretely, what other thing from D do you claim zig has added since? [0] minimally 2019, 3 years in: ▶ this video

in “Obvious things C should do” · View on HN

Zig is not supposed to be a Rust equivalent. It's supposed to be C but with the problems fixed. ▶ this video

in “Learning Zig” · View on HN

All right, now that someone downvoted you (not me), I feel a mild obligation to respond. Regarding the ad hominem part, I invite you to watch ▶ this video to understand why I think our industry needs to elevate the level of our craft. And also please take a look at the actual requirements CRA puts on devs in [link] (pages 2 and 3 – yes, just those two pages* plus requirements on documentation on page 8, which could be a bit more annoying than the requirements on pp. 2 and 3). I hope you will find them reasonable for the most part. Regarding GDPR, I am indeed sad that so many people interpret it incorrectly. This happens in part due to the influence of various groups, as you say. I invite you to read the blog of [link] to understand the spirit of GDPR (indeed, there is a thing called "data minimization" that could be the reason you find it difficult to collect more data without a solid justification; in a fun twist, §1(3)(e) of the CRA annex also mentions data minimization) and see that the progress is made slowly yet steadily. If you noticed big websites recently show the option to deny tracking cookies directly instead of "manage cookies", you got these folks to thank ( [link] ). BTW, I donate to them and think they are doing awesome work. * unless you are doing "serious stuff" (TM) as described on pages 5 and 6.

in “EU to vote regulation that has a considerable potential to hurt OSS” · View on HN

I just think our industry is long overdue for some regulation ( ▶ this video as an inspiration ) and I also found the CRA requirements on pp. 2 and 3 ( [link] ) quite reasonable. What shocked me is how nobody on the thread considered/appreciated those two things. Having said that, there is a chance CRA implementation will get bungled, but I hope for the better. Regarding the commercial activity: I found the screenshot of a 3-part test from a recent Eclipse call and I hope it's OK to post it ( [link] ). I think it's important to understand that in a multi-part test, you typically need to seriously hit a few points to "pass" the test. Some examples of what I would consider passing each point (but not necessarily the whole test): 1. Rust with its 6-week release cadence will quite likely pass the 1 part. 2. Nginx, k8s, Ubuntu LTS will quite likely pass the part 2 of the test. That's the part of the test that worries Github and others, because receiving money and significant contributions from corporate will contribute to scoring high on this point. 3. A project like Eclipse 4diac ( [link] ) would quite likely pass the 3rd part of the test. But then, Eclipse 4diac could claim that it's mainly an R&D project and thus not passing the part 2 of the test. And even part 1 of the test would be hard to establish with barely 1 release a year.

in “EU to vote regulation that has a considerable potential to hurt OSS” · View on HN

not really, unless you're only building for one platform. gnu make isn't portable and doesn't have any real dependency management, so meta build systems quickly become a necessity. cmake is the most portable and the only real option on windows, but it's common to see projects that maintain support for both cmake and autotools. and that's ignoring the nightmare of cross-compiling with gcc. andrew kelley has talked about this[1]. his main point was about the number of dependencies you end up with compared to zig, where the standard library includes a high-level build system api. so your zig build scripts are written in ziglang and run by the zig compiler. no extra dependencies. [1] ▶ this video

in “Maintain It with Zig” · View on HN

Zig libraries can be exported with the C ABI[0], so pretty much anything can interface with it. You can write very fast code with it. It is also small and fits in your head. The only thing missing is a variety of implementations, however there is a clear path to bootstrapping the compiler from source with a semi-recent C++ compiler[1] and from there, there's already a growing number of supported targets[2]. There is also a major focus on making sure cross-compilation is well supported out of the box, including C code that Zig can also compile[3]. It's perfectly fair to compare Zig to C in this case, as the project originated as a dialect of C before the author decided to do a complete clean break[4]. The primary frame of reference when designing the language was C and addressing its shortcomings, both language and tooling. [0]: [link] [1]: [link] [2]: [link] [3]: [link] [4]: ▶ this video

in “Looking into Zig” · View on HN

Indeed. In this video he explains the reason why he made those choices: ▶ this video All these programming language features require a lot of machinery, complicating the binary interfaces of the resulting software and preventing code reuse.

in “Building an efficient and portable programming language with Zig” · View on HN

quoting myself [1]: "It's really easy to make fun of C++, but everyone has that one feature of C++ that they like. And they want to put it in Zig. If everyone had their favorite feature from C++ in Zig, Zig would just be C++. But I'm not going to let that happen." ▶ this video

in “Building an efficient and portable programming language with Zig” · View on HN

Operator overloading leads to a complex binary interface. Avoiding complexity in this area is important given that simple binary interface is a huge reason why reusable software is still written in C. ▶ this video

in “Announcing The Zig Software Foundation” · View on HN

Here is a talk I gave that directly addresses this question: ▶ this video (the title & abstract in the youtube description is the one I gave for the RFP; I ended up going in a slightly different direction than it once I actually made the talk)

in “Hobby x86 kernel written with Zig” · View on HN

Using anything other than C makes one's code unusable as a general purpose library due to the complexity of the binary interfaces. Writing C++ ensures the code won't be touched by anything but more C++ code. A Python script can load a C library shared object, resolve a symbol to a function pointer and call it. I don't think I'll ever see Python load a C++ library shared object, obtain a pointer to a C++ object and call methods on it using the C++ ABI and handle the C++ exceptions it may throw. The only way to interoperate is to sacrifice all the benefits of C++ and adopt a C interface. Rust has this feature as well. I like how the creator of Zig put it: if it doesn't speak the C ABI, someone's gonna rewrite it in C. ▶ this video

in “JavaScript Is C” · View on HN

> With a finger you can follow the code as it runs and know exactly what is going on and when exactly. Oh yeah? ▶ this video

in “A Defer Mechanism for C” · View on HN