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 (although I've heard whispers that eventually they plan to reduce the size of the standard library, which I'd personally find sad). defer is awesome. comptime too.<p>I haven't noticed miscompilation yet but I have noticed occasional unclear error messages such as it pointing at the wrong line. I've meant to make a note of these but since I'm just focused on learning I haven't done a great job of writing down these minor bugs.<p>I don't think the breaking changes (which haven't seemed that big) are a huge deal for most folks curious about PL in general. And I think the potential for being a better C is just so great that it's worth continuing to try out Zig and follow it's development. In particular I think it would make a lot of sense as a teaching language for the college courses that would otherwise use C. And I think it would be a pretty fancy compilation target for language implementations like Chicken Scheme that otherwise target C. (I'm sure it would be great in other situations too but these two are ones I can relate to most.)<p>But I'm still early on in my exploration of Zig. (Disclaimer: the company I work for uses Zig and sponsors ZSF.)
Correctness please.
Zig is a way too simple language to justify all the really easy to hit bugs.<p>I'd give everything for a zig compiler that's 10 times as slow but actually compiles my code.<p>Also testing infrastructure. Zig really needs fuzzing and property testing tooling build-in. Hitting stage 2 with arbitrary autogenerated zig code and IR, would have really helped detect regressions for example.
I watched the linked talk by Andrew Kelly - super interesting stuff. I've played a bit with data oriented design in the context of implementing an ECS, but some of the topics he discusses take it to another level entirely, and it's very cool to see it applied, with measurable results, in a large serious project like a compiler.<p>I have a lot of admiration for Zig, as I think it takes a very interesting approach to being a "better C", and the no-nonsense approach, ruthless simplicity, and thin abstraction over the hardware fall very much in line with my values as a programmer.<p>As a product manager, a few thoughts ran through my head when when I was watching this: with where Zig is as a language, is this kind of focus on extreme memory optimization actually the best use of his time?<p>There's an argument that it might be: maybe this is an exercise in dogfooding Zig as the kind of language which is suitable for data oriented design. Or it could be Kelly has fallen victim to the temptation many of us do, in following the most fascinating path rather than the one that's creating the most long lasting value.<p>Either way I guess that's a luxury he has the right to indulge as an independently funded auteur PL designer.
Congrats, fast compile speed is a requirement nowadays, any language that is slow to compile puts you at a risk of not being able to fix important prod issues quick enough, hence why i use Go for my backend, i can't imagine using anything else<p>Tests, deployment, up to restarting the service in prod, the language should empower me to not loose time<p>I'm not talking about memory bugs, i'm talking about typo issues, API issues, comment/uncomment, renaming, missing a semicolon (that one should go imo), refactoring etc, a fast compiler allows me to be more productive<p>Having to recompile due to typos is the main contributor of wasting my time, if it takes 10+ seconds, then the language sucks, it should be instant up to 1 second<p>Glad that you understand that and you made sure you built the foundation that enables it, that's game changer
> We are also working on a special backend, one that produces C source code. Progress on the C backend has recently shot forward (87% and counting) thanks to an amazing recent contribution.<p>I love this. It's great story for people who want to develop in a newer language while having seamless interoperability into older toolchains and ecosystems (eg. TS/JS). If it reaches production quality, that will be a large selling point for Zig IMHO.
I always enjoy reading about Zig advancements. I haven't developed anything substantial in Zig yet, but I'm very optimistic about the future of the language.<p>If you're curious to see a large Zig codebase, two significant projects are Bun [1] and TigerBeetle [2].<p>[1] <a href="https://github.com/oven-sh/bun" rel="nofollow">https://github.com/oven-sh/bun</a><p>[2] <a href="https://github.com/tigerbeetledb/tigerbeetle" rel="nofollow">https://github.com/tigerbeetledb/tigerbeetle</a>
Nice achievement.<p>Curious about this though:<p>> building the compiler itself used to require 9.6GB of RAM, while now it takes 2.8GB.<p>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.
Congrats Zig Team!<p>Allow me to comment from my professional perspective:<p>I have been working deep inside the spaghetti-stuffed soft underbelly of the computational infrastructures of multitudes of international “Big Science” projects and consortia.
Zig seems like a very, very good fit.
Are there any static code analysis tools that support it?
Such functionality would be a killer app…<p>Wild idea: what about building one inside Zig?
(or repurpose some other external tool to eventually integrate / be a “companion” tool and perform static analysis seamlessly)<p>PS: Of course with C support from the get go - maybe additionally other languages.
To all people complaining about bugs:
1. It's easy to find flaws in hard, ambitious projects. All ambitious projects start out as WIPs.
2. It is much harder to do an ambitious project.<p>Try to be in the 2nd group.
> The package manager will not assume the presence of a central package index. We don’t plan to create an official package index.<p>This is great to hear!
> What’s interesting about this [C] backend is that it will play a role in our plan to replace the old bootstrap compiler implementation<p>That's super neat. I'm guessing the plan is to generate stage1 during CI or something with this backend?
I wonder if Zig is getting too much hype at the moment considering its immaturity (and so many easy to hit bugs as noted by other commenters). Is it getting hype before it's ready? Will it be able to recover from that?
What is the reason to not have a central package index? I find that having one speeds up my development significantly. Is there more reason than decentralization?
Write a "Zig in Y minutes", to me a language doesn't exist if it's not there.<p>Add vector math types/functions/operators, those should be standard, in my view.
Zig seems to have captured a lot of attention in the new language design space, and I personally find this unfortunate. Frankly, I find it irresponsible that the team has marketed a pre 1.0 language so heavily. By constantly evolving the language and making frequent breaking changes, they are quite literally wasting people's time. They also have been very hostile to people who have raised fair points about the misleading claims that they have made.<p>From my perspective, the entire premise of the language is flawed. The main project goal seems to be to become a replacement for c. This means that in some sense the project is implicitly defined by c and doesn't really stand on its own conceptually. This could be ok if it actually fixed some of the worst problems with c, but most of what it offers appears to be relatively superficial syntactic improvements (which could easily be implemented by a simple transpiler to c). While I am sure that the language designers see things differently, it appears that Zig just lets c programmers keep writing c with some additional compiler checks. This is probably an improvement on c (at least in some respects), but it seems largely incremental. Also because they prematurely evangelized the language, they are likely to be weighed down by the additional complexity that seeped in from trying to support so many different use cases before they had really figured out what the language is.<p>That it took two years to write the self hosting compiler speaks to the fact that this language is already quite complex. My guess is that this complexity is always going to pose problems. Downstream users are always going to be finding obscure edge cases that don't work because the language supports so many different things that actually testing everything is going to be extremely difficult.<p>Having said all that, if you love Zig, that's great. I don't doubt that it offers some real quality of life improvements for you. I just personally believe that this project is an evolutionary dead end and that it is very unlikely to have significant mindshare/deployment in say, 10-20 years.