121–130 of 159 posts
Nice achievement. Curious about this though: > building the compiler itself used to require 9.6GB of RAM, while now it takes 2.8GB. Why is the RAM usage so high? It was only a few years back and we were building C++ compilers on machines with barely 16MB.
When Golang switched to a self-hosted compiler, it lost compilation speed. When Zig switched to a self-hosted compiler, it gained compilation speed.
Earlier quoted context omitted.
How is calling non-async functions via @asyncCall insufficient?
@asyncCall is exactly the sort of thing the original function colors calls out.
Earlier quoted context omitted.
Going by your own comment, you seem to not be an "early enough" adopter. That's totally fair, maybe Zig will be more interesting for you once it stabilizes more in the future.
I don’t believe this to be true. Zig is 6 years old now going by Wikipedia. In comparison I use Rust in an more extensive way than Zig for almost 20 years now. I for sure wrote more Rust in 2012 when it was ~2 years? old than Zig last year, yet I don’t remember miscompilations on that level. The same is true for my recollection of using very early D which however at this point was in an earlier life of mine and very…
Earlier quoted context omitted.
Well, while you are developing a language, in particular a system programming language like zig, having to write your compiler in zig is a great way to learn first hand what your users are complaining about. Normally if you dogfood your own creations, you experience them maybe an hour a day, but the compiler will be the number one tool when working on zig.
As a compiler engineer myself, I dislike dogfooding in the compiler itself. It biases us to design the language for the compiler use case, and that is in fact a very niche use case. I much prefer having a side project that uses the language I'm implementing, instead of using it to implement the compiler itself.
Earlier quoted context omitted.
Hey, back in the day, I used a Pascal compiler on CP/M that worked with 64K.
Compilers like that would go directly from text -> machine instructions, step by step (or to very close approximation) because that is all you had the time and memory for. Modern compilers lex then parse into tree structures and then do lots of mutations and traversals of that tree to optimize in different ways for different architectures, and more code is included at once to make more optimizations possible and on a…
https://en.wikipedia.org/wiki/PL/8
Or like the 1980s?
When Golang switched to a self-hosted compiler, it lost compilation speed. When Zig switched to a self-hosted compiler, it gained compilation speed.
Later versions of the compiler improved on the performance side as they then started to improve on the compiler's backend.
Earlier quoted context omitted.
Disclaimer: Not a Zig fan. I think Zig is getting too much hype. It's unfortunate because Zig could have potential, but hyping something before it's ready is a recipe for alienating early adopters and killing progress towards popularity. The worst part of it is that I've heard people say that they've got Zig in production; with all of the bugs in the compiler, they are apt to get burned, and too many burns will lead…
How would you expect a language as low-level as Zig is to support colorless async? It pretty much requires some kind of green threads.
I've been learning Zig by porting my toy SQL database in Go to Zig (both projects are on Github, you can go find them if you'd like). This is my first time trying to seriously use a non-GC language for a project, so there's a big learning curve unrelated to Zig in particular. However, it's much easier than trying to learn C (which I've tried a few times). The standard library is incredibly feature rich compared to C…
The problem is getting the wider market to pick better C languages.