zig

The Zig programming language approach to communications is a great example of what you advocate: https://github.com/ziglang/zig/wiki/Community

Correction: https://github.com/ziglang/zig/issues/10018

There is an open issue for something like `cargo test` https://github.com/ziglang/zig/issues/10018

Here is some kind of valgrind API [1] and a here is a report from someone who tried using valgrind [2]. Yes, it doesn’t sound all that special. [1] https://github.com/ziglang/zig/blob/master/lib/std/valgrind.... [2] https://dev.to/stein/some-notes-on-using-valgrind-with-zig-3...

There's an open issue to add some kind of function annotation+errors for functions which require you to call a cleanup function. The discussion has had a lot of back and forth and they haven't really settled on a desirable solution yet, but it's something they're hoping to add. https://github.com/ziglang/zig/issues/782 I work in games with C++ and we already do so much manual management and initialization+teardown functions that lack of RAII isn't a deal-breaker. Though I'd definitely prefer it if there was something either well-enforced or automatic.

Yep, and we also encourage this, if you open the (incomplete, buggy) autogenerated doc for the standard library, you get a banner at the top that links you to a wiki page that explains how the standard library is structured. https://github.com/ziglang/zig/wiki/How-to-read-the-standard...

There is the `std.unicode` module[1] which provides standard unicode functions (encode, decode, length, iteration over code points), so I don't think it's fair to say that the language's library lacks strings in any real sense. I will re-emphasize that I've not used it, so I cannot speak for its quality. [1]: https://github.com/ziglang/zig/blob/master/lib/std/unicode.z...

I found the standard library's support for strings was plenty fine, doing AoC problems in zig tests it out thoroughly. Tokenize[1], split[2] and trim[3] were the most common ones I used. Was there something in particular you were looking for and didn't find? [1]: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L... [2]: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L... [3]: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L... * After I read my own comment, I'd note that AoC tests out string manipulation pretty thoroughly but things like unicode handling not at all, so []const u8 as a string may be more annoying in the real world than in AoC answers and I haven't used zig's unicode facilities at all

> Everything in Zig is const x = blah;, so why are functions not const bar = function() {};? This may or may not happen: https://github.com/ziglang/zig/issues/8383 > Fixing the standard library documentation would be my biggest priority if I worked on Zig, because I think that is the only thing holding back general usage of the toolchain. This is a valid concern, but I believe the zig team is deliberately holding off on improving the std lib documentation, because they are expecting (potentially huge, maybe not? who knows) breaking changes down the line. The "stdlib is not documented" is a deliberate choice to signal "use at your own risk, especially with respect to forwards compatibility". > there are still quite a few bits of syntatic sugar hiding the real cost of certain operations (like the try error handling, there is implicit bra

> Initializing arrays is weird in Zig. Lets say you want to have a 0 initialized array, you declare it like [_]u8{0} * 4 which means I want an array, of type u8, that is initialized to 0 and is 4 elements long. You get used to the syntax, but it’s not intuitive. Alternatively: var some_array = std.mem.zeroes([4]u8); Though as mentioned later in the article the standard library documentation is not very good, making this not as obvious as it could be. > Everything in Zig is const x = blah;, so why are functions not const bar = function() {};? Good question, there's an accepted proposal to fix this: https://github.com/ziglang/zig/issues/1717 > The builtin compiler macros (that start with @) are a bit confusing. Some of them have a leading uppercase, others a lowercase, and I never did work out any pattern to them. In idiomatic zig, anyth

The first issue is closed with a nicely written message of how hard tabs will be supported and why they aren't now. The second issue links to the first issue when the point of hard tabs are brought up. The FAQ you link at the end contains, directly above the section you linked, a version of the explanation in the first issue, while the exact section you linked also links back to the first issue anyways. So yes, all of the quotes and conclusions you found are either old or wrong according to the very pages you linked. No, it doesn't need to be updated (or prioritized?) as they all conclude with supporting tabs you just hadn't read all of what you're citing. . If there is still any doubt for some reason rather than trolling through GitHub issues from 2017 I'd recommend sticking to the current FAQ from 2021 which has a section dedicated to t

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-45950... 2: https://ziglang.org/documentation/master/#Vectors 3: https://godbolt.org/z/P73MPncGP

Please see https://github.com/ziglang/zig/issues/544#issuecomment-36396... and https://github.com/ziglang/zig/issues/663. In particular, `For every codepoint of zig source code, it is an error for the codepoint to be one of U+0000-U+0009, U+000b-U+001f, U+007f, U+0085, U+2028, U+2029`. Hard tab is U+0009, which is called out as specifically an error. This could just be stale docs, but it's linked to from the wiki as well: https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-fmt-hav.... Again, if this is all old, please ignore (and maybe make it a priority to update?). But the general tone is: "No tabs, only spaces"

It is possible they will add a type level resource release obligation at some point. It would not be anything quite like the Rust borrow checker but I think would be a big help. https://github.com/ziglang/zig/issues/782

Yes: https://github.com/ziglang/zig/milestones