The Road to Zig 1.0 - Andrew Kelley

Sorry, one more thing to add to this: Andrew Kelley is obviously a genius, and his talk introducing Zig[0] is in my top 10 of all time technical presentations, for many reasons. But I really do wish someone close to him with a passion for how coding is in many ways applied mathematics, would ask him to please have broader algebraic support for basic operations like +, -, * and maybe divide, with their basic dataflow characteristics. Optimal speed for complex numbers vs std::complex out of the box would be attractive. I understand his point about not wanting to allow every random C++ feature, but in these cases, it isn't a C++ feature, it's language-level basic algebra. In C++ land, ISPC[1] is often what you use when you want top speed rendering perf on SIMD CPUs, e.g. Moonray project[2] Please, just go ahead and define a nice clean API for vectors and scalars like OpenCL provides on its beautiful reference cards: link [0] ▶ this video [1] link [2] link Final edit sorry: in the end I love C++ and have been learning Rust mainly out of curiosity. Avoiding C++ quirks one can have few problems and a great time.

I can only hope my own language will become "incredibly small" like that one day. :) Even if a language doesn't take off, its ideas can make a difference and influence future designs. The creator of Zig certainly made an impression on me with this talk: ▶ this video Even if Zig hadn't been successful, the ideas it represents would've enriched the world. Gives me hope I'll be able to make something out of my own ideas too one day.

Andrew Kelley's intro[0] is probably the best talk I've ever seen, and his continuing leadership seems really great to me and worth supporting. Besides my reservations for its use in graphics programming (see my other comment) it looks very attractive in many practical ways (build system!! fuck CMake!) I could go from how I currently write my hobby code, sometimes a prototype for future commercial code. [0] ▶ this video

I would recommend this talk by the creator of Zig: ▶ this video He gives some examples of C vs Zig and what they tried to improve.

In addition to the other recommendations, the Zig Zen[0] and The Road to Zig 1.0[1] are pretty convincing. [0] link [1] ▶ this video

Here is a newer talk (April 2019) which is also by me and also an introduction to Zig: ▶ this video A lot has changed since then, and a lot has changed since that Localhost talk. To catch up: * (the older talk happened here) * 0.3.0 release notes - link * 0.4.0 release notes - link * (the newer talk happened here) * 0.5.0 release notes - link

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.

> 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

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

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

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.

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.