22 ms·

Zig 0.9.0

316 points by von_lohengramm 5y ago

spekcular 5y ago
Exciting stuff. How far away is Zig 1.0, roughly?
- Spex_guy 5y ago
  Hard to say, 1.0 for us comes when everything is fully stable in both the language and standard library, and we believe that it can last at least 20 years without modification. My estimate is at least 5 years from now, possibly more.
  - forrestthewoods 5y ago
    Will there be a Zig 0.10 release?
    - squeek502 5y ago
      Yes: https://github.com/ziglang/zig/milestones https://github.com/ziglang/zig/milestones
vladharbuz 5y ago
I don't know if string handling has been improved, but it's one of the few things stopping me from using Zig. I look forward to 1.0, which will hopefully have proper strings. [0] [0]: https://github.com/ziglang/zig/issues/234 https://github.com/ziglang/zig/issues/234
- flohofwoe 5y ago
  IMHO Zig's builtin string handling (or rather, lack of) is exactly right for a systems programming language. Zig avoids the biggest problem of C strings and treats strings as ptr/length slices, not as zero-terminated. UTF-8 for string literals is also fine. That's all that's needed (and should be implemented) on the language level, everything else should go into the standard library, and additional specialized string processing libraries (because string handling can never be a "one-size fits all" solution, it's too complex for that).
  - turminal 5y ago
    The issue with treating strings as slices/arrays is that it exposes (writably!) the underlying representation, which is almost never what you want and leads to subtle bugs. The downside is of course the fact that you have to account for encodings in your language now, but picking the one and only sensible encoding really shouldn't be a problem in 2021.
    - von_lohengramm 5y ago
      It's not that simple. Obviously, you'd choose UTF-8, but that exposes another issue: a codepoint is not a character. There's no simple & elegant solution to this at the language level.
      - turminal 5y ago
        > a codepoint is not a character Precisely. That's why I think representing strings as character slices and letting third party libraries handle them is not a good solution. Deciding what features to put in the language vs. the stdlib vs. third party libraries is one of the hardest parts of language design. Personally I believe strings are important and frequent enough they deserve special treatment at the language level. Edit (late addition): I think not treating strings specially is mostly fine in C, but Zig seems to aim at being a little less lowlevel.
        von_lohengramm 5y ago
        > representing strings as character slices Zig does not do this. It represents strings as byte slices. A UTF-8 character could be multiple codepoints with each codepoint being multiple bytes. A big thing about Zig is not hiding complexity. If UTF-8 were implemented at a language level (whatever that means), then "language level" string operations would be non-linear, which would be very non-Ziggy. I could see value in a standard library UTF-8 implementation, but a LOT of forethought would need to be put into it. I think keeping UTF-8 string manipulation at the third-party library level is a good choice for now. Maybe once the language is finalized, the ecosystem is more developed, and lessons have been learned from the third-party libraries, then the standard library can implement this.
- ruined 5y ago
  thread tl;dr: it doesn't look like there will be language support for things like codepoints or grapheme indexing or treatment of strings as anything but byte arrays, so ddevault is sad. there is intention from andrewrk and jecolon to provide such features in the standard library before 1.0 release. downside to library vs lang support that is you can expect a good chunk of programmers to ignore the less-ergonomic library features, use the language features at hand, and handle strings incorrectly as byte arrays.
  - dnautics 5y ago
    Does this boil to the semantic question of if the stdlib is part of the language?
    - ruined 5y ago
      i don't think so. the answer is presumed no, because everyone in the relevant thread including language authors and stdlib authors (with plenty of overlap) agree that it is not, and agree there are functional distinctions about what is possible on either side of that dividing line (mostly due to zig not supporting custom operators).
    - anonymoushn 5y ago
      One difference is that there won't be a built-in string type with operator[] defined as something other than returning the byte at the indexed position in the array of bytes. There could be most other things one would expect from language-level string support though.
- coldtea 5y ago
  It seems they don't want unicode strings as part of the language, at best as a library. But unless there's a single sactioned one, this will not end well. And this is met with answers like "just avoid string handling" from the language designers... It's probably because they don't work in any related domain, and even less so have to do with international strings (except as byte buckets they don't care about and don't have to do anything do).
  - anonymoushn 5y ago
    It seems way nicer to have a language that treats strings as byte arrays and use libraries to handle encodings than to have a language that treats strings as UCS-2 and use libraries to handle UTF-8 strings that live inside of UCS-2 strings.
    - coldtea 5y ago
      I don't know, it has been a pain to work with strings in any language that does the above, and has seldom (if ever) been a problem with Java, Go, Swift, or even modern Python 3, and so on...
      - anonymoushn 5y ago
        I'm not sure how to explain the difference in experience here. Python 3's built-in string encoding support has been a source of endless pain to me, and Lua's belief that strings are byte arrays has been much easier to deal with.
      - jstimpfle 5y ago
        I don't get what's so hard about it. Most of my programs deal with UTF-8 simply by doing memcpy(). Parsing code just loops over the bytes and compares to ASCII characters (0-9, A-Z, a-z, \n, \r, \t ...). That's how UTF-8 was designed to be used.
        SuchAnonMuchWow 5y ago
        I assume you never had to deal with unicode normalization ? When you send your unicode string to an external system (for example a storage server with a database) and latter retrieve the string, only to find out that it has been normalized differently so it no longer match byte-for-byte what is stored in your program, and all of a sudden strcmp no longer works. Or all kind of weirdness like that because every system outside of your program will handle unicode differently, and you will need to adapt to them, and having a string library to do most of the heavy-lifting will avoid the need for every user to rewrite a library from scratch. Not to mention that for every developer which rewrite unicode handling functions, you will probably end up with a function with subtly different behaviors from others, which aggravate the problem for others when they will try to communicate with your system.
ModernMech 5y ago
Is there a story behind the cartoon lizards? Are they like the Zig mascot or something? Seems like they only started appearing since the last release, but they're not explained (unless I missed it).
- xtian 5y ago
  They are ziguanas :)
  - ModernMech 5y ago
    Okay thanks! One thing I like best about programming languages are the particularities of the cultures that spring up around them.
- rudedogg 5y ago
  https://github.com/ziglang/logo#official-mascots https://github.com/ziglang/logo#official-mascots
- naltun 5y ago
  The one in the jetpack has been around for a couple years, iirc.
aix1 5y ago
Is there a good "Why Zig" writeup motivating the language? I've been looking around their web site and the only thing I could find was pretty generic: Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
- jakelazaroff 5y ago
  It's in the "learn" section: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/
- curtisf 5y ago
  Yes, there is a "why Zig when..." page in the "learn" section: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/
- von_lohengramm 5y ago
  In addition to the other recommendations, the Zig Zen[0] and The Road to Zig 1.0[1] are pretty convincing. [0] https://ziglang.org/documentation/master/#Zen https://ziglang.org/documentation/master/#Zen [1] https://www.youtube.com/watch?v=Gv2I7qTux7g https://www.youtube.com/watch?v=Gv2I7qTux7g
  - animesh 5y ago
    That Road to Zig talk is a must watch. I keep coming back to it. More than the language, I love how much conviction Andrew has in his vision for Zig.
db65edfc7996 5y ago
Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compile-Errors-for-Unused-Locals https://ziglang.org/download/0.9.0/release-notes.html#Compil... Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.
- ryanworl 5y ago
  I like this feature. It has saved me from annoying bugs multiple times in Go during refactoring.
  - deleted 5y ago
    [deleted]
- jimbob45 5y ago
  If a local is intentionally unused, it can be discarded, like this: test "example" { var x: i32 = 1234; _ = x; } Do discards not fulfill your use case?
  - deleted 5y ago
    [deleted]
  - db65edfc7996 5y ago
    That is still more movement for when I am hacking out a feature. When I am trying to figure out an idea, I am liberally creating new variables and adding imports without care. In other languages, I can freely comment in/out large swaths of code as I understand the problem. Not a deal-breaker (honestly, I write Python most days), but a huge annoyance.
    - dilap 5y ago
      Yeah, it's a fair point. Per the zig writeup, the plan / hope for this use case is an editor command that will quickly add in all the "_ = unused" statements, which should take it down to very-small annoyance. (From my use in Go, I'm definitely overall a fan of the feature. Tho of course how much personal value vs annoyance you get out of it is going to depend on your own code style and behaviors.)
Vendan 5y ago
Zig is such a cool looking language, really just love the idea of comptime, but every time it comes up, all I can think about is how it's mandating spaces for indentations. I know it seems pedantic, but a programming language just saying "I don't care about accessibility by the visually impaired" when it is just text comes across as overbearing and insensitive. https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/ https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
- lhorie 5y ago
  IIRC the self hosting compiler will allow both spaces and tabs, but they didn't feel it was worthwhile to backport this to the bootstrap compiler.
  - Vendan 5y ago
    That's... slightly better, but afaict, "allows both spaces and tabs" seems to be "convert tabs to spaces" zig fmt accepts and converts tabs to spaces, \r\n to \n, as well as many other transformations of non-canonical to canonical style. Which is... still saying "spaces instead of tabs"
    - zamadatix 5y ago
      "zig fmt" is the formatter not the aforementioned self hosted compiler.
      - Vendan 5y ago
        It's a part of the ecosystem, and is, AFAICT, saying "tabs are not welcome here". Happy to be proven wrong.
        lhorie 5y ago
        See https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-me-to-use-spaces-instead-of-tabs https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m... In a nutshell, what you're currently using is the stage 1 compiler, aka the bootstrapping compiler to compile the official zig compiler going forward. zig fmt is opinionated because it was only meant to enforce formatting for the zig project. At that stage of the project's life, they felt it was more important to get shit done in a consistent manner w/ the people that are actually contributing than to cater to a hypothetical accessibility-impaired developer that isn't. Zig is a very ambitious project. Prioritizing pragmatism over ideology is a fairly common theme with it currently. Another example: they repeatedly break stdlib APIs because catering to a larger audience is currently less important than getting other things nailed down first.
lhorie 5y ago
Would be nice to get more clarity on what exactly is the scope of the self hosted compiler. From previous discussions, I was under the impression that people would use the self hosted compiler for development, but still be expected to use the bootstrap compiler for production (because LLVM optimizations are in the latter but not the former). This page makes it sound like the self-hosted compiler will be the compiler, but various parts of the compiler infrastructure will be either interchangeable with not-quite-self-hosted modules via flags, or these LLVM-leveraging modules (e.g. for C/C++ compilation) will always be hard dependencies even in the self-hosted compiler.
- deleted 5y ago
  [deleted]
- AndyKelley 5y ago
  The self-hosted compiler is the compiler. It has an LLVM backend. The bootstrap compiler will be used only to bootstrap the self-hosted compiler. The self-hosted LLVM backend is not done. Zig 0.9.0 is the self-hosted compiler, you are using the self-hosted compiler when you use Zig today. But it relies on the bootstrap compiler for the LLVM backend. I know it is weird to say "self-hosted LLVM backend" but I don't know what else to call it. It's the .zig code that lowers Zig IR to LLVM IR. It's possible to build Zig without an LLVM dependency by not passing `-Denable-llvm` to `zig build`. In this case the LLVM backend is not available (neither the self-hosted one or the bootstrap one).
  - yellowapple 5y ago
    Does this mean that y'all are open to the self-hosted compiler supporting CPU architectures unlikely to ever have LLVM support? I know that's one of the blockers for the oft-asked "Will OpenBSD consider adopting Rust/Zig/Go/whatever?", as one example of a project that targets platforms which LLVM does not. My guess from the preliminary Plan 9 target work mentioned in the release notes is that something like a SuperH backend (for example) would indeed be in scope (provided someone's willing to contribute one, of course), but a confirmation would be neat. I suppose the C backend would do the job in these cases, too, but I'm sure it'd be nice to not have to include GCC (or some other C compiler besides zig cc) in the mix (especially for projects like OpenBSD that try to minimize copyleft code). Speaking of: how is zig cc anticipated to work with a self-hosted Zig? Will there be a dependency on clang (as suggested by the punt_to_clang(...) call in the current main.zig)? Will it be possible to swap that out with something else that could turn C into ZIR (or something else the self-hosted compiler could then punt to whatever backend)? Relatedly, would zig cc support the planned C backend? If so, would the resulting C output be equivalent to the input (notwithstanding the current limitations re: macros, struct bitfields, etc.)?
zenlot 5y ago
Is Zig going strong in community, or it's likely to remain as a niche / fans language? I like the idea, but anybody knows how community / companies react to it in a more wider "looking to use in production" environment?
- Spex_guy 5y ago
  We currently don't advise using the Zig language in production. The compiler has known bugs and even some miscompilations, and we sometimes make breaking changes to the std lib and even the language. However, `zig cc` and `zig c++` are currently considered stable enough for production use.
- refulgentis 5y ago
  I had no idea it wasn't in production yet: is there a story for why it consumes so much space on HN? Is the story strong enough already that is a clear alternative to Rust for post-C++ projects?
  - Spex_guy 5y ago
    I can't comment for all the other people who are posting and voting for those posts, but at least for me Zig has quickly become my language of choice for side projects. Its cross compilation features alone are enough for it to replace the system C/C++ compiler toolchains I used to use, and the language itself is everything I'm looking for. Readable (IMO) syntax, proper namespaces, order independent declarations, powerful metaprogramming, and an unmatched level of internal consistency all make it stand out to me. It feels like a massively simplified C++, a native language that improves significantly on C without introducing a massive set of unrelated features.
    - jeremyjh 5y ago
      It seems strange to compare to C++ when it has none of the features that most define C++ like RAII, OOP & templates. Its not really "simplified" - its something totally different.
richardanaya 5y ago
Love this zigling art.
rmanolis 5y ago
I love Zig. But unfortunately there are no use cases for web developers yet that Go and JavaScript does not do already … unless the webassembly replace JS for more cool and futuristic UI.
- ksec 5y ago
  Wait until Bun is officially released. Which would be useful for vast majority of web developers. https://bun.sh https://bun.sh
- deleted 5y ago
  [deleted]
- a-priori 5y ago
  I say this as a web developer: there's far more to programming than the web.
- edflsafoiewq 5y ago
  Why would you want to use Zig for webdev?
  - badhombres 5y ago
    So I can use zig and have someone pay me to use it :)
1_player 5y ago
Congratulations! And welcome Isaac, I loved his Zig+Wayland screencast [1], where he explained very engagingly how Zig is able to embrace and extend a pretty hairy C library and make it more memory safe, without forcing the implementor to rewrite or painfully try to bend it to the strict or idiosyncratic rules of the language, as it may happen with Rust or even Go. I can't wait for 1.0! Or at least until the docs are a bit more accessible... :) 1: https://youtu.be/mwrA5IRGpfU https://youtu.be/mwrA5IRGpfU
vince14 5y ago
> Introduced arbitrary code execution via ${jndi:ldap://... inside any logged string. hehe
jhgb 5y ago
Heh. And just yesterday, I checked if there wasn't a new release to check out! Now there is, I guess.
waruqi 5y ago
Great, we can also use Xmake to build zig program. https://xmake.io/#/guide/project_examples?id=zig-program https://xmake.io/#/guide/project_examples?id=zig-program
- deleted 5y ago
  [deleted]
errantmind 5y ago
Congrats. Here's to hoping Zig gets explicit SIMD intrinsics in 1.0. It is one of the few things holding me back. That and the pedantic compiler errors around unused variables.
- bnprks 5y ago
  I'm pretty new to Zig, but after taking another look recently I was pleasantly surprised by the progress on SIMD operations via builtin Vector types [1],[2]. For an application of "I want to speed up my math-intensive code with SIMD while supporting x86-64, aarch64, and non-SIMD fallbacks" it might be suitable for you now, and Zig certainly exposes more readable SIMD syntax than with C intrinsics imho [3]. But if you have a particular CPU instruction in mind, you're still a little bit at the mercy of the compiler as operations on Vector types aren't explicitly tied to particular CPU instructions. 1: https://github.com/ziglang/zig/issues/903#issuecomment-459508820 https://github.com/ziglang/zig/issues/903#issuecomment-45950... 2: https://ziglang.org/documentation/master/#Vectors https://ziglang.org/documentation/master/#Vectors 3: https://godbolt.org/z/P73MPncGP https://godbolt.org/z/P73MPncGP
  - AndyKelley 5y ago
    It's planned to have feature parity with all the intrinsics that are available in the wild, for any CPU architecture. The difference with C is that we want to make the intrinsics part of the language; not a compiler extension. So, while you could do compile-time CPU feature detection to check if an intrinsic will lower to machine code and choose a different implementation, you could also just express the code with the intrinsics and let the compiler decide how to lower it. It will use shims for any machine that does not have native instructions. Anyway, please file feature requests for missing SIMD intrinsics!
    - _vvhw 5y ago
      And where the CPU doesn't support some SIMD intrinsics—SWAR for the win! I've been digging into Zig's Vectors the past week and really like the decisions. Thanks!
    - 5y ago
anonymoushn 5y ago
We're quite happy about the allocgate changes. It seemed way too easy to write buggy code that would mangle the wrong bits of the stack prior to this change, and this sort of error was not caught by debug builds.

Exciting stuff. How far away is Zig 1.0, roughly?

Spex_guy 5y ago
Hard to say, 1.0 for us comes when everything is fully stable in both the language and standard library, and we believe that it can last at least 20 years without modification. My estimate is at least 5 years from now, possibly more.
- forrestthewoods 5y ago
  Will there be a Zig 0.10 release?
  - squeek502 5y ago
    Yes: https://github.com/ziglang/zig/milestones https://github.com/ziglang/zig/milestones

I don't know if string handling has been improved, but it's one of the few things stopping me from using Zig. I look forward to 1.0, which will hopefully have proper strings. [0] [0]: https://github.com/ziglang/zig/issues/234 https://github.com/ziglang/zig/issues/234

flohofwoe 5y ago
IMHO Zig's builtin string handling (or rather, lack of) is exactly right for a systems programming language. Zig avoids the biggest problem of C strings and treats strings as ptr/length slices, not as zero-terminated. UTF-8 for string literals is also fine. That's all that's needed (and should be implemented) on the language level, everything else should go into the standard library, and additional specialized string processing libraries (because string handling can never be a "one-size fits all" solution, it's too complex for that).
- turminal 5y ago
  The issue with treating strings as slices/arrays is that it exposes (writably!) the underlying representation, which is almost never what you want and leads to subtle bugs. The downside is of course the fact that you have to account for encodings in your language now, but picking the one and only sensible encoding really shouldn't be a problem in 2021.
  - von_lohengramm 5y ago
    It's not that simple. Obviously, you'd choose UTF-8, but that exposes another issue: a codepoint is not a character. There's no simple & elegant solution to this at the language level.
    - turminal 5y ago
      > a codepoint is not a character Precisely. That's why I think representing strings as character slices and letting third party libraries handle them is not a good solution. Deciding what features to put in the language vs. the stdlib vs. third party libraries is one of the hardest parts of language design. Personally I believe strings are important and frequent enough they deserve special treatment at the language level. Edit (late addition): I think not treating strings specially is mostly fine in C, but Zig seems to aim at being a little less lowlevel.
      - von_lohengramm 5y ago
        > representing strings as character slices Zig does not do this. It represents strings as byte slices. A UTF-8 character could be multiple codepoints with each codepoint being multiple bytes. A big thing about Zig is not hiding complexity. If UTF-8 were implemented at a language level (whatever that means), then "language level" string operations would be non-linear, which would be very non-Ziggy. I could see value in a standard library UTF-8 implementation, but a LOT of forethought would need to be put into it. I think keeping UTF-8 string manipulation at the third-party library level is a good choice for now. Maybe once the language is finalized, the ecosystem is more developed, and lessons have been learned from the third-party libraries, then the standard library can implement this.
ruined 5y ago
thread tl;dr: it doesn't look like there will be language support for things like codepoints or grapheme indexing or treatment of strings as anything but byte arrays, so ddevault is sad. there is intention from andrewrk and jecolon to provide such features in the standard library before 1.0 release. downside to library vs lang support that is you can expect a good chunk of programmers to ignore the less-ergonomic library features, use the language features at hand, and handle strings incorrectly as byte arrays.
- dnautics 5y ago
  Does this boil to the semantic question of if the stdlib is part of the language?
  - ruined 5y ago
    i don't think so. the answer is presumed no, because everyone in the relevant thread including language authors and stdlib authors (with plenty of overlap) agree that it is not, and agree there are functional distinctions about what is possible on either side of that dividing line (mostly due to zig not supporting custom operators).
  - anonymoushn 5y ago
    One difference is that there won't be a built-in string type with operator[] defined as something other than returning the byte at the indexed position in the array of bytes. There could be most other things one would expect from language-level string support though.
coldtea 5y ago
It seems they don't want unicode strings as part of the language, at best as a library. But unless there's a single sactioned one, this will not end well. And this is met with answers like "just avoid string handling" from the language designers... It's probably because they don't work in any related domain, and even less so have to do with international strings (except as byte buckets they don't care about and don't have to do anything do).
- anonymoushn 5y ago
  It seems way nicer to have a language that treats strings as byte arrays and use libraries to handle encodings than to have a language that treats strings as UCS-2 and use libraries to handle UTF-8 strings that live inside of UCS-2 strings.
  - coldtea 5y ago
    I don't know, it has been a pain to work with strings in any language that does the above, and has seldom (if ever) been a problem with Java, Go, Swift, or even modern Python 3, and so on...
    - anonymoushn 5y ago
      I'm not sure how to explain the difference in experience here. Python 3's built-in string encoding support has been a source of endless pain to me, and Lua's belief that strings are byte arrays has been much easier to deal with.
    - jstimpfle 5y ago
      I don't get what's so hard about it. Most of my programs deal with UTF-8 simply by doing memcpy(). Parsing code just loops over the bytes and compares to ASCII characters (0-9, A-Z, a-z, \n, \r, \t ...). That's how UTF-8 was designed to be used.
      - SuchAnonMuchWow 5y ago
        I assume you never had to deal with unicode normalization ? When you send your unicode string to an external system (for example a storage server with a database) and latter retrieve the string, only to find out that it has been normalized differently so it no longer match byte-for-byte what is stored in your program, and all of a sudden strcmp no longer works. Or all kind of weirdness like that because every system outside of your program will handle unicode differently, and you will need to adapt to them, and having a string library to do most of the heavy-lifting will avoid the need for every user to rewrite a library from scratch. Not to mention that for every developer which rewrite unicode handling functions, you will probably end up with a function with subtly different behaviors from others, which aggravate the problem for others when they will try to communicate with your system.

ModernMech 5y ago

Is there a story behind the cartoon lizards? Are they like the Zig mascot or something? Seems like they only started appearing since the last release, but they're not explained (unless I missed it).

xtian 5y ago
They are ziguanas :)
- ModernMech 5y ago
  Okay thanks! One thing I like best about programming languages are the particularities of the cultures that spring up around them.
rudedogg 5y ago
https://github.com/ziglang/logo#official-mascots https://github.com/ziglang/logo#official-mascots
naltun 5y ago
The one in the jetpack has been around for a couple years, iirc.

aix1 5y ago

Is there a good "Why Zig" writeup motivating the language? I've been looking around their web site and the only thing I could find was pretty generic: Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

jakelazaroff 5y ago
It's in the "learn" section: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/
curtisf 5y ago
Yes, there is a "why Zig when..." page in the "learn" section: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/
von_lohengramm 5y ago
In addition to the other recommendations, the Zig Zen[0] and The Road to Zig 1.0[1] are pretty convincing. [0] https://ziglang.org/documentation/master/#Zen https://ziglang.org/documentation/master/#Zen [1] https://www.youtube.com/watch?v=Gv2I7qTux7g https://www.youtube.com/watch?v=Gv2I7qTux7g
- animesh 5y ago
  That Road to Zig talk is a must watch. I keep coming back to it. More than the language, I love how much conviction Andrew has in his vision for Zig.

db65edfc7996 5y ago

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compile-Errors-for-Unused-Locals https://ziglang.org/download/0.9.0/release-notes.html#Compil... Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.

ryanworl 5y ago
I like this feature. It has saved me from annoying bugs multiple times in Go during refactoring.
- deleted 5y ago
  [deleted]
jimbob45 5y ago
If a local is intentionally unused, it can be discarded, like this: test "example" { var x: i32 = 1234; _ = x; } Do discards not fulfill your use case?
- deleted 5y ago
  [deleted]
- db65edfc7996 5y ago
  That is still more movement for when I am hacking out a feature. When I am trying to figure out an idea, I am liberally creating new variables and adding imports without care. In other languages, I can freely comment in/out large swaths of code as I understand the problem. Not a deal-breaker (honestly, I write Python most days), but a huge annoyance.
  - dilap 5y ago
    Yeah, it's a fair point. Per the zig writeup, the plan / hope for this use case is an editor command that will quickly add in all the "_ = unused" statements, which should take it down to very-small annoyance. (From my use in Go, I'm definitely overall a fan of the feature. Tho of course how much personal value vs annoyance you get out of it is going to depend on your own code style and behaviors.)

Vendan 5y ago

Zig is such a cool looking language, really just love the idea of comptime, but every time it comes up, all I can think about is how it's mandating spaces for indentations. I know it seems pedantic, but a programming language just saying "I don't care about accessibility by the visually impaired" when it is just text comes across as overbearing and insensitive. https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/ https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...

lhorie 5y ago
IIRC the self hosting compiler will allow both spaces and tabs, but they didn't feel it was worthwhile to backport this to the bootstrap compiler.
- Vendan 5y ago
  That's... slightly better, but afaict, "allows both spaces and tabs" seems to be "convert tabs to spaces" zig fmt accepts and converts tabs to spaces, \r\n to \n, as well as many other transformations of non-canonical to canonical style. Which is... still saying "spaces instead of tabs"
  - zamadatix 5y ago
    "zig fmt" is the formatter not the aforementioned self hosted compiler.
    - Vendan 5y ago
      It's a part of the ecosystem, and is, AFAICT, saying "tabs are not welcome here". Happy to be proven wrong.
      - lhorie 5y ago
        See https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-me-to-use-spaces-instead-of-tabs https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m... In a nutshell, what you're currently using is the stage 1 compiler, aka the bootstrapping compiler to compile the official zig compiler going forward. zig fmt is opinionated because it was only meant to enforce formatting for the zig project. At that stage of the project's life, they felt it was more important to get shit done in a consistent manner w/ the people that are actually contributing than to cater to a hypothetical accessibility-impaired developer that isn't. Zig is a very ambitious project. Prioritizing pragmatism over ideology is a fairly common theme with it currently. Another example: they repeatedly break stdlib APIs because catering to a larger audience is currently less important than getting other things nailed down first.

lhorie 5y ago

Would be nice to get more clarity on what exactly is the scope of the self hosted compiler. From previous discussions, I was under the impression that people would use the self hosted compiler for development, but still be expected to use the bootstrap compiler for production (because LLVM optimizations are in the latter but not the former). This page makes it sound like the self-hosted compiler will be the compiler, but various parts of the compiler infrastructure will be either interchangeable with not-quite-self-hosted modules via flags, or these LLVM-leveraging modules (e.g. for C/C++ compilation) will always be hard dependencies even in the self-hosted compiler.

deleted 5y ago
[deleted]
AndyKelley 5y ago
The self-hosted compiler is the compiler. It has an LLVM backend. The bootstrap compiler will be used only to bootstrap the self-hosted compiler. The self-hosted LLVM backend is not done. Zig 0.9.0 is the self-hosted compiler, you are using the self-hosted compiler when you use Zig today. But it relies on the bootstrap compiler for the LLVM backend. I know it is weird to say "self-hosted LLVM backend" but I don't know what else to call it. It's the .zig code that lowers Zig IR to LLVM IR. It's possible to build Zig without an LLVM dependency by not passing `-Denable-llvm` to `zig build`. In this case the LLVM backend is not available (neither the self-hosted one or the bootstrap one).
- yellowapple 5y ago
  Does this mean that y'all are open to the self-hosted compiler supporting CPU architectures unlikely to ever have LLVM support? I know that's one of the blockers for the oft-asked "Will OpenBSD consider adopting Rust/Zig/Go/whatever?", as one example of a project that targets platforms which LLVM does not. My guess from the preliminary Plan 9 target work mentioned in the release notes is that something like a SuperH backend (for example) would indeed be in scope (provided someone's willing to contribute one, of course), but a confirmation would be neat. I suppose the C backend would do the job in these cases, too, but I'm sure it'd be nice to not have to include GCC (or some other C compiler besides zig cc) in the mix (especially for projects like OpenBSD that try to minimize copyleft code). Speaking of: how is zig cc anticipated to work with a self-hosted Zig? Will there be a dependency on clang (as suggested by the punt_to_clang(...) call in the current main.zig)? Will it be possible to swap that out with something else that could turn C into ZIR (or something else the self-hosted compiler could then punt to whatever backend)? Relatedly, would zig cc support the planned C backend? If so, would the resulting C output be equivalent to the input (notwithstanding the current limitations re: macros, struct bitfields, etc.)?

zenlot 5y ago

Is Zig going strong in community, or it's likely to remain as a niche / fans language? I like the idea, but anybody knows how community / companies react to it in a more wider "looking to use in production" environment?

Spex_guy 5y ago
We currently don't advise using the Zig language in production. The compiler has known bugs and even some miscompilations, and we sometimes make breaking changes to the std lib and even the language. However, `zig cc` and `zig c++` are currently considered stable enough for production use.
refulgentis 5y ago
I had no idea it wasn't in production yet: is there a story for why it consumes so much space on HN? Is the story strong enough already that is a clear alternative to Rust for post-C++ projects?
- Spex_guy 5y ago
  I can't comment for all the other people who are posting and voting for those posts, but at least for me Zig has quickly become my language of choice for side projects. Its cross compilation features alone are enough for it to replace the system C/C++ compiler toolchains I used to use, and the language itself is everything I'm looking for. Readable (IMO) syntax, proper namespaces, order independent declarations, powerful metaprogramming, and an unmatched level of internal consistency all make it stand out to me. It feels like a massively simplified C++, a native language that improves significantly on C without introducing a massive set of unrelated features.
  - jeremyjh 5y ago
    It seems strange to compare to C++ when it has none of the features that most define C++ like RAII, OOP & templates. Its not really "simplified" - its something totally different.

richardanaya 5y ago

Love this zigling art.

rmanolis 5y ago

I love Zig. But unfortunately there are no use cases for web developers yet that Go and JavaScript does not do already … unless the webassembly replace JS for more cool and futuristic UI.

ksec 5y ago
Wait until Bun is officially released. Which would be useful for vast majority of web developers. https://bun.sh https://bun.sh
deleted 5y ago
[deleted]
a-priori 5y ago
I say this as a web developer: there's far more to programming than the web.
edflsafoiewq 5y ago
Why would you want to use Zig for webdev?
- badhombres 5y ago
  So I can use zig and have someone pay me to use it :)

1_player 5y ago

Congratulations! And welcome Isaac, I loved his Zig+Wayland screencast [1], where he explained very engagingly how Zig is able to embrace and extend a pretty hairy C library and make it more memory safe, without forcing the implementor to rewrite or painfully try to bend it to the strict or idiosyncratic rules of the language, as it may happen with Rust or even Go. I can't wait for 1.0! Or at least until the docs are a bit more accessible... :) 1: https://youtu.be/mwrA5IRGpfU https://youtu.be/mwrA5IRGpfU

vince14 5y ago

> Introduced arbitrary code execution via ${jndi:ldap://... inside any logged string. hehe

jhgb 5y ago

Heh. And just yesterday, I checked if there wasn't a new release to check out! Now there is, I guess.

waruqi 5y ago

Great, we can also use Xmake to build zig program. https://xmake.io/#/guide/project_examples?id=zig-program https://xmake.io/#/guide/project_examples?id=zig-program

deleted 5y ago
[deleted]

errantmind 5y ago

Congrats. Here's to hoping Zig gets explicit SIMD intrinsics in 1.0. It is one of the few things holding me back. That and the pedantic compiler errors around unused variables.

bnprks 5y ago
I'm pretty new to Zig, but after taking another look recently I was pleasantly surprised by the progress on SIMD operations via builtin Vector types [1],[2]. For an application of "I want to speed up my math-intensive code with SIMD while supporting x86-64, aarch64, and non-SIMD fallbacks" it might be suitable for you now, and Zig certainly exposes more readable SIMD syntax than with C intrinsics imho [3]. But if you have a particular CPU instruction in mind, you're still a little bit at the mercy of the compiler as operations on Vector types aren't explicitly tied to particular CPU instructions. 1: https://github.com/ziglang/zig/issues/903#issuecomment-459508820 https://github.com/ziglang/zig/issues/903#issuecomment-45950... 2: https://ziglang.org/documentation/master/#Vectors https://ziglang.org/documentation/master/#Vectors 3: https://godbolt.org/z/P73MPncGP https://godbolt.org/z/P73MPncGP
- AndyKelley 5y ago
  It's planned to have feature parity with all the intrinsics that are available in the wild, for any CPU architecture. The difference with C is that we want to make the intrinsics part of the language; not a compiler extension. So, while you could do compile-time CPU feature detection to check if an intrinsic will lower to machine code and choose a different implementation, you could also just express the code with the intrinsics and let the compiler decide how to lower it. It will use shims for any machine that does not have native instructions. Anyway, please file feature requests for missing SIMD intrinsics!
  - _vvhw 5y ago
    And where the CPU doesn't support some SIMD intrinsics—SWAR for the win! I've been digging into Zig's Vectors the past week and really like the decisions. Thanks!
  - 5y ago

anonymoushn 5y ago

We're quite happy about the allocgate changes. It seemed way too easy to write buggy code that would mangle the wrong bits of the stack prior to this change, and this sort of error was not caught by debug builds.