Hacker News Reader

Comment by AndyKelley | Hacker News Reader

Hello HN! Here is some context to decorate this announcement:

The Zig self-hosted compiler codebase consists of 197,549 lines of code.

There are several different backends, each at varying levels of completion. Here is how many behavior tests are passing:

       LLVM: 1101/1138 (97%)
       WASM:  919/1138 (81%)
          C:  740/1138 (65%)
     x86_64:  725/1138 (64%)
        arm:  490/1138 (43%)
    aarch64:  411/1138 (36%)

As you might guess, the one that this milestone is celebrating is the LLVM backend, which is now able to compile the compiler itself, despite 3% of the behavior tests not yet passing.

The new compiler codebase, which is written in Zig instead of C++, uses significantly less memory, and represents a modest performance improvement. There are 5 more upcoming compiler milestones which will have a more significant impact on compilation speed. I talked about this in detail last weekend at the Zig meetup in Milan, Italy[1].

There are 3 main things needed before we can ship this new compiler to everyone.

1. bug fixes

2. improved compile errors

3. implement the remaining runtime safety checks

If you're looking forward to giving it a spin, subscribe to [this issue](https://github.com/ziglang/zig/issues/89) to be notified when it is landed in master branch.

Edit: The talk recording about upcoming compiler milestones is uploaded now [1]

[1]: https://www.youtube.com/watch?v=AqDdWEiSwMM

View on HN

Congratulations with the milestone!

Does using Zig over C++ lead to "less memory, and represents a modest performance"? Or was the C++ implementation a bit sloppy? (lacking data oriented design for instance)

Also, what specifically are you most excited using Zig for?

Thanks :)

The new Zig implementation is certainly more well designed than the C++ implementation, for several reasons:

* It's the second implementation of the language

* It did not have to survive as much evolution and language churn

* I leveled up as a programmer over the last 7 years

* The Zig language safety and debugging features make it possible to do things I would never dream of attempting in C++ for fear of footguns. A lot of the data-oriented design stuff, for example, makes use of untagged unions, which are nightmarish to debug in C++ but trivial in Zig. In C++, accessing the wrong union field means you later end up trying to figure out where your memory became corrupted; in Zig it immediately crashes with a stack trace. This is just one example.

* Zig makes certain data structures comfortable and ergonomic such as MultiArrayList. In C++ it's too hard, you end up making performance compromises to keep your sanity.

Generally, I would say that C++ and Zig are in the same performance ballbark, but my (obviously biased) position is that the Zig language guides you away from bad habits where as C++ encourages them (such as smart pointers and reference counting).

As for less memory, I think this is simply a clear win for Zig. No other modern languages compete with the tiny memory footprints of Zig software.

Some of the projects I am exited to use Zig for:

* rewriting Groove Basin (a music player server) in zig and adding more features

* a local multiplayer arcade game that runs bare metal on a raspberry pi

* a Digital Audio Workstation

Thanks for the detailed answer! I have more questions, if you'll indulge me:

If I understood it correctly, you think smart pointers and reference counting are bad habits. Why? Especially the smart pointers bit.

Why does Zig use less memory than other languages? Is it inherent to Zig, or can it be reproduced in other languages?

I think Zig prefers explicit memory management, because allocations may fail and should be handled explicitly, and because automatic deallocations lead to hard-to-predict lifetimes (excess memory usage, and bugs for resource handles that are destructed at hard to predict moments).

These are things that a "systems language" programmer should put in the work to do correctly/near-optimally, and not ask the compiler to just do something "good enough", like Python would.

> because automatic deallocations lead to hard-to-predict lifetimes (excess memory usage, and bugs for resource handles that are destructed at hard to predict moments).

I don't really feel this is the case in Rust.

But it is. If you have a String on the stack, it's memory is only reclaimed at the end of the scope, while it often could be free'd before. This is especially bad in async code around await point since it means the memory need to be kept alive more than needed.

I disagree. It is substantially and unequivocally better to hold onto memory until the end of scope than to leak memory by default. How can anyone argue that leaking memory is a better default? That’s a ticking time bomb. Maybe someone is so optimistic as to believe they’ll catch every leak before shipping new code?

You can easily add a manual “drop” call in Rust at any point if you want to force an allocation to be freed sooner, but I speak from years of experience using Rust for work when I say that Rust’s RAII model is not problematic in practice. I’m not simply speculating or theorizing, and I have professional experience with a variety of languages at all levels of the stack. I personally don’t mind garbage collectors most of the time, but Rust is great when you need more control.

In C++, RAII can absolutely be problematic because you are able to easily do things that cause undefined behavior by accident, which is arguably worse than either leaking by default or the mere act of holding onto memory for the duration of a scope.

If you can propose a system which cannot be contrived to have any downside, that would be fantastic! In the real world, Rust’s approach to memory management is extremely pragmatic and beneficial. I’m sure someone will eventually improve on Rust’s approach, but “leak by default” isn’t it.

I honestly do enjoy following Zig… it is a fascinating language taking a really interesting approach to solving many problems, but its memory safety story is not where I want it to be yet. Leaking memory by default is technically safe, but it's not exactly endearing.

Of course you can call drop() manually, but almost nobody does or even think about it because that's not the way you program in a language with RAII.

Don't get me wrong. I do think that rust and c++ RAII is much more convenient and safe than the C or Zig way.

(I'd even prefer if you could annotate given struct in rust so the compiler could drop them as soon as it's no longer used, but that s not that simple)

I definitely wish that Non-Lexical Lifetimes would eagerly drop anything that doesn't implement Drop.

It would probably be a breaking change to automatically call an explicit Drop implementation anywhere other than the end of the current scope, so I think that would have to be left as-is. String doesn't implement Drop, so it could easily be dropped eagerly within the scope as soon as it won't be referenced again. Such a change would be roughly equivalent to any of the compiler optimizations that reorder statements in ways that should be unobservable.

100%. I would actually go further and say every value should be dropped immediately after its last use, including temporaries in the middle of statements, whether or not it implements Drop. Reuse the same rules that NLL uses. Breaking change yes, so do it next edition. It would lower memory usage in general and solve so many little pain points, not least of which is holding strings across await points.

    fn foo(xx : &Mutex<String>) {
        let lock = xx.lock();
        let ptr = &mut *lock as *mut String;
        unsafe { use_from_c(ptr) }
    }

You get the idea: you don't want the lock or the string to be dropped before the unsafe code, even if the actual string is no longer used. That's the breaking change. It's hard to detect automatically, so hard to justify even in an edition.

I generally agree with you (which is why I made an exception for values with a manual Drop implementation), but to advocate on behalf of the idea… I don’t think it would be too crazy to make a rule that any function that invokes “unsafe” (or is itself defined as an unsafe function) would fall back to the old scope-based drop rules. Worst case scenario is that you’d be dealing with the current level of memory usage efficiency, and you might need to manually call drop if you want something dropped earlier, but in most cases things would be eagerly dropped even sooner.

Outside of uses of unsafe, are there any other serious problems with eagerly dropping values that manually implement Drop? Maybe this fallback mechanism would also have to be invoked simply for casting to a raw pointer anywhere in the function. Either way, a list of exceptions to eager drop would arguably be better than not having eager drop, as long as the list was sound.

It would still be a breaking change, and would definitely require at least being restricted to a new edition. Some people currently use Drop as a kind of scoped “defer”, especially for things like instrumentation, so maybe it would be time for the language to introduce a proper “defer” statement that exists for that purpose instead of making Drop so lazy for everyone.

I still don't get why one should do that in the first place

I’ve recently been writing personal code that leaks like a sieve. It’s just not worth my time to find every leak when the lifetime of the process is finite and short and it will only ever run on a machine with gigs of memory. I haven’t thought through your question enough but maybe a situation where memory usage would be super high if waiting until the end of scope? I’m probably trying to hard to come up with a situation but I have a gut feeling that freeing mid scope is important under certain circumstances to keep the code simple and understandable.

> I’m probably trying to hard to come up with a situation but I have a gut feeling that freeing mid scope is important under certain circumstances to keep the code simple and understandable.

I explained in my previous comment that you can explicitly "drop" any value at any time in Rust, if you choose.[0] But if you don't, it will still be dropped at the end of the scope. The developer has control, but the language will watch your back.

[0]: https://doc.rust-lang.org/std/mem/fn.drop.html

Heck, this is the entire memory management model of PHP, which I found shocking when I learned it, but makes sense given that the language is intended to generate web pages: just allocate, never reclaim the memory, then kill the process when you’re done.

Do you have any sources? Maybe some truly ancient version? PHP has done garbage collection (seemingly mixed with some reference counting, like Python) for at least 10 or 15 years... I didn't bother to keep searching for even older information, but nothing I saw indicated that PHP only released memory when the process for a request exited.

I don't even think most mainstream uses of PHP have done the process-per-request model for decades, but I could be wrong.

Correct, garbage collector was added to PHP 5.3, prior to 5.3 PHP did only reference counting. PHP 5.3 was released in June of 2009.

Here is a series of articles that describes it in detail

https://www.php.net/manual/en/features.gc.php

Especially look at this example where the same script is executed with and without GC

https://www.php.net/manual/en/features.gc.performance-consid...

Stacks are a fixed size. Unless you are running out of stack space there is no point in “freeing” memory from the stack. Where in the stack the stack pointer points has no bearing on stack size for any OS I’m aware of.

I’m assuming by string you mean a stack allocated array of char and not a std::string.

I meant a std::string on the stack, which is just a handle for more memory on the heap

This doesn't match the experience of GC'd languages. I've never heard of problems in practice that arose from treating all values present on the stack/registers as GC roots, even if those values are dead in the data flow sense.

You can just put a single pair of bracket around it and that’s it.

For locks it is seriously the best way to manage them.

The lifetime of the memory a smart pointer manages is very predictable. It will have the same lifetime as the smart pointer itself (this is ignoring moves).

I think what he's saying is there is a way to carelessly use smart pointers in rust.

pub enum List { Empty, Elem(i32, Box<List>), }

instead of :

pub struct List { head: Link, }

enum Link { Empty, Some(Box<Node>), }

struct Node { elem: i32, next: Link, }

Can you explain the difference between these approaches? Is it just that the first example allocates an extra u16 (tag of the tagged union) (ignoring any overhead)?

Notice that if I make this alleged "List" with a single data item in it, my data lives in the List object I just made (probably on the stack), but an empty List gets allocated on the heap.

I thought Aria's "Entirely Too Many Lists" tutorial actually tries to build this, but it actually doesn't, she draws you the resulting "list" and then is like, OK, that's clearly not what we want, let's build an actual (bad, slow, wasteful) linked list as our first attempt.

I don’t really get your example, or how does it have to do anything with rust? It’s just a bad linked list, isn’t it?

Are you talking about the example by RustyConsul? Because I'm not RustyConsul so I can't tell you what specifically RustyConsul intended with this example. Yes this is a bad data structure in Rust, or C, or presumably Zig. In the context of this thread I'm sure Zig's proponents will say that you'd never make this mistake in Zig.

My original point was referencing the use of smart pointers. They are indeed very smart, but can be used stupidly as a bandaid kind of like .clone().

The difference really lies in the fact that i now have some data stored on the stack (The element) and some data stored on the heap because it's recursive. Was just a random example of where it's poor practice. As others have noted, linkedlists are a terrible data structure to begin with.

And as we know from C, every developer is quite capable of taking care of use after free possible bugs.

The general purpose allocator in the zig standard library has protections against use after free bugs.

Just like C and C++ debugging allocators, so what is the improvement here?

By quarantining all memory forever. This is not a scalable solution because keeping one allocation in a 4kB page alive will leak the whole rest of the page. And if you don't quarantine all memory forever then use after free comes back. If it were that easy to solve UAF then C++ would have solved it by now.

There is a scalable solution for UAF that doesn't involve introducing a lifetime/region system: garbage collection. Of course, that comes with its own set of tradeoffs.

The problem of a single allocation keeping a 4 KB page alive is something that you might commonly find with the C++ or Rust way of programming that encourages allocating many individual objects on the heap, but in Zig land this is pretty rare. In fact, compare a Zig implementation of a given application with an equivalent in any other language and you will find there is no contest with respect to the size of the memory footprint.

There are many cool possibilities that C++ has never explored and frankly I find your argument unimaginative.

An allocator that can leak (4kB - epsilon) of memory for each allocation is broken. It's not a question of whether the language makes such allocations unusual: free() not actually allowing memory to be freed is a violation of the contract of a memory allocator.

From the man page (which I believe quotes ISO C): "The free() function shall cause the space pointed to by ptr to be deallocated; that is, made available for further allocation." If free doesn't do that because another allocation is pointing into that page, that's a violation of the contract. Standard quarantine doesn't violate the spec because the space will eventually become available no matter what, but perpetual quarantine does.

One way to fix the problem would be to round up all allocations to 4kB, but that's very wasteful and slow due to cache and page table traffic; you'd be better off from a performance point of view with a garbage collector. More promising is ARM MTE, though the tag is currently too small to really be called a solution to UAF as opposed to a mitigation. A 64-bit tag would be enough, but I'm not sure what the performance costs of that would be--I wouldn't be surprised if the increased memory traffic makes it slower than a GC.

> way of programming that encourages *allocating many individual objects* on the heap

Quoting and bolding. I think this is the thing that I need to change most about my own style of programming.

The point of C and Zig is that you can solve any kind of problems with them. In particular there is much more to memory reclamation than garbage collectors or Rust's borrow checker. Some of the reclamation schemes offer wait-freedom, or efficiently support linearizable operations.

Any kind of problem?

So how do you solve SIMD with C, without language extensions?

C is not a special snowflake.

Are there languages that "solve" SIMD?

ISPC for one.

https://ispc.github.io/

https://futhark-lang.org/

https://github.com/halide/Halide

SIMD is not a problem, it's hardware. Compilers tend to take advantage of the CPU-specific SIMD registers and instructions, or you can use them explicitly.

Writing generic SIMD code is more portable. C has libraries, and Zig also has vector primitives available through built-in functions.

Any language can have libraries, C is not special here, nor is Zig.

In fact, a few GC enabled languages have explicit SIMD support.

What can C and Zig do that Rust can't?

Nothing if unsafe Rust is considered, though Zig does not require you to fight the language nearly as much. This is especially obvious with embedded. Zig's philosophy of no hidden control flow or allocation makes things simple. Simplicity is power.

For certain problems you would want a TLA+ specification for safety and especially liveness either way. It's not like Rust absolutely guarantees correctness in all cases.

Rust sits in a sweet spot between C/Zig and languages like Java, but it's not an appropriate replacement for either of them.

Certainly Rust sits where C++ is. Zig and Rust are definitely best used for different things, but I think sweating rust off as in between C and Java is inaccurate.

This is kind of a trick question because they are all Turing Complete, but so is Assembly. The best way to interpret your question, then, is not “what is possible” but rather “what is simple to express correctly” and “what is simple to get correct eventually”. Those are questions about how tricky it is to get something to compile in the language and which tools exist to help determine whether a compiled program does what’s expected and does not do what’s not expected.

It wasn't a trick question. I'm not asking it in the same tone as someone would ask 'What can C do that Java can't?'.

I believe that Rust can be as low level as you want. If you have to fight the language to accomplish something, it's because you're probably trying to do something unsafe, and Rust will let you do that if you pay the price.

I was looking for examples of real cases where Zig is a better option than Rust. And while Zig is a lovely language, its main points against Rust are that it lets you do unsafe things more easily, and it's easier to learn.

Great, thanks for those details! I primarily develop using C++ and avoiding pitfalls (smart pointers, exceptions, unintended memory allocations) takes a lot of effort.

I enjoy synthesizers (including Eurorack) and looking forward playing with a Zig DAW!

Thanks for all the context. Curious to know more about the concept/design of the DAW.

Seconded.

Can you clarify about the union part? Did you meant that zig allowed you replacing what would be untagged union in C++ with tagged union in zig? Or does the zig compiler has some kind of debug sanitizer mode which automatically turns untagged unions into tagged unions with checks?

In the past they've talked about the speed and memory improvements they've gotten from using MultiArrayList in the compiler, storing tags separately from the unions themselves. If you have a union with a size of 16 bytes and you add a tag to that which is 1 byte, a lot of space is wasted due to padding. If you keep the tags in a separate array, both arrays are individually densely packed. Less memory wasted due to padding == less memory use overall and better utilization of cache.

But in terms of the implementation, this means working with untagged unions, because the tags are maintained externally.

In debug builds, untagged unions become tagged behind the scenes as you described.

If the union is untagged, how can it be determined (at runtime) that you've accessed the wrong field?

The compiler adds a tag in debug modes, but not in release modes.

Neat, that's somewhere in between a `union` and a `std::variant`. You could build your own, but it's cool that it's a first class member of the language.

> * a Digital Audio Workstation

Woah.

A little bit ago I went to write a little tool that mucked with the FL Studio FLP format. It was easy enough to guess out the bits that I cared about, so I pretty much just did that using a couple quick projects with specific things in them. However, I did check to see if anyone else had mucked around with the FLP format, and couldn’t help but notice your name. Was pretty surprised as a very curious onlooker to the Zig programming language. You certainly seem to get around :)

That’s a little tangential, but I guess I mention it because I was actually wondering if this was ever something you planned on doing given the fact that it was clear you had dabbled with DAW stuff (forgive me for not knowing if you have a more rich connection to music production than just that; I never bothered to check.)

A DAW in Zig sounds like a kick-ass idea. I tried to write a sort-of DAW toy with friends in Rust and it was a lot of fun even if it mostly made me realize how challenging it could be. (And also how bad at math I am. It took me so much effort to feel like I could understand FFTs enough to actually implement them.) It makes me wonder if your Zig DAW would be open source? It would be a fun project to attempt to contribute to, if or when it ever came to fruition.

Exciting stuff. Congrats on the Zig milestone.

> It took me so much effort to feel like I could understand FFTs enough to actually implement them.)

Do you understand how little DSP is involved in writing a DAW? It has almost nothing to do with DSP and everything to do with application architecture, data management, threading and more.

I think you may be reading too much into what I said; I was working on a DAW-like toy, not a full DAW that uses VST plugins, and because I chose to write DSP code, I had to understand it. I don’t know what a real DAW looks like because I am not a subject expert.

That said, Rust seemed pretty promising for writing the audio engine of a DAW due to the memory ownership model. It was relatively easy to come up with a way to architect a very basic lock-free audio thread and feel sure that it was at least memory correct. I have no idea how a real DAW avoids certain pitfalls in the audio thread; lock-free isn’t too hard, but avoiding allocations in all circumstances seems tricky.

Most DAWs do not avoid locks in RT context.

Take a listen to my interview with Justin Frankel of Reaper - somehow in our 3hr+ epic chat, he acknowledges that they don't avoid locks entirely. And Ardour, despite trying, also fails to do so. Anecdotally, from my conversations with other DAW developers, they also do no manage it 100%. As Justin put it, it's more about contention avoidance than lock avoidance.

Avoiding actual stack-based allocation is pretty easy in C++. You just have to want to do it, and remember to do it.

Memory correctness is really easy in the RT threads of a DAW precisely because they do (should) not allocate. You're dealing with pre-allocated memory blocks that do not change over time. It's almost the simplest case of memory mgmt that I know of within a DAW. I have seen several new-to-DAW developers adopting ill-advised schemes for memory mgmt in an RT context. The "list of blocks" is one pattern that I consider something to avoid (and unnecessady). Single-reader/single-writer lock-free (circular) FIFOs get you almost all the way there, for everything.

Interesting. I actually thought this was the case, but when I made a similar argument in a chatroom I got pretty severely roasted by people who were sure real audio engines never used locks in the audio thread. It seems like whichever way I go I’m wrong with audio :P but that’s OK, because I really am not pretending to be knowledgable here, for me it was only ever for fun.

The main reason I felt Rust was nice was simply the re-assurance that I could not, even if I wanted to, accidentally cause a data race within the confines of safe Rust. It’s not that the actual code was hard, but it did force me to ensure that what I was doing with the data model was actually safe. It wound up guiding how data flow worked in the playback engine.

Anyway, thanks for the pointer to the interview. I don’t expect myself to be writing the next Reaper or Ardour so it is probably OK if I don’t quite grok what you’re getting at. But, I do find this stuff rather interesting, so I would love to have a listen when I get a chance.

It's a fun exercise to implement FFT and other DSP algorithms, but for real-world software please stick to true and tested libraries like FFTW or FFTPACK instead of your own naïve implementation.

I feel like there’s some kind of PTSD in the audio field. I was only talking about a fun toy project among friends and I already have two replies critiquing it presumably by subject matter experts. Just an observation, I’m not really that sore over it. But still, even with cryptography, where it is well-known you never roll your own code (and yet people do anyways) I would not expect people to get all flustered if I had said “toy EC-SRP implementation” because the word “toy” is meant to signify “I know that’s not what you would do in the real world.”

Impressive work getting Zig self-hosting. However:

> As for less memory, I think this is simply a clear win for Zig. No other modern languages compete with the tiny memory footprints of Zig software.

Is not true at all. There are several other modern languages that compete with Zig for small memory footprints.

Would you tell about those languages or they are left as an exercise to readers?

Sort of left it to the readers and hopefully encourage people to investigate for themselves. It's far too easy to get into "this benchmark vs this benchmark", etc. Memory usage is overall a complicated topic, which I think Andrew's comment doesn't do justice to. Granted the Zig team has done some impressive work, much of the memory usage & bloat in the C++ world comes from real world programs and libraries and the inevitable drift in program architecture over time.

However, I could believe Zig's stdlib and culture encourages low memory footprints, but there isn't anything novel in the language that makes it inherently lower memory footprint. Though to name a few languages I'd say that can be directly comparable are Rust, D (esp. BetterC mode), and Nim. Even Julia & Go in the right context. Though honestly I often prefer wasting a few hundred bytes of RAM here and there, even on a microcontroller, for pure convenience.

edit: forgot Odin. Another comment mentioned it, though I've never used it. It looks like it's used in production.

Zig has a few extra tricks up their sleeves compared to most languages. The ones that come to mind are

* MultiArrayList

* arbitrary size-integers that make it easy to pack data very tightly

* easy access to several special purpose allocators which reduce the need for strategies like reference counting

Perhaps, though nothing there that's not been available for a while. To be fair Zig has integrated some of these features well.

* MultiArrayList is convenient and easy to do in Rust, D, Nim. Odin seems built around it. * Arbitrary bit-size integers seem more gimmicky than anything and similar to struct bitfields in other languages (except Rust oddly). Most compilers don't even pack uint8/uint16's for performance reasons. * Special purpose allocators are a bit more interesting. Still they don't provide actual memory safety AFAICT and can have fragmentation and performance penalties.

It'll be interesting to see larger Zig code bases emerge in different fields and see how the memory footprint compares in practice.

What? 8- and 16-bit are never 32-bit aligned nor sized.

To clarify I meant comparing how int8/int16's are packed in structs vs struct bitfields. Can't recall about the stack rules. Here's more discussion:

http://www.catb.org/esr/structure-packing/

https://github.com/Twon/Alignment/blob/master/docs/alignment...

Also ARM for example doesn't have 8/16 bit registers so int8 or int16 will use a 32bit register:

https://stackoverflow.com/a/23716920

Curiosity got to me, perhaps Zig had improved significantly. So I compared the first benchmark I found (kostya/benchmarks/bf) with Zig with Nim. For the smaller input (bench.b) Zig did run with ~22% less RAM (about 20kB less).

However, for the larger input (mandel.b) Nim+ARC used ~33% less RAM in safe mode: Nim 2.163mb -d:release; Zig 2.884mb -O ReleaseSafe; Zig 2.687mb -O ReleaseFast. The Nim requires 0.5mb less ram and the code is ~40% shorter. I don't have time to try out the Rust or Go versions though.

edit: grammar

Are the two using the exact same algorithm?

Yes, as far as I can tell [1]. It's a simple Tape algorithm. Neither had any crazy SIMD, threads, no custom containers, etc. They use almost the same function names (and look the same as the Go version too). I used `time -l` https://stackoverflow.com/a/30124747 for memory usage.

Note I ran the benchmarks locally (MacBook Air M1) because the reported benchmark uses the older (default) Nim GC while I only use Nim+ARC. I also had to fix the Zig code and it took a few tries to get the signed/unsigned int conversions working. I tried tweaking flags for both a bit as well to see how stable they were. Zig's memory usage was pretty constant. Nim had a small speed vs memory tradeoff that could be tweak-able, but the defaults used the least memory.

Overall I'd expect exact memory usage by language(s) to vary some by benchmark and one random benchmark isn't conclusive. Still I didn't find anything to indicate Zig is clearly better than other new generation languages. Manual memory management might actually be worse than letting a compiler manage it in some cases.

1: https://github.com/kostya/benchmarks/tree/master/brainfuck

Odin doesn't work on 32-bit ARM, which was a disappointment to me.

Bummer, looks like an intriguing language.

In that category (of C/C++ alternatives) is also Vlang (https://vlang.io/). It would be closer to Odin, than Julia, Go, or Nim. Although Vlang and Odin have a strong Go influence.

> * a Digital Audio Workstation

ORLY?

Maybe you can put together a better, faster team (like Presonus managed to do for Studio One), but most current DAWs have been in existence for 20 years or more. Catching up with that is a challenge, and if you don't catch up then it's an interesting toy or half-a-DAW.

So why?

ps. obviously I am biased.

This argument applies equally to programming languages, and Zig seemed to go OK?

Oh yes, it absolutely applies to all programming languages.

> written in Zig instead of C++, uses significantly less memory, and represents a modest performance improvement

That's particularly interesting considering the rust compiler in rust has never been as fast as the original OCaml one

Well, OCaml Rust compiler also didn't use LLVM and used its own lightweight code generator and I think self-hosted Rust compiler frontend was in fact faster than OCaml Rust compiler frontend.

With both projects, how much of the improvement is simply building for the second time?

For Rust, I think improvement was almost entirely due to LLVM producing faster code. That's not applicable to Zig case, since both old and new compiler use LLVM. I don't know enough about Zig to answer.

I wonder how much this statement still holds. I've never used the OCaml bootstrap compiler but performance wise, the rust compiler has improved incredibly since the 1.0 release.

An apple to apple comparison is impossible because rustboot compiled a very different language. But I suspect suitably updated rustboot would be still faster because compilation time is dominated by LLVM.

Rustboot's code generator was generally slower than LLVM. I think in some small test cases it might have been faster, but when implementing stuff like structure copies rustboot's codegen was horrendously slow because it would overload the register allocator.

The original OCaml compiler didn't have essentially any of the static analysis that Rust would eventually be known for. Rust in 2011 (when rustc bootstrapped) was dramatically different from what would later stabilize in 2015.

Huh? That's not true at all. It took over 30 minutes to compile the self-hosted Rust compiler with the OCaml compiler, when rustc was far smaller than it is today. rustboot was agonizingly slow, and one of the main reasons why I was so anxious to switch to rustc back in those days was compilation speed.

I was there and had to suffer through this more than virtually anyone else :)

My source: https://pingcap.com/blog/rust-compilation-model-calamity#boo...

> 7 femto-bunnies - rustboot building Rust prior to being retired

> 49 kilo-hamsters - rustc building Rust immediately after rustboot's retirement

> 188 giga-sloths - rustc building Rust in 2020

> uses significantly less memory, and represents a modest performance improvement.

The reduced memory has significant value. Being able to do the same build on less expensive hardware or do more with the same hardware is a significant financial performance improvement

yup 18x memory reduction improvement 8.5GB -> 0.5GB according to the vid..

Happy to see the C backend coming along. LLVM is a major barrier to use on esoteric embedded devices.

You can also target C through Wasm.

https://github.com/WebAssembly/wabt/tree/main/wasm2c

My genuine question is what sort of code-size and/or performance impact the translation imposes.

The simple example in the README.md seems straightforward enough, but I wonder if there are any pathological explosions in practice.

That would be an interesting undergraduate paper. Perf, Size, by primary language, by toolchain, linker, post processor (dead code elimination, etc).

For a pathological explosion, you mean something like a Zip Bomb? Wasm and C are pretty close together in their semantics, Wasm hides the stack and prevents jumping into the middle of a function (CFI, Control Flow Integrity). I think the code bloat should be on the order of some multiple of the smallest interpreter.

I just did a quick scan of Wasm interpreters (3 in Rust, 1 in C)

    yblein/rust-wasm ~4kloc
    rhysd/wain ~16kloc
    paritytech/wasmi ~25kloc
    wasm3/wasm3 ~22kloc (C)

My hunch is that the expanded code would be approximately (2x-5x interpreter + bin.wasm). I just did a spot check with doom.wasm, I am wrong. The resulting expanded C code when compiled to Arm is 2x the wasm binary size.

    4.1M wasidoom.o
    1.8M wasidoom.wasm

https://en.wikipedia.org/wiki/Zip_bomb

* What kind of tests are these "behavior test"?

* Is that a list of compilation targets?

* If not all behavior tests pass, does that not mean that the compiler fails to compile programs correctly?

Please indulge those of us who are not familiar with self-hosting compiler engineering.

> What kind of tests are these "behavior test"?

Snippets of zig code that use language features and then make sure those features did the right thing. You can find them here: https://github.com/ziglang/zig/tree/master/test/behavior

> Is that a list of compilation targets?

Mostly. Pedantically, it's a list of code generation backends, each of which may have multiple compilation targets. So for example the LLVM backend can target many architectures. The ones that are architecture specific are currently debug-only and cannot do optimization.

> If not all behavior tests pass, does that not mean that the compiler fails to compile programs correctly?

Some tests are not passing because they cause an incorrect compile error, others compile but have incorrect behavior (miscompilation). Don't use Zig in production yet ;)

(edit: fix formatting)

To add to what Spex said: also some of those tests check language features that the compiler code doesn't exercise, like async/await. This means that the compiler is able to build itself, but is not able to build every possible valid Zig program. We're getting there though :^)

it's so surprising to hear there was a Zig Meetup in Milan, I'd not expect a large enough community to exist there, pretty cool!

Probably a significant chunk of the larger European community was represented there too - don't forget that traveling to EU countries is relatively easy for EU citizens

Congratulations!

Reply on news.ycombinator.com