8 ms·

Zig 0.12.0 Release Notes

119 points by GalaxySnail 2y ago

frankjr 2y ago
const connection = try http_server.accept(); defer connection.stream.close(); This pattern of reaching into the returned struct's internals is so weird to me. Why not just connection.close()? Unnecessary Use of var Sounds like yet another case of "this should be a warning instead".
- ginko 2y ago
  > Sounds like yet another case of "this should be a warning instead". Agreed. There should at least be a way to turn this into a warning during development.
  - flohofwoe 2y ago
    If it takes the same direction as the controversial "unused vars are errors" feature, IDE integrations will take care of that. For instance in VSCode the unused-var-error has become a complete non-issue taken care of by autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. But TBH, I'm using similar strict error settings in TS/ESLint for a long time now (as part of our company linter rules) without autoformatting and it's fine.
    - masklinn 2y ago
      > IDE integrations will take care of that So this is an IDE-mandatory language which does not come with an IDE? > autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. So the error has become a non issue by completely undermining it? That seems like the opposite of a good idea. > I'm using similar strict error settings in TS/ESLint A linter or an IDE "error" is equivalent to a compiler warning: they don't prevent compiling and running the code. And JS/TS's const is much weaker than Zig's, essentially trivial: zig's const means the value is immutable, not just the binding.
      - flohofwoe 2y ago
        > So this is an IDE-mandatory language which does not come with an IDE? Nope. AFAIK the autofixing is actually implemented by `zig fmt`. The IDE integration just makes that feature available as "VSCode Formatter". > So the error has become a non issue by completely undermining it? That seems like the opposite of a good idea. Nope. The important part is that the autofix works in both directions. E.g. if an unused-fix was added before, it will be removed as soon as the variable is used. This makes the development workflow painless, but at the same time the code cannot become littered with redundant unused-fixes. It's also trivial to search for the "_ =" discard pattern to find any leftover discards (in a 'final' codebase there shouldn't be any of those). > A linter or an IDE "error" is equivalent to a compiler warning: they don't prevent compiling and running the code. Nope, in our case it's an actual hard compile error. You can't "npm build" or even git-commit a project that has unused variables (which are not explicitly discarded).
        masklinn 2y ago
        > Nope. Except yes, and your clarifications confirm it. If the formatter automatically adds and removes artificial uses for unused variables then you're undermining the diagnostic since you're automatically suppressing it. It's completely useless. Worse than useless even. Not to mention zig's diagnostic is as crap as go's: it doesn't track unused stores, so it only catches a minuscule number of possible issues, and misses the much larger one, yielding both incredible annoyance and false confidence, all because the maintainers of both languages refuse to support warnings. > It's also trivial to search for the "_ =" discard pattern to find any leftover discards (in a 'final' codebase there shouldn't be any of those). Meanwhile a warning actually tells you directly and reminds you, without having to "search for the discard pattern". > Nope, in our case it's an actual hard compile error. Boy am I happy not to work with you.
        AndyKelley 2y ago
        > It's completely useless It seems like you're forgetting that it shows up in diffs (code reviews) and text editors.
    - throwawaymaths 2y ago
      > For instance in VSCode the unused-var-error has become a complete non-issue taken care of by autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. this doesn't help anyone writing autogen code, though.
- HeavyStorm 2y ago
  A violation of the Law of Demeter.
- wild_pointer 2y ago
  > Sounds like yet another case of "this should be a warning instead". The discussion about it is indeed interesting: https://github.com/ziglang/zig/issues/224 https://github.com/ziglang/zig/issues/224 e.g.: > > When debugging/prototyping, it's useful to comment out a line without having to refactor, e.g. > > I think this use case is a strong argument. However, it's up against another strong use case, which is the ability to rely on a set of assumptions when reading the source of a compiling codebase. > [...] > a variable declared with var does have a modification to it Which is an interesting property. We'll see how it goes for them.
- NoReligion 2y ago
  [dead]
deleted 2y ago
[deleted]
Alifatisk 2y ago
Zig is, I think the only language, that at first didn't catch my attention, but slowly grew on me. It started off by finding out zig cc.
latch 2y ago
I've written a lot of Zig, including a somewhat popular http framework, a driver for PostgreSQL and one for DuckDB. Personally, I feel that if you want to grow as a programmer, no matter what you're doing, there's little that offers more bang for your buck than learning C. You can pick up C relatively quickly, and that knowledge will serve you (maybe mostly indirectly) throughout your entire career. Learning Zig is a much better option. Too many quality of life improvements over C, and you still learn the same fundamentals. If you're interested, I wrote something that might help (1). As for _using_ Zig. I think it's a good idea to take a conservative view and assume the ecosystem is hostile. The quality of test coverage of the standard library varies. Breaking changes are frequent and aren't always trivial. 3rd party libraries are often abandoned and many are written by people learning Zig (including my own!). It's really great for learning/side/fun project because you can get distracted for weeks writing something you never intended to. It's not actively hostile, but I think approaching it that way will help manage expectations. I would strongly consider tracking the master branch. If you write anything substantial in Zig, you will 100% run into a must-have bug-fix or feature in the stdlib or 3rd party library that depends on on 0.13.x development commit. (1) - https://www.openmymind.net/learning_zig/ https://www.openmymind.net/learning_zig/
- RetroTechie 2y ago
  Zig is positioned as a sort of "better C", correct? With that in mind, how does Zig compare to C, complexity-wise? Both for learning, and its implementation. Is it a 'bigger' language than C? Just different? Easier to grasp? Or takes more effort to get a good understanding of? About the same as C? Anyway: a very promising project. Nice to see it progressing towards a mature ecosystem.
  - flohofwoe 2y ago
    IMHO (not the parent): from the perspective of a C programmer, Zig is several things: 1. A "better C" in the sense that the language core of Zig fixes the commonly known and accepted design warts of C which are hard to fix because of backward compatibility requirements - this part is actually less complex and easier to learn than C because there's less implicit and less unexpected hidden behaviour while having roughly the same "language surface". If you are used to C's somewhat sloppy "hippie-approach" to programming, be prepared that the Zig compiler will yell at you a lot at the start of the learning phase, especially when it comes to implicit type conversions which follow very strict rules in Zig (when compared to C). 2. A much richer and actually useful stdlib (in this area Zig is also a much better C++), don't quite expect a Python-style "batteries included" stdlib though. 3. A much more complete compiler toolchain package, with a build system, package manager, C/C++/ObjC integration and cross-compilation to the important target platforms included and working out of the box (and most of that integrated into the Zig executable, a vanilla Zig install actually only has a single executable, the Zig compiler). 4. And finally the "visionary part", where Zig differs most from C and other languages and explores its own path, like the approach to comptime, generics, type reflection and error handling.
sobeston 2y ago
Small self plug: https://zig.guide https://zig.guide is ready for Zig 0.12. Some notable changes in zig.guide since Zig 0.11 came out: - Changed from following master, to following major releases (Zig is more stable now, less work for me. Yay.). - Migrated from Hugo to Docusaurus, bringing some large frontend improvements. - Moved over from ziglearn.org to zig.guide. - Removed 'usage in production is not recommended' from the front page. - Support for versioning. - Greatly improved testing through build.zig. - Opened up for github sponsorships. - Added another section for supplementary walkthroughs. The site still isn't nearly where I want it to be but there's been some big improvements in the last few months.
- Gys 2y ago
  - Migrated from Hugo to Docusaurus, bringing some large frontend improvements. Does this mean Docusaurus has more or better features? I do not know either of them very well but looking for a solution to publish md docs.
  - sobeston 2y ago
    You could probably make a good docs site in hugo with enough work, but Docusaurus has pretty much everything I need out of the box (and is less annoying to extend). I think it really is a lot better for documentation.
jcalabro 2y ago
Congrats to the team! I've been regularly using Zig for a bit over a year now and it's been fantastic. I feel as though it's helped me grow as a programmer as well as has allowed me to build some cool stuff. It's a pleasure to use!
fithisux 2y ago
Congrats, I find myself more and more interested.
binary132 2y ago
I love the idea of Zig, but it really bothers me that they haven’t put 100% total priority on stdlib reliability and asyncrony. It kinda boggles my mind in particular that they’ve left async unfinished all this time. I can argue myself into tolerating an unfinished stdlib until the 1.0 release, since at least the interface should be pretty stable, but it’s been years, and async is an essential differentiator in this domain that needed to be nailed down early so that an ecology and craft theory could start developing around it. Instead, not only does Zig still lack a production-quality stdlib today, but it’s basically a nonstarter against the main contenders without proper async. Maybe the thing to do would have been to offer some type of sanitary minimal API for a stack object + state machine + set/longjmp builtin primitives that have well-defined semantics so that at least people could get started defining usable APIs on top of it and experimenting with it. Instead there was a false start on it with a short stop. I don’t understand the mindset that led to this (non-)decision, but it erodes my confidence in the project. I understand that it’s not meant to inspire confidence and that it’s still experimental, but at this timescale it is simply frustrating to see and wish for a better status. I know, I’m not wearing their shoes or whatever. Maybe I’m being uncharitable, but I don’t think I could really be accused of being impatient at this point. In fairness, I feel this is a major hole in nearly everything but Go, so I guess getting it right is important.
- flohofwoe 2y ago
  Tbh, I don't understand the fixation on async/await in any language, and the last place where I would want to have that baked in is the stdlib (instead even with async/await available the lowest 'async stdlib layer' should use simple completion callbacks, which can then be wrapped in a higher level async/await compatible API if desired - although the original Zig async/await actually had a solution for the function color problem, which made such an 'async-agnostic' layering less important). Async/await is a nice-to-have syntax sugar, but not required to write asynchronous code, and considering the substantial under-the-hood complexity I'm not sure if async/await is a good thing overall, especially in a low level systems programming language like Zig (or FWIW, also Rust and C++). Arguably, promises are an important concept in JS because it's a convenient and composable method to let code complete "in the background" without proper multithreading, but promises work just fine without the async/await code transformation magic (which even in JS is just the cherry on the top, but not a must-have feature). > sanitary minimal API for a stack object + state machine + set/longjmp builtin primitives Traditional async/await doesn't use most of that but instead relies on the compiler to transform sequential 'async code' into a switch-case state machine. What you want sounds more like green threads / fibers with stack switching. This isn't portable to some platforms where the call stack isn't accessible (like WASM). But as I wrote above, I think that lowest layer should simply be 'stdlib functions with completion callbacks'. Those low level functions can then be wrapped into all sorts of asynchronous/multithreading runtimes. FWIW, I think a stack-switching fiber runtime should be possible in Zig without special language primitives, because Zig has inline assembly: https://ziglang.org/documentation/master/#Assembly https://ziglang.org/documentation/master/#Assembly
yoav 2y ago
I started learning zig to build electrobun a couple months ago [1]. It’s very much like low level go and feels like home for people with Typescript experience. Even with all the little quirks and gaps, it’s my new fav language. The other day I ported a c implementation of bsdiff to zig and was able to make it go 20% faster and compress patches 10% smaller. Very excited for the future of zig. The stated mission of replacing c and mindset of the people building it align well with how I think. Can’t wait to update to 0.12.0 when I’m back at my laptop. [1] https://github.com/blackboardsh/electrobun https://github.com/blackboardsh/electrobun
templix 2y ago
I'm 100% hooked on Zig, don't really wanna use another language anymore Reading other people's Zig code is usually a joy, as is writing it
Jarred 2y ago
If you like writing Zig, Bun is hiring systems engineers in San Francisco. We are one of the largest Zig projects. https://bun.sh/careers https://bun.sh/careers
- ane 2y ago
  What's your business model? Where do you get money to pay people?
  - lioeters 2y ago
    From an archived announcement page of Oven, the company behind Bun: > Oven has raised $7m in funding led by Bucky at Kleiner Perkins with participation from Guillermo Rauch, YCombinator’s Continuity Fund and more. > Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun. > The plan is to run our own servers on the edge in datacenters around the world. Oven will leverage end-to-end integration of the entire JavaScript stack (down to the hardware) to make new things possible. https://archive.ph/1gnVt https://archive.ph/1gnVt
- vitaminCPP 2y ago
  Hey Jarred; Nice to see you here. Great work on Bun. Excited to see the future of your project.
38 2y ago
Note TLS/HTTPS is still not working https://github.com/ziglang/zig/issues/14172 https://github.com/ziglang/zig/issues/14172
- AndyKelley 2y ago
  it's working perfectly fine, it just has not met the project's high standard of test coverage yet.
  - latch 2y ago
    I think there are at least 2 serious issues with TLS, both documented in: https://github.com/ziglang/zig/issues/15226 https://github.com/ziglang/zig/issues/15226
  - 38 2y ago
    are you nuts? TLS 1.2 is not supported at all
overflyer 2y ago
IMHO the fact that Zig already gained a lot of track in software development does bring some responsibilities whether the devs like it or not. If you create a language that good and something that is actually taken seriously for tackling the behemoth task of being the actual predecessor for C that has been around half a century, then you CANNOT simply excuse weak points with "the language is not done, yet.". No sorry for you guys, you made some freaking good stuff, people wanna use it in production already, deal with your success. And there aren't even many pain points with the language itself. Most of them are meta. Here are my pain points: - Documentation: Step it up... this is a mess. I might be able to learn it because I learned many languages over the years, but many people will just give up frustrated and never turn back. And even so I am mostly OK with the docs, I still miss stuff. One of the worst things could as well be its own point: Document the build system darn it. It is so hard to learn, that I prefer using any other build system or even creating manual zig commands. - ZLS needs to be merged as part of the project. The fact that it is not always on par with every commit is annoying. A language server should be an inseparable part of a language nowadays. - And now to one of the few pain points I have with the language itself: You cannot be serious about that "underscore, unused variable" solution. That is so extremely ugly and code polluting. I know this critique was harsh, but it is because I love this language and I think it will take off so heavily :). My fear is that if those things are not considered that at a certain point users will be annoyed by Zig and it will lose a big amount of userbase.
- rofrol 2y ago
  This may help - https://ziggit.dev/t/build-system-tricks/3531 https://ziggit.dev/t/build-system-tricks/3531 - https://ziggit.dev/t/how-to-package-a-zig-source-module-and-how-to-use-it/3457 https://ziggit.dev/t/how-to-package-a-zig-source-module-and-... - https://ziggit.dev/t/importation-and-dependencies/4067/14 https://ziggit.dev/t/importation-and-dependencies/4067/14
- ngrilly 2y ago
  Considering that the language is "not done yet", I think the documentation is quite ok for now. But I'd really like a proper language specification, similar to https://go.dev/ref/spec https://go.dev/ref/spec, updated in lockstep with the implementation. I also agree that the build system needs some minimal documentation. It is a bit arcane without it. Considering that a major goal of Zig is to build and maintain robust software, the decision of making unused variables an error is interesting and worth exploring. It works pretty well in practice when we use ZLS, which goes back to your point about making ZLS part of the standard toolchain. > deal with your success And how exactly should the Zig team deal with its success? That's a small team, with limited funding. Do you think they should prioritize the pain points you listed over the ones in their current roadmap?
deleted 2y ago
[deleted]

119 points by GalaxySnail 2y ago

const connection = try http_server.accept(); defer connection.stream.close(); This pattern of reaching into the returned struct's internals is so weird to me. Why not just connection.close()? Unnecessary Use of var Sounds like yet another case of "this should be a warning instead".

ginko 2y ago
> Sounds like yet another case of "this should be a warning instead". Agreed. There should at least be a way to turn this into a warning during development.
- flohofwoe 2y ago
  If it takes the same direction as the controversial "unused vars are errors" feature, IDE integrations will take care of that. For instance in VSCode the unused-var-error has become a complete non-issue taken care of by autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. But TBH, I'm using similar strict error settings in TS/ESLint for a long time now (as part of our company linter rules) without autoformatting and it's fine.
  - masklinn 2y ago
    > IDE integrations will take care of that So this is an IDE-mandatory language which does not come with an IDE? > autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. So the error has become a non issue by completely undermining it? That seems like the opposite of a good idea. > I'm using similar strict error settings in TS/ESLint A linter or an IDE "error" is equivalent to a compiler warning: they don't prevent compiling and running the code. And JS/TS's const is much weaker than Zig's, essentially trivial: zig's const means the value is immutable, not just the binding.
    - flohofwoe 2y ago
      > So this is an IDE-mandatory language which does not come with an IDE? Nope. AFAIK the autofixing is actually implemented by `zig fmt`. The IDE integration just makes that feature available as "VSCode Formatter". > So the error has become a non issue by completely undermining it? That seems like the opposite of a good idea. Nope. The important part is that the autofix works in both directions. E.g. if an unused-fix was added before, it will be removed as soon as the variable is used. This makes the development workflow painless, but at the same time the code cannot become littered with redundant unused-fixes. It's also trivial to search for the "_ =" discard pattern to find any leftover discards (in a 'final' codebase there shouldn't be any of those). > A linter or an IDE "error" is equivalent to a compiler warning: they don't prevent compiling and running the code. Nope, in our case it's an actual hard compile error. You can't "npm build" or even git-commit a project that has unused variables (which are not explicitly discarded).
      - masklinn 2y ago
        > Nope. Except yes, and your clarifications confirm it. If the formatter automatically adds and removes artificial uses for unused variables then you're undermining the diagnostic since you're automatically suppressing it. It's completely useless. Worse than useless even. Not to mention zig's diagnostic is as crap as go's: it doesn't track unused stores, so it only catches a minuscule number of possible issues, and misses the much larger one, yielding both incredible annoyance and false confidence, all because the maintainers of both languages refuse to support warnings. > It's also trivial to search for the "_ =" discard pattern to find any leftover discards (in a 'final' codebase there shouldn't be any of those). Meanwhile a warning actually tells you directly and reminds you, without having to "search for the discard pattern". > Nope, in our case it's an actual hard compile error. Boy am I happy not to work with you.
        AndyKelley 2y ago
        > It's completely useless It seems like you're forgetting that it shows up in diffs (code reviews) and text editors.
  - throwawaymaths 2y ago
    > For instance in VSCode the unused-var-error has become a complete non-issue taken care of by autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. this doesn't help anyone writing autogen code, though.
HeavyStorm 2y ago
A violation of the Law of Demeter.
wild_pointer 2y ago
> Sounds like yet another case of "this should be a warning instead". The discussion about it is indeed interesting: https://github.com/ziglang/zig/issues/224 https://github.com/ziglang/zig/issues/224 e.g.: > > When debugging/prototyping, it's useful to comment out a line without having to refactor, e.g. > > I think this use case is a strong argument. However, it's up against another strong use case, which is the ability to rely on a set of assumptions when reading the source of a compiling codebase. > [...] > a variable declared with var does have a modification to it Which is an interesting property. We'll see how it goes for them.
NoReligion 2y ago
[dead]

deleted 2y ago

[deleted]

Alifatisk 2y ago

Zig is, I think the only language, that at first didn't catch my attention, but slowly grew on me. It started off by finding out zig cc.

latch 2y ago

I've written a lot of Zig, including a somewhat popular http framework, a driver for PostgreSQL and one for DuckDB. Personally, I feel that if you want to grow as a programmer, no matter what you're doing, there's little that offers more bang for your buck than learning C. You can pick up C relatively quickly, and that knowledge will serve you (maybe mostly indirectly) throughout your entire career. Learning Zig is a much better option. Too many quality of life improvements over C, and you still learn the same fundamentals. If you're interested, I wrote something that might help (1). As for _using_ Zig. I think it's a good idea to take a conservative view and assume the ecosystem is hostile. The quality of test coverage of the standard library varies. Breaking changes are frequent and aren't always trivial. 3rd party libraries are often abandoned and many are written by people learning Zig (including my own!). It's really great for learning/side/fun project because you can get distracted for weeks writing something you never intended to. It's not actively hostile, but I think approaching it that way will help manage expectations. I would strongly consider tracking the master branch. If you write anything substantial in Zig, you will 100% run into a must-have bug-fix or feature in the stdlib or 3rd party library that depends on on 0.13.x development commit. (1) - https://www.openmymind.net/learning_zig/ https://www.openmymind.net/learning_zig/

RetroTechie 2y ago
Zig is positioned as a sort of "better C", correct? With that in mind, how does Zig compare to C, complexity-wise? Both for learning, and its implementation. Is it a 'bigger' language than C? Just different? Easier to grasp? Or takes more effort to get a good understanding of? About the same as C? Anyway: a very promising project. Nice to see it progressing towards a mature ecosystem.
- flohofwoe 2y ago
  IMHO (not the parent): from the perspective of a C programmer, Zig is several things: 1. A "better C" in the sense that the language core of Zig fixes the commonly known and accepted design warts of C which are hard to fix because of backward compatibility requirements - this part is actually less complex and easier to learn than C because there's less implicit and less unexpected hidden behaviour while having roughly the same "language surface". If you are used to C's somewhat sloppy "hippie-approach" to programming, be prepared that the Zig compiler will yell at you a lot at the start of the learning phase, especially when it comes to implicit type conversions which follow very strict rules in Zig (when compared to C). 2. A much richer and actually useful stdlib (in this area Zig is also a much better C++), don't quite expect a Python-style "batteries included" stdlib though. 3. A much more complete compiler toolchain package, with a build system, package manager, C/C++/ObjC integration and cross-compilation to the important target platforms included and working out of the box (and most of that integrated into the Zig executable, a vanilla Zig install actually only has a single executable, the Zig compiler). 4. And finally the "visionary part", where Zig differs most from C and other languages and explores its own path, like the approach to comptime, generics, type reflection and error handling.

sobeston 2y ago

Small self plug: https://zig.guide https://zig.guide is ready for Zig 0.12. Some notable changes in zig.guide since Zig 0.11 came out: - Changed from following master, to following major releases (Zig is more stable now, less work for me. Yay.). - Migrated from Hugo to Docusaurus, bringing some large frontend improvements. - Moved over from ziglearn.org to zig.guide. - Removed 'usage in production is not recommended' from the front page. - Support for versioning. - Greatly improved testing through build.zig. - Opened up for github sponsorships. - Added another section for supplementary walkthroughs. The site still isn't nearly where I want it to be but there's been some big improvements in the last few months.

Gys 2y ago
- Migrated from Hugo to Docusaurus, bringing some large frontend improvements. Does this mean Docusaurus has more or better features? I do not know either of them very well but looking for a solution to publish md docs.
- sobeston 2y ago
  You could probably make a good docs site in hugo with enough work, but Docusaurus has pretty much everything I need out of the box (and is less annoying to extend). I think it really is a lot better for documentation.

jcalabro 2y ago

Congrats to the team! I've been regularly using Zig for a bit over a year now and it's been fantastic. I feel as though it's helped me grow as a programmer as well as has allowed me to build some cool stuff. It's a pleasure to use!

fithisux 2y ago

Congrats, I find myself more and more interested.

binary132 2y ago

I love the idea of Zig, but it really bothers me that they haven’t put 100% total priority on stdlib reliability and asyncrony. It kinda boggles my mind in particular that they’ve left async unfinished all this time. I can argue myself into tolerating an unfinished stdlib until the 1.0 release, since at least the interface should be pretty stable, but it’s been years, and async is an essential differentiator in this domain that needed to be nailed down early so that an ecology and craft theory could start developing around it. Instead, not only does Zig still lack a production-quality stdlib today, but it’s basically a nonstarter against the main contenders without proper async. Maybe the thing to do would have been to offer some type of sanitary minimal API for a stack object + state machine + set/longjmp builtin primitives that have well-defined semantics so that at least people could get started defining usable APIs on top of it and experimenting with it. Instead there was a false start on it with a short stop. I don’t understand the mindset that led to this (non-)decision, but it erodes my confidence in the project. I understand that it’s not meant to inspire confidence and that it’s still experimental, but at this timescale it is simply frustrating to see and wish for a better status. I know, I’m not wearing their shoes or whatever. Maybe I’m being uncharitable, but I don’t think I could really be accused of being impatient at this point. In fairness, I feel this is a major hole in nearly everything but Go, so I guess getting it right is important.

flohofwoe 2y ago
Tbh, I don't understand the fixation on async/await in any language, and the last place where I would want to have that baked in is the stdlib (instead even with async/await available the lowest 'async stdlib layer' should use simple completion callbacks, which can then be wrapped in a higher level async/await compatible API if desired - although the original Zig async/await actually had a solution for the function color problem, which made such an 'async-agnostic' layering less important). Async/await is a nice-to-have syntax sugar, but not required to write asynchronous code, and considering the substantial under-the-hood complexity I'm not sure if async/await is a good thing overall, especially in a low level systems programming language like Zig (or FWIW, also Rust and C++). Arguably, promises are an important concept in JS because it's a convenient and composable method to let code complete "in the background" without proper multithreading, but promises work just fine without the async/await code transformation magic (which even in JS is just the cherry on the top, but not a must-have feature). > sanitary minimal API for a stack object + state machine + set/longjmp builtin primitives Traditional async/await doesn't use most of that but instead relies on the compiler to transform sequential 'async code' into a switch-case state machine. What you want sounds more like green threads / fibers with stack switching. This isn't portable to some platforms where the call stack isn't accessible (like WASM). But as I wrote above, I think that lowest layer should simply be 'stdlib functions with completion callbacks'. Those low level functions can then be wrapped into all sorts of asynchronous/multithreading runtimes. FWIW, I think a stack-switching fiber runtime should be possible in Zig without special language primitives, because Zig has inline assembly: https://ziglang.org/documentation/master/#Assembly https://ziglang.org/documentation/master/#Assembly

yoav 2y ago

I started learning zig to build electrobun a couple months ago [1]. It’s very much like low level go and feels like home for people with Typescript experience. Even with all the little quirks and gaps, it’s my new fav language. The other day I ported a c implementation of bsdiff to zig and was able to make it go 20% faster and compress patches 10% smaller. Very excited for the future of zig. The stated mission of replacing c and mindset of the people building it align well with how I think. Can’t wait to update to 0.12.0 when I’m back at my laptop. [1] https://github.com/blackboardsh/electrobun https://github.com/blackboardsh/electrobun

templix 2y ago

I'm 100% hooked on Zig, don't really wanna use another language anymore Reading other people's Zig code is usually a joy, as is writing it

Jarred 2y ago

If you like writing Zig, Bun is hiring systems engineers in San Francisco. We are one of the largest Zig projects. https://bun.sh/careers https://bun.sh/careers

ane 2y ago
What's your business model? Where do you get money to pay people?
- lioeters 2y ago
  From an archived announcement page of Oven, the company behind Bun: > Oven has raised $7m in funding led by Bucky at Kleiner Perkins with participation from Guillermo Rauch, YCombinator’s Continuity Fund and more. > Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun. > The plan is to run our own servers on the edge in datacenters around the world. Oven will leverage end-to-end integration of the entire JavaScript stack (down to the hardware) to make new things possible. https://archive.ph/1gnVt https://archive.ph/1gnVt
vitaminCPP 2y ago
Hey Jarred; Nice to see you here. Great work on Bun. Excited to see the future of your project.

38 2y ago

Note TLS/HTTPS is still not working https://github.com/ziglang/zig/issues/14172 https://github.com/ziglang/zig/issues/14172

AndyKelley 2y ago
it's working perfectly fine, it just has not met the project's high standard of test coverage yet.
- latch 2y ago
  I think there are at least 2 serious issues with TLS, both documented in: https://github.com/ziglang/zig/issues/15226 https://github.com/ziglang/zig/issues/15226
- 38 2y ago
  are you nuts? TLS 1.2 is not supported at all

overflyer 2y ago

IMHO the fact that Zig already gained a lot of track in software development does bring some responsibilities whether the devs like it or not. If you create a language that good and something that is actually taken seriously for tackling the behemoth task of being the actual predecessor for C that has been around half a century, then you CANNOT simply excuse weak points with "the language is not done, yet.". No sorry for you guys, you made some freaking good stuff, people wanna use it in production already, deal with your success. And there aren't even many pain points with the language itself. Most of them are meta. Here are my pain points: - Documentation: Step it up... this is a mess. I might be able to learn it because I learned many languages over the years, but many people will just give up frustrated and never turn back. And even so I am mostly OK with the docs, I still miss stuff. One of the worst things could as well be its own point: Document the build system darn it. It is so hard to learn, that I prefer using any other build system or even creating manual zig commands. - ZLS needs to be merged as part of the project. The fact that it is not always on par with every commit is annoying. A language server should be an inseparable part of a language nowadays. - And now to one of the few pain points I have with the language itself: You cannot be serious about that "underscore, unused variable" solution. That is so extremely ugly and code polluting. I know this critique was harsh, but it is because I love this language and I think it will take off so heavily :). My fear is that if those things are not considered that at a certain point users will be annoyed by Zig and it will lose a big amount of userbase.

rofrol 2y ago
This may help - https://ziggit.dev/t/build-system-tricks/3531 https://ziggit.dev/t/build-system-tricks/3531 - https://ziggit.dev/t/how-to-package-a-zig-source-module-and-how-to-use-it/3457 https://ziggit.dev/t/how-to-package-a-zig-source-module-and-... - https://ziggit.dev/t/importation-and-dependencies/4067/14 https://ziggit.dev/t/importation-and-dependencies/4067/14
ngrilly 2y ago
Considering that the language is "not done yet", I think the documentation is quite ok for now. But I'd really like a proper language specification, similar to https://go.dev/ref/spec https://go.dev/ref/spec, updated in lockstep with the implementation. I also agree that the build system needs some minimal documentation. It is a bit arcane without it. Considering that a major goal of Zig is to build and maintain robust software, the decision of making unused variables an error is interesting and worth exploring. It works pretty well in practice when we use ZLS, which goes back to your point about making ZLS part of the standard toolchain. > deal with your success And how exactly should the Zig team deal with its success? That's a small team, with limited funding. Do you think they should prioritize the pain points you listed over the ones in their current roadmap?

deleted 2y ago

[deleted]