14 ms·

Zig Is Self-Hosted Now, What's Next?

303 points by kristoff_it 4y ago

jokoon 4y ago
Write a "Zig in Y minutes", to me a language doesn't exist if it's not there. Add vector math types/functions/operators, those should be standard, in my view.
- kristoff_it 4y ago
  Then Zig is indeed real :^) https://gist.github.com/ityonemo/769532c2017ed9143f3571e5ac104e50 https://gist.github.com/ityonemo/769532c2017ed9143f3571e5ac1...
- anonymoushn 4y ago
  What do you mean by vector math types/functions/operators? There's built-in SIMD stuff but that may not be the right thing.
zamalek 4y ago
> What’s interesting about this [C] backend is that it will play a role in our plan to replace the old bootstrap compiler implementation That's super neat. I'm guessing the plan is to generate stage1 during CI or something with this backend?
richardanaya 4y ago
It would be nice to have a public Zig webassembly compiler that anyone could import and use.
DrBazza 4y ago
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.
- tomcam 4y ago
  And by “a few years” you mean a generation
- chubot 4y ago
  Yeah that is interesting ... I guess it's because Zig compilation is single-process, parallel, and threaded, not like the C++ compilation model of separate processes? I never tried, but I highly doubt either gcc or Clang could be built with 16 MB of RAM, even serially, at any point in the last 10 years. Probably not even 20 years, though I could be wrong
  - tredre3 4y ago
    > I never tried, but I highly doubt either gcc or Clang could be built with 16 MB of RAM, even serially, at any point in the last 10 years. Probably not even 20 years, though I could be wrong Last week I tried to compile GCC on a machine with 8GB of ram (no swap). Compilation failed, I add to upgrade to 16GB. I think the last time gcc could build with 16MB was last century.
- aidenn0 4y ago
  I don't know about Zig specifically, but things using LLVM tend to be absurd memory hogs. I remember having to disable parallel compilation for clang to prevent OOM issues.
  - UncleOxidant 4y ago
    Yeah, 9.6GB of RAM seems like a really small number when you're talking about LLVM.
- garyrob 4y ago
  Hey, back in the day, I used a Pascal compiler on CP/M that worked with 64K.
  - jackmott42 4y ago
    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 and on and on.
j-pb 4y ago
Correctness please. Zig is a way too simple language to justify all the really easy to hit bugs. I'd give everything for a zig compiler that's 10 times as slow but actually compiles my code. 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.
- dist1ll 4y ago
  I'm not so familiar with Zig, are you saying that the compiler fails to compile correct (i.e. according to spec) code?
  - j-pb 4y ago
    Yeah, theres a surprising amount of stuff that's buggy, think `if` or `recursive structs with pointers` level stuff.
    - mattgreenrocks 4y ago
      Can you substantiate this further? I don't see how basic stuff like that could be subtly buggy, the Zig devs are very qualified IMO.
      - mirashii 4y ago
        Here's a pretty substantial bug from just a week ago: https://github.com/ziglang/zig/issues/13211 https://github.com/ziglang/zig/issues/13211
        singularity2001 4y ago
        "stage1 is expected to be broken in many ways and does not handle non-x86_64 C ABI at all." so its self-hosted for x86_64 only so far, which is fine if communicated
moffkalast 4y ago
- butterisgood 4y ago
  Well played!
- Soulsbane 4y ago
  zug zug
butterisgood 4y ago
Port to 9front!
deleted 4y ago
[deleted]
david2ndaccount 4y ago
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?
- ksec 4y ago
  Compared to Rust at this stage of its development? No, Rust was far more popular. If you search headline with Zig which reached HN front page, you will only see about 1 - 2 per month. Compared that to Rust, which isn't even as popular as it once was. But still, I do wish the Zig community could quiet down a little bit. It would be nice if decent zig submission hit HN front page once every two months. Keeping the interest alive but not too much so people felt it is over hyped. We will have a November Release soon and I can guarantee it will hit HN front page again.
- ghoward 4y ago
  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 to putting out the fire and rewriting. It doesn't help that (in my opinion) there is confusion regarding basic things about Zig. [1] [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
  - nyberg 4y ago
    A number of those using zig in production have played with zig for a considerable amount of time (I started playing with 0.5.0 where large breaking changes came shortly after) thus know what to expect. Afaik most of those are within embedded, using it as a toolchain (zig cc not zig), or have similar constraints.
  - kbd 4y ago
    Ugh that "Zig has function coloring" post again. The misunderstanding that post makes is that function coloring refers to at compile time. In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context. Obviously the functions will have different runtime representations, so if you do something that cares about runtime calling conventions or w/e then yes you do need to worry about how the function is used, which is unavoidable.
raoulj 4y ago
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?
- skybrian 4y ago
  I don't know but hopefully there would be something like Go's module proxy, which can be replaced or turned off. https://proxy.golang.org/ https://proxy.golang.org/
- bsder 4y ago
  Decentralization is good. I'm really not a fan of what has happened in the Rust community with crates. The fact that there is a single blessed Rust crate source and the fact that the Rust community doesn't take responsibility for vetting crates means that maintainership changes, name squatting gold rush, and a whole host of pathological behaviors show up. If you're not going to take responsibility, then the only option is to leave everything decentralized.
thefaux 4y ago
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. 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. 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. 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.
- flohofwoe 4y ago
  Why do you care so much about a language you have no interest in? Just ignore it and move on, there's plenty of programming languages under the sky to have fun with and which probably fit your idea of a good programming language much better than Zig.
eatonphil 4y ago
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. 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. 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.) But I'm still early on in my exploration of Zig. (Disclaimer: the company I work for uses Zig and sponsors ZSF.)
- pjmlp 4y ago
  Being a better C is not hard to achieve as goal, JOVIAL, NEWP and PL/I did it one decade before C was born, and Modula-2 did it while C was mostly a Bell Labs toy, back in 1978. The problem is getting the wider market to pick better C languages.
  - eatonphil 4y ago
    I agree! I think the Zig community is doing a better job marketing than most better-c languages (which saddens me in some respects because I like D too, but sometimes you go with what meets most criteria and seems like it will succeed with adoption!).
- jpe90 4y ago
  I started trying to learn Zig as my first non-GC language but switched over to C because I had trouble finding learning resources for Zig, while there are plenty of books and C code written to ISO standards to learn from. It felt like a language for people already proficient in C/C++ and systems programming.. but props to you for proving that wrong!
2pEXgD0fZ5cF 4y ago
> The package manager will not assume the presence of a central package index. We don’t plan to create an official package index. This is great to hear!
sitkack 4y ago
I hope Zig continues to ship clang, because Zig is the easiest way to install clang.
- SoraNoTenshi 4y ago
  If i am not mistaken, that's one of the larger selling points in Favour of Zig, isn't it? I am pretty sure the C/C++ capabilities will stay in the Zig toolchain for a very long time :)
- int_19h 4y ago
  And to build C and C++ projects! https://kristoff.it/blog/maintain-it-with-zig/ https://kristoff.it/blog/maintain-it-with-zig/
skohan 4y ago
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. 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. 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? 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. Either way I guess that's a luxury he has the right to indulge as an independently funded auteur PL designer.
- kristoff_it 4y ago
  The choice of improving the performance of the compiler before working on the package manager was deliberate. With the new compiler you will be able to have plenty of dependencies and compilation times / memory usage will remain reasonable. The same could not be said of the bootstrap compiler. For us compilation speed is part of the main value offering of Zig.
  - anonymoushn 4y ago
    Is this working? stage2 seems to take similar and large amounts of time to compile a non-async-using program from our project with no caches and with caches after a whitespace change.
    - cturtle 4y ago
      The linked post mentioned that the compiler itself does compile faster, but not by much. Memory usage is the greatest impact of stage2. The speed will come when the native backends are finished. Right now the compile time is mostly llvm. The idea is a native and fast backend for debug (development) builds, and llvm for optimized releases.
Kukumber 4y ago
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 Tests, deployment, up to restarting the service in prod, the language should empower me to not loose time 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 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 Glad that you understand that and you made sure you built the foundation that enables it, that's game changer
- lacasito25 4y ago
  Single biggest reason I don't start new rust projects
haberman 4y ago
> 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. 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.
DrNosferatu 4y ago
Congrats Zig Team! Allow me to comment from my professional perspective: 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… 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) PS: Of course with C support from the get go - maybe additionally other languages.
- throwawaymaths 4y ago
  It would be awesome if zig implemented compiler hooks, for example: shoot off messages at various stages (sema of files, zir on individual functions, linker events), with some sort of defined binary structure (ok if it's defined in zig itself!) at say a tcp port.
  - flavious 4y ago
    Yes, that would be amazing, full classes of approaches to problem solving would be unlocked at once and we wouldn't have to invent new languages, DSLs, transpilers, etc, but just leverage zig.
_7bxa 4y ago
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. Try to be in the 2nd group.
- Tozen 4y ago
  But here's the thing about that though, when it comes to other languages which are not 1.0, various people will bash and troll to no end about any flaw, bug, or mistake they can find. Hell, even smear the developers at will. How many times have we seen people dogging the hell out of Jai, Odin, Vlang, Carbon (that just started), and other newbies? People will dog other languages out and even compare them to 10 year old or older languages, without blinking.
- the_mitsuhiko 4y ago
  Zig is not the first new language I try. I was an excited early adopted of a lot of many languages including D, Go, Rust and TypeScript. At no point to I remember running into miscompilations on rather fundamental issues and so quickly. So I do think this is quite out of the ordinary.
  - sullyj3 4y ago
    Consulting Wikipedia's "first appeared" field for each: D: 8 December 2001; 20 years ago Go: November 10, 2009; 12 years ago Rust: July 7, 2010; 12 years ago TypeScript: 1 October 2012; 10 years ago Zig: 8 February 2016; 6 years ago The only one of these which isn't at least twice as old as Zig is TypeScript, which has the might of Microsoft behind it, and is based on a well understood, pre-existing language. This is not a fair comparison.
    - Tozen 4y ago
      However, when it comes to comparing just as old or even newer languages than Zig, such as Odin, Jai, Vlang, Carbon, etc... Various people have no mercy whatsoever.
    - 4y ago
1vuio0pswjnm7 4y ago
When Golang switched to a self-hosted compiler, it lost compilation speed. When Zig switched to a self-hosted compiler, it gained compilation speed.
- tapirl 4y ago
  It is reasonable. For Go case, Go is slower than C. For Zig case, zig is not slower than C++.
- pjmlp 4y ago
  Because they weren't focused on performance, rather correctness. Later versions of the compiler improved on the performance side as they then started to improve on the compiler's backend.
rychco 4y ago
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. If you're curious to see a large Zig codebase, two significant projects are Bun [1] and TigerBeetle [2]. [1] https://github.com/oven-sh/bun https://github.com/oven-sh/bun [2] https://github.com/tigerbeetledb/tigerbeetle https://github.com/tigerbeetledb/tigerbeetle
- _vvhw 4y ago
  Joran from TigerBeetle here! Awesome to hear that you're excited about Zig. Thanks for sharing the link to our repo also—would love to take you on a 1-on-1 tour of the codebase sometime if you'd be up for that!

303 points by kristoff_it 4y ago

Write a "Zig in Y minutes", to me a language doesn't exist if it's not there. Add vector math types/functions/operators, those should be standard, in my view.

kristoff_it 4y ago
Then Zig is indeed real :^) https://gist.github.com/ityonemo/769532c2017ed9143f3571e5ac104e50 https://gist.github.com/ityonemo/769532c2017ed9143f3571e5ac1...
anonymoushn 4y ago
What do you mean by vector math types/functions/operators? There's built-in SIMD stuff but that may not be the right thing.

zamalek 4y ago

> What’s interesting about this [C] backend is that it will play a role in our plan to replace the old bootstrap compiler implementation That's super neat. I'm guessing the plan is to generate stage1 during CI or something with this backend?

richardanaya 4y ago

It would be nice to have a public Zig webassembly compiler that anyone could import and use.

DrBazza 4y ago

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.

tomcam 4y ago
And by “a few years” you mean a generation
chubot 4y ago
Yeah that is interesting ... I guess it's because Zig compilation is single-process, parallel, and threaded, not like the C++ compilation model of separate processes? I never tried, but I highly doubt either gcc or Clang could be built with 16 MB of RAM, even serially, at any point in the last 10 years. Probably not even 20 years, though I could be wrong
- tredre3 4y ago
  > I never tried, but I highly doubt either gcc or Clang could be built with 16 MB of RAM, even serially, at any point in the last 10 years. Probably not even 20 years, though I could be wrong Last week I tried to compile GCC on a machine with 8GB of ram (no swap). Compilation failed, I add to upgrade to 16GB. I think the last time gcc could build with 16MB was last century.
aidenn0 4y ago
I don't know about Zig specifically, but things using LLVM tend to be absurd memory hogs. I remember having to disable parallel compilation for clang to prevent OOM issues.
- UncleOxidant 4y ago
  Yeah, 9.6GB of RAM seems like a really small number when you're talking about LLVM.
garyrob 4y ago
Hey, back in the day, I used a Pascal compiler on CP/M that worked with 64K.
- jackmott42 4y ago
  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 and on and on.

j-pb 4y ago

Correctness please. Zig is a way too simple language to justify all the really easy to hit bugs. I'd give everything for a zig compiler that's 10 times as slow but actually compiles my code. 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.

dist1ll 4y ago
I'm not so familiar with Zig, are you saying that the compiler fails to compile correct (i.e. according to spec) code?
- j-pb 4y ago
  Yeah, theres a surprising amount of stuff that's buggy, think `if` or `recursive structs with pointers` level stuff.
  - mattgreenrocks 4y ago
    Can you substantiate this further? I don't see how basic stuff like that could be subtly buggy, the Zig devs are very qualified IMO.
    - mirashii 4y ago
      Here's a pretty substantial bug from just a week ago: https://github.com/ziglang/zig/issues/13211 https://github.com/ziglang/zig/issues/13211
      - singularity2001 4y ago
        "stage1 is expected to be broken in many ways and does not handle non-x86_64 C ABI at all." so its self-hosted for x86_64 only so far, which is fine if communicated

moffkalast 4y ago

butterisgood 4y ago
Well played!
Soulsbane 4y ago
zug zug

butterisgood 4y ago

Port to 9front!

deleted 4y ago

[deleted]

david2ndaccount 4y ago

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?

ksec 4y ago
Compared to Rust at this stage of its development? No, Rust was far more popular. If you search headline with Zig which reached HN front page, you will only see about 1 - 2 per month. Compared that to Rust, which isn't even as popular as it once was. But still, I do wish the Zig community could quiet down a little bit. It would be nice if decent zig submission hit HN front page once every two months. Keeping the interest alive but not too much so people felt it is over hyped. We will have a November Release soon and I can guarantee it will hit HN front page again.
ghoward 4y ago
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 to putting out the fire and rewriting. It doesn't help that (in my opinion) there is confusion regarding basic things about Zig. [1] [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
- nyberg 4y ago
  A number of those using zig in production have played with zig for a considerable amount of time (I started playing with 0.5.0 where large breaking changes came shortly after) thus know what to expect. Afaik most of those are within embedded, using it as a toolchain (zig cc not zig), or have similar constraints.
- kbd 4y ago
  Ugh that "Zig has function coloring" post again. The misunderstanding that post makes is that function coloring refers to at compile time. In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context. Obviously the functions will have different runtime representations, so if you do something that cares about runtime calling conventions or w/e then yes you do need to worry about how the function is used, which is unavoidable.

raoulj 4y ago

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?

skybrian 4y ago
I don't know but hopefully there would be something like Go's module proxy, which can be replaced or turned off. https://proxy.golang.org/ https://proxy.golang.org/
bsder 4y ago
Decentralization is good. I'm really not a fan of what has happened in the Rust community with crates. The fact that there is a single blessed Rust crate source and the fact that the Rust community doesn't take responsibility for vetting crates means that maintainership changes, name squatting gold rush, and a whole host of pathological behaviors show up. If you're not going to take responsibility, then the only option is to leave everything decentralized.

thefaux 4y ago

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. 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. 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. 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.

flohofwoe 4y ago
Why do you care so much about a language you have no interest in? Just ignore it and move on, there's plenty of programming languages under the sky to have fun with and which probably fit your idea of a good programming language much better than Zig.

eatonphil 4y ago

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. 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. 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.) But I'm still early on in my exploration of Zig. (Disclaimer: the company I work for uses Zig and sponsors ZSF.)

pjmlp 4y ago
Being a better C is not hard to achieve as goal, JOVIAL, NEWP and PL/I did it one decade before C was born, and Modula-2 did it while C was mostly a Bell Labs toy, back in 1978. The problem is getting the wider market to pick better C languages.
- eatonphil 4y ago
  I agree! I think the Zig community is doing a better job marketing than most better-c languages (which saddens me in some respects because I like D too, but sometimes you go with what meets most criteria and seems like it will succeed with adoption!).
jpe90 4y ago
I started trying to learn Zig as my first non-GC language but switched over to C because I had trouble finding learning resources for Zig, while there are plenty of books and C code written to ISO standards to learn from. It felt like a language for people already proficient in C/C++ and systems programming.. but props to you for proving that wrong!

2pEXgD0fZ5cF 4y ago

> The package manager will not assume the presence of a central package index. We don’t plan to create an official package index. This is great to hear!

sitkack 4y ago

I hope Zig continues to ship clang, because Zig is the easiest way to install clang.

SoraNoTenshi 4y ago
If i am not mistaken, that's one of the larger selling points in Favour of Zig, isn't it? I am pretty sure the C/C++ capabilities will stay in the Zig toolchain for a very long time :)
int_19h 4y ago
And to build C and C++ projects! https://kristoff.it/blog/maintain-it-with-zig/ https://kristoff.it/blog/maintain-it-with-zig/

skohan 4y ago

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. 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. 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? 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. Either way I guess that's a luxury he has the right to indulge as an independently funded auteur PL designer.

kristoff_it 4y ago
The choice of improving the performance of the compiler before working on the package manager was deliberate. With the new compiler you will be able to have plenty of dependencies and compilation times / memory usage will remain reasonable. The same could not be said of the bootstrap compiler. For us compilation speed is part of the main value offering of Zig.
- anonymoushn 4y ago
  Is this working? stage2 seems to take similar and large amounts of time to compile a non-async-using program from our project with no caches and with caches after a whitespace change.
  - cturtle 4y ago
    The linked post mentioned that the compiler itself does compile faster, but not by much. Memory usage is the greatest impact of stage2. The speed will come when the native backends are finished. Right now the compile time is mostly llvm. The idea is a native and fast backend for debug (development) builds, and llvm for optimized releases.

Kukumber 4y ago

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 Tests, deployment, up to restarting the service in prod, the language should empower me to not loose time 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 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 Glad that you understand that and you made sure you built the foundation that enables it, that's game changer

lacasito25 4y ago
Single biggest reason I don't start new rust projects

haberman 4y ago

> 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. 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.

DrNosferatu 4y ago

Congrats Zig Team! Allow me to comment from my professional perspective: 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… 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) PS: Of course with C support from the get go - maybe additionally other languages.

throwawaymaths 4y ago
It would be awesome if zig implemented compiler hooks, for example: shoot off messages at various stages (sema of files, zir on individual functions, linker events), with some sort of defined binary structure (ok if it's defined in zig itself!) at say a tcp port.
- flavious 4y ago
  Yes, that would be amazing, full classes of approaches to problem solving would be unlocked at once and we wouldn't have to invent new languages, DSLs, transpilers, etc, but just leverage zig.

_7bxa 4y ago

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. Try to be in the 2nd group.

Tozen 4y ago
But here's the thing about that though, when it comes to other languages which are not 1.0, various people will bash and troll to no end about any flaw, bug, or mistake they can find. Hell, even smear the developers at will. How many times have we seen people dogging the hell out of Jai, Odin, Vlang, Carbon (that just started), and other newbies? People will dog other languages out and even compare them to 10 year old or older languages, without blinking.
the_mitsuhiko 4y ago
Zig is not the first new language I try. I was an excited early adopted of a lot of many languages including D, Go, Rust and TypeScript. At no point to I remember running into miscompilations on rather fundamental issues and so quickly. So I do think this is quite out of the ordinary.
- sullyj3 4y ago
  Consulting Wikipedia's "first appeared" field for each: D: 8 December 2001; 20 years ago Go: November 10, 2009; 12 years ago Rust: July 7, 2010; 12 years ago TypeScript: 1 October 2012; 10 years ago Zig: 8 February 2016; 6 years ago The only one of these which isn't at least twice as old as Zig is TypeScript, which has the might of Microsoft behind it, and is based on a well understood, pre-existing language. This is not a fair comparison.
  - Tozen 4y ago
    However, when it comes to comparing just as old or even newer languages than Zig, such as Odin, Jai, Vlang, Carbon, etc... Various people have no mercy whatsoever.
  - 4y ago

1vuio0pswjnm7 4y ago

When Golang switched to a self-hosted compiler, it lost compilation speed. When Zig switched to a self-hosted compiler, it gained compilation speed.

tapirl 4y ago
It is reasonable. For Go case, Go is slower than C. For Zig case, zig is not slower than C++.
pjmlp 4y ago
Because they weren't focused on performance, rather correctness. Later versions of the compiler improved on the performance side as they then started to improve on the compiler's backend.

rychco 4y ago

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. If you're curious to see a large Zig codebase, two significant projects are Bun [1] and TigerBeetle [2]. [1] https://github.com/oven-sh/bun https://github.com/oven-sh/bun [2] https://github.com/tigerbeetledb/tigerbeetle https://github.com/tigerbeetledb/tigerbeetle

_vvhw 4y ago
Joran from TigerBeetle here! Awesome to hear that you're excited about Zig. Thanks for sharing the link to our repo also—would love to take you on a 1-on-1 tour of the codebase sometime if you'd be up for that!