6 ms·

I think Zig is great and I'm following it with interest. But I think people should be aware that it is not really stable yet, at least in my experience from tr

I think Zig is great and I'm following it with interest. But I think people should be aware that it is not really stable yet, at least in my experience from trying it earlier this year. I ran into a compiler crash: https://github.com/ziglang/zig/issues/7865 https://github.com/ziglang/zig/issues/7865. I attempted to fix the compiler crash myself (https://github.com/ziglang/zig/pull/8372 https://github.com/ziglang/zig/pull/8372), and I found a fix that worked, but apparently it was not the right fix, and I was told the correct fix would be "quite hard" and "To fix some of the bugs you would need to rewrite quite a bit of code." It sounds like a big milestone will be when Zig's stage1 compiler is self-hosting, written in Zig instead of in C++. I got the sense that the C++ code I was modifying is somewhat crufty, and the Zig version of it will be better designed in many ways (ie. https://github.com/ziglang/zig/issues/89#issuecomment-382110023 https://github.com/ziglang/zig/issues/89#issuecomment-382110...), which will make fixing bugs like the one I encountered will be more tractable. I personally will be interested to revisit Zig when this migration occurs. I also found that the language was changing from release to release in ways that made me update the code. This is all totally reasonable for a language in development, and I mean no disrespect to the Zig devs -- it's an extremely interesting language. I only say this because stories I saw on HN gave me an impression that Zig was farther along than it is, at least in my experience.

bagels 5y ago
Why would they spend the effort on writing the zig compiler in zig?
- TheApexTheater 5y ago
  There are a couple of reasons why creating a self-hosting compiler can be good idea: 1. Shows to others that your language is capable of a project of moderate complexity, as well as display what an "idiomatic" version of writing code is 2. Remove dependencies on parts you can't control (once you rewrite it in Zig, rather than C++, you don't need to worry about new C++ features or deprecations between versions) 3. Writing code in the language helps catch bugs in the language specification and in the compiler's implementation of the language. These are just the ones off the top of my head, but people with more PL-Design experience may be able to elaborate.
  - dgb23 5y ago
    Contributions are another one I think. Both the authors and potential collaborators might find it more attractive to use their language of choice. Compilers also tend to pose a variety of challenges that force one to really dig into a language.
    - shp0ngle 5y ago
      Yep. I know it's entirely other end of the language spectrum, but I think that's why Typescript got successful while Flow did not; Typescript is in Typescript, while Flow is in OCaml. And nobody knows OCaml. OTOH, eslint is making waves now and it's in golang, so. Who knows.
      - blacktriangle 5y ago
        I'm not a golang fan, but one thing I've noticed about go is that it is possibly the most approachable yet real programming language for beginners I've ever seen. I think this is part of why go is doing so well in the devops space. Sys admins who are not really well versed in programming but know enough to write some scripts here and there are able to bring their domain specific knowledge of admin tasks and write code to contribute.
      - pekim 5y ago
        I suspect that you might mean esbuild (not eslint).
- deleted 5y ago
  [deleted]
- AndyKelley 5y ago
  For all the reasons that Zig is a better language than C++: * Debugging is easier, faster, and more straightforward * Fewer bugs due to footguns in the language * Typical Zig code runs faster than typical C++ code. Part of this is due to Zig's safety features - there are design optimizations for performance that I won't even attempt in C or C++ because it's footgun city. Meanwhile in Zig it's actually completely safe in debug builds; you get a compile error or runtime panic if you mess up something. * Floating point operations work on f16 and f128 without a dependency on SoftFloat library * Cross compilation is trivial * Comptime features make build options feasible and maintainable, such as enabling/disabling logging, whether to link libc, whether to link llvm, whether to enable tracy profiling, etc. * Zig's error handling makes correct code the default instead of the other way around in C++ * The std lib HashMap, ArrayHashMap, and ArrayList data structures are really nice * If the compiler is written in Zig, then adding a new target backend to the Zig compiler makes the Zig compiler work on that target. With another language we are stuck only supporting whatever that language supports. Not only that but the Zig compiler available for download today is already backed by majority of lines of code written in Zig rather than C++; what is available today is already partially self-hosted. For example the following features are already written in Zig, not C++: `zig fmt`, `zig translate-c`, the command line interface, `zig cc`/`zig c++`, `zig build`, the cache system, compiler-rt, the macOS linker, and compile error checks that operate before type checking.
  - _vvhw 5y ago
    > * The std lib HashMap, ArrayHashMap, and ArrayList data structures are really nice Reading Zig's std lib HashMap code the first time was an unforgettable experience for me. I've spent literally months on some state of the art hash table papers, implementations and tons of hash functions, and Zig's HashMap implementation has got to be right up there with some of the best and most performant out of the box. However, what impressed me most was just the level of control offered by the interface, and how clean and readable the code is.
zamalek 5y ago
I tried, and enjoyed, Zig. My enjoyment rapidly fell off a cliff when I started getting deeper into the stdlib. It feels like (this may not be true) that people contributed random stuff into it, a bit like C++ prior to Boost. The inconsistency hampered my enjoyment, and I headed back to Rust.
- 10000truths 5y ago
  Andrew plans to audit the zig stdlib before the 1.0 release to fix those issues: https://github.com/ziglang/zig/issues/1629 https://github.com/ziglang/zig/issues/1629
- flohofwoe 5y ago
  I think that's ok for being so early in the development cycle. Currently the Zig stdlib seems to be mostly stuff that's needed by the compiler and build system. At least it's already much more useful than the C stdlib.
_vvhw 5y ago
As a counterpoint, we've written several thousand lines of code in Zig for a new financial accounting database called TigerBeetle [1], and all we've seen were two compiler bugs. The first was already fixed a few hours before we reported it, and the second was not a showstopper and something we could easily work around. On the other hand, because Zig has incredible velocity, we're also seeing that std lib contributions or fixes we make (e.g. io_uring) are landed quickly, and that the community has some of the most talented programmers we've seen, who are also well aware of where the language is at (and like you, also looking forward to self-hosted). As for TigerBeetle, when we made the decision to go with Zig, the only alternative for us was C since we needed a safe way to handle memory allocation failure and also wanted a simple language with high orthogonality and power, and C interop. However, C's toolchain even then was still not as "ready" as Zig's and Zig also presented a unique approach to safety (e.g. the compiler can check that all syscall errors are handled at compile time, and integer arithmetic and overflow is checked by default) plus comptime, which is a force multiplier. To be fair, the days of debugging we save through Zig's safety compared to C's undefined behavior, we could easily spend a few hours contributing small fixes back to the language. And breaking changes between releases have also been fairly tame, and the changes welcome. We appreciate the velocity here. The final insight for us was realizing that it would also take us some time to get our project to production, and that our roadmap would probably intersect with Zig's stability. We go into this decision some more in the Q&A at the end of our Zig SHOWTIME talk [2]. We could have skated to where the puck was at, or where we believed it would be, and we picked the latter. Technological waves can be incredible if you can spot the value ahead of the curve. In hindsight, this decision has paid off again and again. We would never go back to C. For new projects, there are a good many reasons to pick Zig, and for projects that may have a long half-life, this decision may be all the more important. [1] https://www.tigerbeetle.com https://www.tigerbeetle.com [2] https://www.youtube.com/watch?v=BH2jvJ74npM https://www.youtube.com/watch?v=BH2jvJ74npM (TigerBeetle — A Million Financial Transactions Per Second In Zig)
- ksec 5y ago
  This is going completely off topic but Tigerbeetle is really interesting. Is it the first of its kind of are there many other financial accounting databases?

bagels 5y ago

Why would they spend the effort on writing the zig compiler in zig?

TheApexTheater 5y ago
There are a couple of reasons why creating a self-hosting compiler can be good idea: 1. Shows to others that your language is capable of a project of moderate complexity, as well as display what an "idiomatic" version of writing code is 2. Remove dependencies on parts you can't control (once you rewrite it in Zig, rather than C++, you don't need to worry about new C++ features or deprecations between versions) 3. Writing code in the language helps catch bugs in the language specification and in the compiler's implementation of the language. These are just the ones off the top of my head, but people with more PL-Design experience may be able to elaborate.
- dgb23 5y ago
  Contributions are another one I think. Both the authors and potential collaborators might find it more attractive to use their language of choice. Compilers also tend to pose a variety of challenges that force one to really dig into a language.
  - shp0ngle 5y ago
    Yep. I know it's entirely other end of the language spectrum, but I think that's why Typescript got successful while Flow did not; Typescript is in Typescript, while Flow is in OCaml. And nobody knows OCaml. OTOH, eslint is making waves now and it's in golang, so. Who knows.
    - blacktriangle 5y ago
      I'm not a golang fan, but one thing I've noticed about go is that it is possibly the most approachable yet real programming language for beginners I've ever seen. I think this is part of why go is doing so well in the devops space. Sys admins who are not really well versed in programming but know enough to write some scripts here and there are able to bring their domain specific knowledge of admin tasks and write code to contribute.
    - pekim 5y ago
      I suspect that you might mean esbuild (not eslint).
deleted 5y ago
[deleted]
AndyKelley 5y ago
For all the reasons that Zig is a better language than C++: * Debugging is easier, faster, and more straightforward * Fewer bugs due to footguns in the language * Typical Zig code runs faster than typical C++ code. Part of this is due to Zig's safety features - there are design optimizations for performance that I won't even attempt in C or C++ because it's footgun city. Meanwhile in Zig it's actually completely safe in debug builds; you get a compile error or runtime panic if you mess up something. * Floating point operations work on f16 and f128 without a dependency on SoftFloat library * Cross compilation is trivial * Comptime features make build options feasible and maintainable, such as enabling/disabling logging, whether to link libc, whether to link llvm, whether to enable tracy profiling, etc. * Zig's error handling makes correct code the default instead of the other way around in C++ * The std lib HashMap, ArrayHashMap, and ArrayList data structures are really nice * If the compiler is written in Zig, then adding a new target backend to the Zig compiler makes the Zig compiler work on that target. With another language we are stuck only supporting whatever that language supports. Not only that but the Zig compiler available for download today is already backed by majority of lines of code written in Zig rather than C++; what is available today is already partially self-hosted. For example the following features are already written in Zig, not C++: `zig fmt`, `zig translate-c`, the command line interface, `zig cc`/`zig c++`, `zig build`, the cache system, compiler-rt, the macOS linker, and compile error checks that operate before type checking.
- _vvhw 5y ago
  > * The std lib HashMap, ArrayHashMap, and ArrayList data structures are really nice Reading Zig's std lib HashMap code the first time was an unforgettable experience for me. I've spent literally months on some state of the art hash table papers, implementations and tons of hash functions, and Zig's HashMap implementation has got to be right up there with some of the best and most performant out of the box. However, what impressed me most was just the level of control offered by the interface, and how clean and readable the code is.

zamalek 5y ago

I tried, and enjoyed, Zig. My enjoyment rapidly fell off a cliff when I started getting deeper into the stdlib. It feels like (this may not be true) that people contributed random stuff into it, a bit like C++ prior to Boost. The inconsistency hampered my enjoyment, and I headed back to Rust.

10000truths 5y ago
Andrew plans to audit the zig stdlib before the 1.0 release to fix those issues: https://github.com/ziglang/zig/issues/1629 https://github.com/ziglang/zig/issues/1629
flohofwoe 5y ago
I think that's ok for being so early in the development cycle. Currently the Zig stdlib seems to be mostly stuff that's needed by the compiler and build system. At least it's already much more useful than the C stdlib.

_vvhw 5y ago

As a counterpoint, we've written several thousand lines of code in Zig for a new financial accounting database called TigerBeetle [1], and all we've seen were two compiler bugs. The first was already fixed a few hours before we reported it, and the second was not a showstopper and something we could easily work around. On the other hand, because Zig has incredible velocity, we're also seeing that std lib contributions or fixes we make (e.g. io_uring) are landed quickly, and that the community has some of the most talented programmers we've seen, who are also well aware of where the language is at (and like you, also looking forward to self-hosted). As for TigerBeetle, when we made the decision to go with Zig, the only alternative for us was C since we needed a safe way to handle memory allocation failure and also wanted a simple language with high orthogonality and power, and C interop. However, C's toolchain even then was still not as "ready" as Zig's and Zig also presented a unique approach to safety (e.g. the compiler can check that all syscall errors are handled at compile time, and integer arithmetic and overflow is checked by default) plus comptime, which is a force multiplier. To be fair, the days of debugging we save through Zig's safety compared to C's undefined behavior, we could easily spend a few hours contributing small fixes back to the language. And breaking changes between releases have also been fairly tame, and the changes welcome. We appreciate the velocity here. The final insight for us was realizing that it would also take us some time to get our project to production, and that our roadmap would probably intersect with Zig's stability. We go into this decision some more in the Q&A at the end of our Zig SHOWTIME talk [2]. We could have skated to where the puck was at, or where we believed it would be, and we picked the latter. Technological waves can be incredible if you can spot the value ahead of the curve. In hindsight, this decision has paid off again and again. We would never go back to C. For new projects, there are a good many reasons to pick Zig, and for projects that may have a long half-life, this decision may be all the more important. [1] https://www.tigerbeetle.com https://www.tigerbeetle.com [2] https://www.youtube.com/watch?v=BH2jvJ74npM https://www.youtube.com/watch?v=BH2jvJ74npM (TigerBeetle — A Million Financial Transactions Per Second In Zig)

ksec 5y ago
This is going completely off topic but Tigerbeetle is really interesting. Is it the first of its kind of are there many other financial accounting databases?