Cro: Maintain it With Zig [LWN.net]

Cro: Maintain it With Zig

Posted Sep 10, 2021 9:48 UTC (Fri) by moltonel (subscriber, #45207)
Parent article: Cro: Maintain it With Zig

This is talking about Zig as a build system for C/C++, not about Zig as a language. We've seen a lot of those before, what could possibly go wrong ? Getting this "foot in the door" as a build system to help transitioning to progressively migrate a C/C++ project to a better language could work, or it could be that people who appreciate the build system are not the same people who appreciate the language.

The article couldn't help jabbing at Rust (talking about the "RIIR mantra" is a gross mischaracterization at this stage), rightfully pointing out that we won't get rid of our C/C++ giants any time soon. But Rust makes by and large the same promise of a good build system a better language, and the possibility of progressive evolution without outright replacing the C heritage.

As nice as Zig looks, to me it doesn't seem compelling enough to dive into. If I'm working with a legacy project, changing its build system is hopefully not on my todo list, but I have many options beside Zig if it is. If I'm working on a new project, Rust seems to have more to offer.

to post comments

Cro: Maintain it With Zig

Posted Sep 10, 2021 14:36 UTC (Fri) by mario-campos (subscriber, #152845) [Link] (5 responses)

>If I'm working with a legacy project, changing its build system is hopefully not on my todo list, but I have many options beside Zig if it is.

I agree: changing a build system on a legacy project is hardly ever a priority. That being said, I think the author mentions it, not for the build system itself as if it's some gift to the world of build systems, but to inform the reader that one can transition gradually to Zig, by using Zig as drop-in replacement for `cc` and other tools.

>If I'm working on a new project, Rust seems to have more to offer.

I am both excited and confounded by all of the languages in the systems-programming space. Just to name a few: Ada, D, C, C++, Go (if you squint), Rust, Zig, Nim, etc. They all seem to have their unique niches, although, as an outsider to these languages, I'm not truly sure what they are and I don't know if or how Rust stacks up to Zig. Or Nim. Or Ada.

Cro: Maintain it With Zig

Posted Sep 10, 2021 22:20 UTC (Fri) by khim (subscriber, #9252) [Link]

It's not about different niches but more about different attitudes. E.g. Rust is the only language without tracing GC which considers the ability to abuse an API to crash the program a CVE event. Sadly it doesn't consider DOS worthy of the same treatment, but most other system languages just say “you are holding it wrong” to such bugreports (ada considers it's Ok if you can abuse heap-allocating procedures but if dynamic memory is not used it uses the same standard).

Cro: Maintain it With Zig

Posted Sep 11, 2021 0:49 UTC (Sat) by dvdeug (guest, #10998) [Link] (2 responses)

For Ada, Ada's old. It doesn't have a lot of the fancy features new systems have, and its system of generics is the very first generic system in any major programming language, the direct ancestor of C++ templates. It is, in many ways, an advanced object-orientated Pascal. (It was the first internationally standardized object-orientated language, in its 1995 iteration.)

For upsides, for one, it's been around for 40 years, and there's a group working on the next ISO standard version. Like Fortran, it will be around for a few more decades. It's got more support than D or Nim or Zig, and unlike Go or Rust, I know it's going to be there for a while. (Look at Perl and Adobe Flash for other examples of shifting sands.) The military and aviation support will keep it alive, and AdaCore is dedicated fairly solidly to supporting the open source community.

For the other, it's a lot more powerful than C and a lot less hairy than C++. It's a fully object orientated language with generics, concurrency and Unicode support. The last update added a lot of support for invariants and the next is working on a lot of more convenient parallel processing constructs. SPARK is a formally provable subset, and there's subsets for running without dynamic memory allocation and for hard real-time systems.

I went hard into Ada after fighting with pre-ISO C++, and I sometimes group it in with my early years in BASIC, as something to be remembered more fondly than used, but SPARK is easier to use than Coq, and for a powerful language at the lowest level of the system, personally, Rust may be the only sane alternative.

Cro: Maintain it With Zig

Posted Sep 11, 2021 2:46 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I tried to look into Ada once and I haven't been able to understand how it deals with pointers and heap data. Are there any guides for that?

Cro: Maintain it With Zig

Posted Sep 11, 2021 3:24 UTC (Sat) by dvdeug (guest, #10998) [Link]

I don't know about guides. It just basically calls pointers access variables, and initalizes them with "new" and you have to make a free function with the generic package Ada.Unchecked_Deallocation, so it's little more sophisticated than C on this. (The clunky free function name is apparently because they assumed everyone would using garbage collection in the future in 1980, so deallocating memory needed to be marked. In practice, except for a couple short-lived JVM or .NET ports, nobody has ever used GC with Ada.) There's object finalization, so you can hide it behind objects that will automatically deallocate the memory when leaving scope, and storage pools, so you can control where memory for certain types gets allocated from, but by and large, it's like C, with all the potential use-after-free errors.

Cro: Maintain it With Zig

Posted Sep 12, 2021 1:59 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

There does seem to have been a resurgence of interest in this topic (systems programming languages) accompanying actual developments.

Rust in particular stands out for its focus on safety and concurrency (and so, safe concurrency). Once upon a time concurrent programming was a weird niche case, and few needed to care about it. Then for a while it was more mainstream but still only something a few very low-level components needed, like a multi-processor operating system, but today it is likely that choosing not to do concurrent programming means choosing suboptimal solutions for an increasing range of problems.

Rust's type system allows it to assure you that your (safe) Rust programs exhibit Sequential Consistency. This means you can reason about the working of your concurrent program in terms of things happening in some order, e.g. if thread #1 did A, then B, then C, and thread #2 observes that C happened, it stands to reason that A has already happened, since that was before C. Modern CPUs do not actually experience Sequential Consistency, raw machine code for thread #1 that does A, then B, then C, will _not_ reliably result in a thread #2 which checks C happened also observing A having happened, so this really is some work for the compiler. In languages like C or C++ the compiler promises to deliver Sequential Consistency *if* your program is free from data races (cases where the same value could be modified simultaneously in two or more places) but if you fail the program not only doesn't have Sequential Consistency its behaviour is Undefined. Rust sidesteps this by making such races impossible in the language design. If you try to write a data race your program won't compile.

I think C++ stands out as the most friendly to would-be consultants. A consultancy career in C++ looks safe even if you started today, there's a lot of C++ out there and it's fantastically complicated, even if interest in the language for new projects wanes over the coming decades, I can't see an expert in C++ struggling to find consultancy gigs in 2050. And if C++ continues to go from strength to strength, that's just more opportunity for consulting. As a programmer having so many different ways to initialize a variable, plus the knowledge that some (but not all) variables in the language can be declared uninitialized, is annoying. But as a consultant that means even "variable initialization" becomes a topic heading, you can have policies, you can talk about existing practices, you can write an exercise, tonnes of fun.

As we see in the article, Zig has a remarkable cross compilation story. There are plenty of other small things to like about Zig, but I'd say the one that stands out is how enthusiastic Zig is about solving your build problem. If this dominates the work you don't like on a hobby project, that might be enough reason to adopt Zig even if nothing else about it appeals to you.

I suspect Go's niche is exactly what Google specified, although perhaps less than they had hoped. New hires can write a Go program that has reasonably good performance, and it probably either does what they expected or they've got a reasonable chance to fix the bugs and make it work. Go doesn't want you to be too clever, in fact it specifically cautions against this. But, it turns out that although it's not as dangerous as C or C++ it's still not actually safe, and although it's not as slow as Java or Python it's still not actually fast, and although it's easier to learn than Rust or Haskell it's still not actually easy. Trying to be the best would have involved being clever, and they didn't want to. If you can only ever learn one programming language, you could do much worse than Go. But if you can learn two, there's no reason I can see why either of them should be Go.