Interview with Zig language creator Andrew Kelley [video] (opens in new tab)

> But sentences like these in the documentation [2] would make me prefer Rust for most low level domains

While such use-after-free issues are not prevented at compile time, the plan is to ultimately have safe Zig catch them (and panic) at runtime, i.e. safe Zig shouldn't have undefined behaviour. Because this is done with runtime checks, the expectation is that those checks will be turned off (selectively, perhaps) in production, after testing has satisfied you. In that case, the guarantees aren't as strong as Rusts, but those guarantees come at a significant cost -- to language complexity and compilation time -- that can also have a negative effect on correctness. So while Zig's approach to safety/correctness is certainly very different from Rust's, I don't think it is necessarily weaker (perhaps it could even be stronger, but the question is hard to settle).

Yeah, I've been using no_std for this use case and pretty happy with it.

If you want a full blown container you can use heapless, building a custom container is really straightforward and requires a minimal amount of unsafe.

That is pretty common in low level domains. Rust instead comes with complexity of borrowck and lifetimes management no matter how rustaceans say it is second nature.

The actual Modern C++ design book from Alexander’s ci is about custom allocators and performance.

The irony.

std::span is a modern C++ class designed to act like an array or vector, by viewing the memory of an existing array/vector without allocating anything. In my experience writing audio code, C++'s implicit copy constructors are what makes it too easy to accidentally allocate memory.

Can you explain how this is a problem in modern C++? I was under the impression that all the STL containers (string, vector, list, map, etc.) worked the same and have an allocator parameter. Are there other areas where these are missing? Or is the issue that STL implementations almost always default to an allocator that uses malloc? I'm not trying to dog on Zig here (it's a nice little language) but this just doesn't seem to be something that only Zig can do.

Is there any way to mark "this code does not call malloc"? Or maybe more generally, "this code does not use anything from libc"?

I also wish that Rust had linear types, it would make a lot of FFI easier without resorting to unsafe{}.

With linear types you can guarantee that a destructor is run, so you can create objects with lifetimes that are not only bounded from below, but bounded by above. There are some common patterns in e.g. C libraries that rely on this--for example, you might register a callback on an object, and you want to assert that the object's lifetime is shorter than the callback's (so the callback is never called outside its lifetime).

Since Rust doesn't have linear types, you have to use unsafe{}.

http://ats-lang.sourceforge.net/ baby!

To be honest, I'd be a lot more worried about physics PhDs then I would interns. I've seen plenty of 20 year-old engineering students write solid low-latency code. I can't say the same thing about string theorists.

It'd be pretty unusual for junior or non-technical people to write code in "core" components of the system. Things like datafeed parsers, order handlers, inventory management, safety checks, networking libraries, exchange connections, etc.

But even with all these layers in place, you still need an actual strategy to run at the end of the day. Everything in the quoter can be optimized to hell, but if the strategy module is spinning for 1000+ microseconds because it's running some bloated ML model, then none of that really matters.

Usually the system engineers and the strategists are different people. Not always. Especially in the case of more straight-forward mechanical strategies. But anything reasonably complex usually requires dedicated quants with different skillsets than profiling C code.

Nit pick: On modern systems malloc isn't a syscall, it's implemented in userspace. (Sorry, I couldn't help it)

That's not to say you're safe to call other syscalls, many of them either require memory allocations in-kernel (see ENOMEM) or can block indefinitely.

Literal interns are not very likely to work on it, but juniors might, and the junior's probably not going to know much more than an intern.

> On the other hand, Zig makes a deliberate decision not to bother itself with memory safety too much

This is not true. Zig places a strong emphasis on memory safety, it just does so in a way that's very different from either Java's or Rust's. I wrote more about this here: https://news.ycombinator.com/item?id=24293329

I didn't say I actually use it, I said it's the perfect language for that use case. In practice there are many other factors that determine whether a language is adopted, e.g. library availability, compiler maturity, and the fact that it's not simple to integrate a new language into an existing codebase of very many lines of C++.

Right, they are only approximately comparable, but the important thing to remember is that features of formalisms are never goals in themselves, but rather means to various ends. The goal is never "to have interfaces/typeclasses/traits" but to be able to specify an algorithm that works for a variety of data structures with shared properties. Moreover, I think it would be a mistake for Zig library authors to try and replicate styles used in other languages. Zig provides sufficient mechanisms for expressing programs, and it will develop its own style. There will be elements that are analogous to those in other lanugages, but not identical.

Having said that, I do support a proposal for specifying a type at the parameter declaration with some type -> bool function.

I like this quote by Leslie Lamport about comparing formalisms (he talks about specification languages rather than programming languages, but the sentiment is the same):

> Comparisons between radically different formalisms tend to cause a great deal of confusion. Proponents of formalism A often claim that formalism B is inadequate because concepts that are fundamental to specifications written with A cannot be expressed with B. Such arguments are misleading. The purpose of a formalism is not to express specifications written in another formalism, but to specify some aspects of some class of computer systems. Specifications of the same system written with two different formalisms are likely to be formally incomparable… Arguments that compare formalisms directly, without considering how those formalisms are used to specify actual systems, are useless.

> Are there features that Nim implements which go against this premise? if so, what are they? :)

Nim has generics (plus concepts), templates, and macros. Zig has just comptime, through which it achieves all those goals (minus some macro capabilities that it deems harmful anyway) with just one, very simple, cohesive construct. You could argue on whether you like this or not, but you can't argue that Zig's approach isn't fundamentally more minimal. Zig is a language you can reasonably fully learn in one day; I don't think you could say the same about Nim.

---

Also, note another remarkable feature. One could define a language called Zig' with the following properties:

1. Every well-formed Zig program is a well-formed Zig' program (i.e. Zig' accepts all Zig programs, potentially more).

2. Every Zig program has the same semantics as the identical program when interpreted in Zig'.

This means that to analyse the semantics of a Zig program you can pretend it's a Zig' program; in fact, you don't need to create an interpreter for Zig', you can just pretend it exists. Why would you want to do that? Because Zig' is simpler. How? Here's the kicker: Zig' ignores comptime completely. It is a very simple, optionally-typed, dynamic language with reflection.

In other words, to analyse the semantics of a Zig program you can forget about comptime and pretend it can do everything at runtime (and treat comptime as a pure semantics-preserving optimisation).

This is not true for languages with macros, as they are not "erasable".

> and rust is taking inspiration from it already

But C++/Rust can never have Zig's primary feature -- simplicity. Zig's power is not that it has comptime, but that it has little else.

> I can't wait before Zig2 comes and eventually adds generics…

No need. Zig gives you the same capabilities as generics do, only through a separate feature that other languages also have in addition to generics. In other words, it has generics, but without having generics as a special construct. Zig recognises that once you have that other feature (compile-time introspection) you don't need generics as a separate construct, but they can be just an instance of that single construct.

Zig already has generics, gp was imprecise. They are not a part of the language, but an emergent feature that is simple enough to implement using comptime.

Edit: clearly gp was not mistaken, just imprecise.

In Zig types are values (same as any other value.) This lets you do generics without the need for any special syntax; you can simply pass types as parameters and return types.

Looks like comptime is what they already have instead:

https://ziglang.org/documentation/master/#Introducing-the-Co...

Clearly you meant zig++

I don't have any particular examples in hand, but the question you're asking is one that's tough to answer because the languages that might be as ergonomic as Haskell in that regard and are also low-level are significantly more complex than either Haskell or Zig, and so I don't think we have a good point of comparison (I think Zig is revolutionary). There is definitely a price to pay for being a high-control/low-level language, and it certainly requires that you spend some of your "complexity budget" on things that high-level languages like Haskell or Java don't have to. But I think Zig shows that you can be both low-level and reasonably "expressive" without also being so much more complex than most high-level languages.

Zig has generics, they are just not part of the language (very easy to implement using what zig gives you).

> The vast majority of programmers don't use low-level languages for writing applications

I work in a multi-million-line codebase, a significant majority of which is very far from that "need perfect control" domain but is written in a what I'd call a mid-level language - a high-abstraction dialect of C++. So I'd say GP is correct, that too many people are stuck writing code in the wrong language for the task at hand. The need for languages like Zig to improve the lower-level experience (which, as you say, is not going away) and the need for higher-level languages for more common types of programs are not in conflict. They're complementary. It's the mid-level languages that need to DIAF, because they're not really suited for either and pretending to be more general than they are only encourages people to make choices that hurt them.

For me the way to go are languages that go all the way, C++, Ada, Object Pascal, even .NET and Java could fit into it, if the low level story ever gets straight. Currently AOT like .NET Native seems on the right path to achieve it.

Burroughs, Mesa, Modula, Oberon, Interlisp-D,... were on the right path, but in technology not always the best ideas win.

> Sometimes you do not want to be burdened by the limitations of a "high-level" language.

I see very few people suffering from such burdens, but a great many suffering from its exact opposite: using a low- or mid-level language to write hundreds of lines where ten lines in a higher-level language would suffice and be more easily verified as correct.

Ada, D, Pascal/Delphi, and yes, Fortran, are all still options.

I think Zig has the potential to be the best of them, fwiw.

It'd argue that the constraints of writing lower-level code can actually lead to producing better code. For instance, idiomatic C, Rust and Zig is to pass a buffer into some function, that it then fills, and the caller handles the output. This leads to having more pure, side-effect free functions, compared to the approach some higher-level languages will take of having the function allocate some stuff in its body, process it, maybe do some IO, and pass it to another function. They encourage "imperative shell, functional core", because of how difficult it is to manage memory/ownership if every random function is allocating promiscuously.

Low-level languages encourage the use of clean ownership patterns, which ultimately leads to cleaner design.

Valgrind on C is the closest thing I've worked with in terms of what Zig offers.

My experience is that Rust's approach is definitely better in terms of correctness than using valgrind during testing.

My intuition is that the advantages Zig brings to the table will not tip the balance.

That being said, the choice Zig makes is absolutely the right one. Rust fills the niche of a better and more correct C++ without fixing the issues of slow compilation and language complexity.

Zig fixes so much of what's wrong with C without abandoning the advantages of language simplicity and locality of reasoning. I love Zig, but need a medium sized non-work project for it.

My understanding is that Zig goes further than that. In particular it just added a safe allocator suitable for production,

https://github.com/ziglang/zig/pull/5998

edit: For more details, see

https://ziglang.org/#Performance-and-Safety-Choose-Two

That is the same approach used in many C++ projects

That's not on par with linear or affine types.

Does zig have an answer to RAII yet?

> You lose soundness, but we don't have sound guarantees for functional correctness, anyway

This sounds like "we can't guarantee the most important thing, so it's unclear whether it's useful to guarantee this other thing," but that's a bizarre statement, so am I misinterpreting?

I've been slowly replacing the C files of xv6 with some zig. It was surprisingly easy with the generated header files to use zig from within the C part.

> Standard library documentation is indeed clunky as it is auto-generated for the most part.

I have not expressed myself clearly: the auto-generated documentation is severly lacking. The API of the standard library is clunky. To be fair, both those points are getting better. And yes, the language is very young and I understand that there are more pressing issues with the core language itself.

> I personally like that Zig doesn't bother with "strings" at a language level at all and just considers everything as arrays of bytes. String handling is a complexity nightmare and I feel that Zig wisely chooses to be simple instead.

It is definitely simpler, alas not everything is ASCII and arguing it should be to make life easy for programers is hardly a reasonable stance.

Also, maybe it is not clear in my comments but I actually enjoy Zig.

I believe OP was saying that the Python 2 → 3 debacle shows it's important to get strings right the first time.

Well there are no strings, only byte arrays. Now that's fine if you only pass bytes around in a stream, but if wan't to do any computation it you have to assume an encoding and basically anything outside of straight ASCII will be a pain.

Now you may argue that this can be handled nicely in the standard library without changing the language. This is correct, but there will be some frictions with string litterals.

To 'master' C is actually realizing C itself is not as simple as it looks from its syntax. It's an old language and the implementations are by no means straightforward. I'm by no means a C master but I have worked with people who are, and they know nuances of the language and the way it compiles down to various platforms in ways that shame me.

But in general I have gone for for generalist not specialist in my career.

<rant-time>

I can't help but feel like in our industry C is successful (vs its 80s competition of Pascal/Modula-2, or Ada etc.) partially because of some of the same reasons that Git is successful now. Yes, it is powerful and flexible; but also in some ways unnecessarily arcane and 'dangerous' and _this gives the user a feeling of cleverness_ that is seductive to software engineers.

Put another way: Most of us enjoy the mental stimulation of programming, and we enjoy the mental challenges (in general). C makes us feel clever. Witness the "obfuscated C programming contest" etc.

Same thing that has led to nonsense 'brain teaser' whiteboard-algorithm tests at job interviews. IMHO it's in many cases for the benefit of the interviewer's ego, not the company or the interviewee ("gotcha! no job for you!").

</>

If one does both, almost certainly learning zig will make for a better C programmer, as zig often forces you into patterns that would be best practices for a C programmer.

Is the https://ziglearn.org site up to date with the latest versions of the language and standard library? The initial "Hello, World" example fails to compile for me. I get:

Semantic Analysis [533/803] ./main.zig:4:14: error: container 'std.debug' has no member called 'print' std.debug.print("Hello, {}!\n", .{"World"});

Is there something in between homepage and docs? Like 30-50 line workout programs?