All Things Zig

Let's have a Zig thread. Post interesting stuff, show your projects or tell everyone what you love or hate about Zig. For those not aware, the Zig programming language is a compiled general-purpose language that basically aims to be a replacement for the C programming language. It removes the bad parts of C, such as undefined behavior and the macro preprocessor, and adds modern programming features that help in writing robust, safe and reusable code while giving you the same control over memory allocations and code alignment that you get with C. It seamlessly integrates with C libraries and comes with its own standard library (which doesn't depend on libc). https://ziglang.org/ https://ziglang.org/documentation/master/ https://github.com/ziglang/zig/wiki

There's like a billion C pretenders, what makes this one different?

>>13884 Take off every zig. All your base are belong to us >>13885 Maybe https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Already-CPP,-D,-and-Rust%3F has the answer to your question, but I am yet to find a detailed review of Zig and how it compares similar languages like C OOC https://ooc-lang.org/ Vala Nim https://nim-lang.org/ Kit https://www.kitlang.org/ SafeC http://www.safe-c.org/ Cyclone http://cyclone.thelanguage.org/ CheckedC https://github.com/microsoft/checkedc CO http://c0.typesafety.net/ C-- https://www.cs.tufts.edu/~nr/c--/index.html I did find https://gist.github.com/andrewrk/b09e2024177692fcc08e. I haven't used Zig personally, but it looks interesting, though its dependency on LLVM is somewhat of a concern. To be honest I wish OP had posted their own examples of Zig, or mentioned Zig in a different thread before deciding to make a Zig thread.

>>13886 It was mentioned in the now closed thread about compiled languages some weeks ago. Whatever happened to it? I can't find it in the catalog.

>>13885 The creator did an entertaining talk on Zig recently which is worth watching if you're vaguely interested in the language. https://hooktube.com/watch?v=Gv2I7qTux7g >There's like a billion C pretenders, what makes this one different? I think the tl;dr is he didn't create the langauge from scratch he started with a C compiler (clang), removed things he thought were dangerous/dumb/legacy like the preprocessor and incrementally added new things he thought would make C better and the result is Zig.

>>13893 I remember a whole thread about Zig recently. It could be some other board though. I feel this trxt has been already posted somewhere else.

>>13900 dejavu here too

I like zig, if for no other reason, because it makes rust spammers angry. I know zig is better than their lang based entirely on their immediate escalation to ghandi con 3.

>>13884 How does zig handle multithreading, concurrency, and parallelism?

Does it have anonymous functions?

>>13946 I love zig almost as much as I love rust.

>>13947 it has nothing special to offer there. >>13948 it's planned: https://github.com/ziglang/zig/issues/1717

Why is the preprocessor bad?

>>14486 If you have one at all, you have to explain why what the preprocessor offers can't be done with the language itself. C has some pretty stupid limitations that the processor can gloss over, that Zig just doesn't have. C's preprocessor is particularly bad in that it permits code that looks like one thing but does something radically different. ATS's 'preprocessor' at least replaces elements in the parsed AST tree instead of in the text of the source code.

>>13900 >>13904 sounds like lainchan maybe?

>>13884 Currently using zig to prototype a product at work since have spare time to learn it. It's going great, few gotchas but not too many rough edges where the compiler crashes. Parsing binary protocols is where it's been great and I'm hopeful for the wasm part as going for a fully (with required js parts) patching DOM in pure zig seems to be going well thus far. Can't show anything yet though but will ask once its further along. >>14486 It's a separate language I must learn with different rules and the preproc tends to have next to no understanding of the language it's manipulating. Even AST based macros can really bite you in dynamic languages while in static they tend to cause 20 page long error messages from locations you can't directly see in your code (C++, Template Haskell, etc). It's code you don't see that hurts you the most. >>13948 _ = (struct { pub fn f(x: var) @TypeOf(x) { return x; } }).f(4); As the other said, no but you can get pretty far without them. >>13885 This one feel more complete with a better implementation of most of the features than others I've tried. It's barely C in it's meta programming which feels like it will go much further than it currently has now that automatic json printing and parsing exists (soon xml, messagepack, etc? I hope so). The stdlib design is brilliant too with it's pass-the-allocator style not forcing you to use a particular allocator with greater code reuse available between platforms along with the lazy processing of modules which makes platform dependent imports just an if expression rather than some macro soup. Cross compilation is also much better.

seems like a sane and more coherent rust

>>13885

>>13885 Zig is not a C but a walk towards a static lisp. A while back zig did seem like C with features cleaned up however that's no longer the case. Zig's error system is great as it's expressed in both the type and at the callsite rather than being implicit. This combined with inference of error sets makes it rewarding to handle errors at the most level convenient. The only issue some have is the restriction to error values rather than user provided types (I'd argue this isn't a limitation but rather a solid feature). @Type() has gained more power recently with the ability to construct all container types leading to computing optimal structures rather than resorting to external code generation. This is now enough to implement Type Providers as a library where traits are already and interfaces exist as one too. Sure, it's not possible to modify functions more than conditional compilation based on compile-time values but one doesn't miss it since it can be lifted into functions. Take the JSON parser in std as an example, it specializes a parser for the exact data structure you pass it causing it to fail early if input deviates from the type's structure while parsing meaning it's not vulnrable to overflow attacks in most cases with the exception of overflowing the bitstack on a type nested further than the size of it (comptime computation of it's size resolves this). The focus on cross-compilation has made it a tool which extends to improve C/C++ development in addition to Zig itself. Interaction with C by translation of headers and ABI compatibility takes away a great deal of friction between reusing existing code. Zig isn't just a better C, it's a better build system. Sums, products, and algebraic data types, refer to rust and haskell for more. Pointer handling is another area where Zig has improved far beyond that of C with sentinel slices and arrays, optionals instead of null, alignment tracked within the type system, and so on. The lisp part itself? You can run the whole of zig as the meta language for zig (with a few more conveniences) allowing for strategies to be computed. With a layer of indirection you could switch from AoS to SoA simply by passing along the desired mode as a comptime parameter and a function for constructing the correct view of the data you wish to work against rather than having to hide it through type erasure and abstract types. So that's how zig is different. There's more but those are the main points I care about.

>>20882 >sender side formating WTF are you doing?

>>17397 Yes, but without the marketing benefits of paying Steve Klabnik, Andrew Gallant, and about four other weird dudes to brigade HN every day for a decade to convince junior devs/students of its merit

>>20882 This is a bit of a stretch. At least that is what I think, perhaps you or someone could explain with examples. So many people talk about a programming language, and they point to theory or some contrived scenario but never post concrete demo code. C has so many examples for real world applications, as does Haskell, Rust, etc., so when people come to say things like this but you cannot find actual examples of this comparison it seems a bit moot. > Zig isn't just a better C, it's a better build system. Having to deal with packaging Zig, how it deals with things outside FHS is amusing and that is coming from someone that has dealt with CMake, and other tooling hell. Zig is/has an abomination for packaging, library resolution, etc. In case someone asks, see commit 2148336 which has caused some people problems (supposedly for FHS shenanigans). Also the creator views an aggressiveness toward following the system a good thing and prefers the project settings get preferred for flags, etc. Issue #3382 on GitHub for those playing at home. I find this amusing especially because my system fundamentally means I should be in control especially if I want to do something the project does not desire. If Zig cannot compile, link and run programs while following system conventions and blames the system when every other language worth its salt does it just fine, does that not make Zig fragile? At work we have patched GCC and LLVM/Clang to support custom flags. This is mainly for our in house static analysis but also networked runtime performance collection. For our CI these are globally set and the logs get watched after each significant build so we know there are no regressions on tests, etc. We got this to work fine with Rust, Haskell, Go, but Zig? No. It does not just want to do the one thing it is supposed to do compile code. Instead it demands you perfect the world to its own opinion and if it is in a good mood your code will compile, link and maybe run.

does its' logo represent what programs compiled in it do to the battery life of devices that run them?

>>21032 Zig's actually a really light language, since it's basically C.

>>21012 I think that asking Zig to be as mature as Rust, Haskell, C and Go is a bit silly. This is not production ready yet, and the issue you quote will be resolved before 1.0. Also, I do think that the arguments here https://github.com/ziglang/zig/issues/3382#issuecomment-540088556 provide a compelling reason to think about being overly reliant on the system. Also, if your work requieres a patched GCC and LLVM, maybe Zig is just not for you yet, considering that they're moving away from LLVM to self-hosted. I can also just be wrong idk, I'm not a language/compiler nerd, just someone that likes C and Zig.

>>21012 Zig devs should re-invent some wheel like Grep. Call it “zipgrep” because it “zips grep to shreds!” Yeah, it has fewer features, but, whatever.That’s the ticket to success. Oh, you use cat? You poor philistine, I use “zat” which is cat with emojis...written in Zig btw ;)

>>21041 I don't get the joke

>>21048 It is because that is what most Rust and Golang users have became. I don't think zig would ever become like that because it doesn't promise your programs to be better just by using it and if someone writes a reimplementation in Zig, it could be easily adapted to C aswell.

>>21048 > ripgrep is a rust rewrite of grep that has less features, but its colorful and slightly faster. > bat is a rust rewrite of cat that's more colorful and automatically uses a pager if the file is larger than a certain amount. > exa is a rewrite of ls that's more colorful and can display custom icons for different filetypes > [insert list of 50+ go and rust rewrites of various utilites, most of which are derivative yet pleasant to use] admittedly I use some of these because I like colors. Though they may not be proper replacements for the commands they try to supersede they are very pleasant to use. >>21041 I laughed, thanks anon.

Does Zig has it's Mein Kampf like C has K&R?

>>21071 Not, because Zigmund Freud was jewish.

>>21050 >It is because that is what most Rust and Golang users have became. As a Go fan who does about 95% of their work in the language, I'd like to dispute this point, but I won't, because it's absolutely true. But in fairness to the language itself, if Go didn't exist, a lot of Go projects would have otherwise have been Node.js projects instead. And if there's one thing I think we can all agree on, it's that the less Javascript there is in this world, the better off we all are.

>>21095 this. some of the projects are pretty original from my understanding though. I think fzf is written in go, and its a great utility.

>>21095 Agreed. Saw a couple CLI projects that were in NodeJS and that physically pained me. >>21058 I also like colours. I wrote a pretty version of cat a while back that detected if the file was a code file, and would highlight the syntax if that was the case. Made reading some small thing pretty comfy. >>21034 Agreed Zig is nowhere near production ready. Self-hosted seems incredibly interesting, and I have really high hopes for the future of the language. It also helps that the dev doesn't seem to be as much of a zealot like Elm's creator is.

Zig will hold us over until Jai is released

>>21208 >Agreed. Saw a couple CLI projects that were in NodeJS and that physically pained me. Dear god in heaven. I was thinking more in terms of webapps, where it kinda-sorta-ish makes sense to re-use existing language expertise if you just need a really really simple backend server that a frontend dev has the time to throw together in a week. But CLI projects in Node? As in deliberately choosing Javascript in a situation where there's a hundred better language alternatives, instead of it being forced due to being the only thing browsers speak? Wow. Just... wow. That ain't right. That ain't right.

>>21236 I keep forgetting that Jai exists.

>>21267 I mean zig is literally scuffed Jai. Work on zig was started shortly after the Jai compiler demos, and implemented a bunch of the novel features in a lower-quality, more limited, less polished way. Jai also comes with much more library stuff like rendering, UI, audio, networking, etc I like zig and I like Andrew Kelley, but it will go away after Jai is released.

This is the one thing that keeps me from using Zig. https://github.com/ziglang/zig/issues/1481 I love the language, but I can't work with certain libraries because of that. It saddens me deeply.

>>21034 > considering that they're moving away from LLVM to self-hosted. For debug builds and targets with poor or no support from LLVM along with incremental builds and (soon) hot-code swapping. LLVM isn't going away as a release option. >>21402 I don't understand the jai hype, there's no code to be seen in public afaik thus it's unusable until release of it. Closed source compilers are (well, I wish) a thing of the past. >>21012 > At work we have patched GCC and LLVM/Clang to support custom flags. Have build.zig resolve the flags and add them? When it comes to system flags it's a pain when moving your project to another machine and it suddenly breaks as flags differ and you haven't noticed. Explicit mention of using it can be made nicer but that's mostly it.

Does anyone have a good comparison coming from someone proficient with D wondering why I'd want a different "C with compile time and fat pointers." I read the linked github page >>13886 and it was not very satisfying. >No hidden control flow I want a language to beautify my program, not make it ugly and hard to follow. There's nothing inherently wrong with operator overloading etc. >Zig's standard library is still very young Things will change and break and maybe they'll find something seriously wrong with the approach. D has a crisis right now because standard library algorithms handle unicode by default and in a way that not only is incorrect, but also incurs a runtime penalty. >C ABI support It seems to me that you have to throw most the unique language features away to write a C ABI library. I can write a library in D with C bindings and play with all the shiny toys. >Zig has no macros and no metaprogramming This is the biggest problem to me. My initial impression is that if I want to do something not involving typeinfo (which is a great and useful addition) then it seems less powerful than the C preprocessor. In my use case for C I have an X macro that generates declarations and loads symbols from a dynamic library.

>>21660 I'm also a d user but not a zig programmer. If I understand correctly, features (or lack thereof) like no operator overloading and manually passing around allocators conform with the perceived implications of zig's mission, being a systems programming language. Unfortunately, as you've stated, this comes at a cost: burdening the programmer by impeding one from succinctly expressing concepts. Instead of an organization or individual specifying style and conventions, zig will enforce its own. Many like this, it seems. With regards to the library situation, that's just the state of zig not having reached version 1.0. (Thankfully, for D, there are escape hatches to avoid auto-decoding. I love Andrei's work, but that blunder was brutal.) I cannot comment on the rest as I'm not familiar.

>>21661 I think it's a self defeating goal trying to court C programmers by not startling them with operator overloading. Everyone who would leave C already has for C++/Ada/D/Rust/anything else from the past three decades. C will continue to shamble along due to its unique positioning with unix, and to a lesser extent embedded. I haven't used Zig enough to determine if it can replace my use of C macros and D mixins, but the dogma leads me to believe that it cannot.

>>21660 I think this https://youtu.be/Gv2I7qTux7g explains the philosophy of zig very well. Andrew has some strange opinions (like banning tabs from formating) but overall i thing it's a good idea.

>>21741 All someone needs to do now is build their own self-hosting zig toolchain with the random stuff like that removed. Granted, that's a lot of work.

>>21754 Well, compiler is MIT, all you would need to do is scan source code for '\t' and replace aborts with continues.

User was derezzed for clearly preferring Rust

I wrote >>21660 and I just wanted to update the thread after having used zig for a few little projects. It's good, everything I like from C and more features than I expected. My main complaint was the lack of something like D mixins, and I admit I was wrong. Anonymous structs with compile time arguments can be used for what I want to do with the usingnamespace feature.

>>22515 Its kind of interessting, because meta progamming was never directly implemented and supported as a feature, but it was ermerging from comptime. This is the same case with generics. Its also not directly supported, but emerging from comptime. Its weird to see all this useful features emegre from a single concept. I think this is the essence of why zig is so interessting.

>>22803 Comptime is just straight meta programming with a different name and the given restrictions as you're programming in zig' rather than zig which is the same for haskell, idris, lisp and so on. That said, there are three proposals left until Zig is pretty much a playground for program specialization [1] [2] [3]. [1]: https://github.com/ziglang/zig/issues/6965 [2]: https://github.com/ziglang/zig/issues/7257 [3]: https://github.com/ziglang/zig/issues/7224

>>21012 As someone who deals with packaging software regularly, I find this at least amusing. CMake has become more FHS-friendly in the recent half decade, at least. I'm wondering one thing, though. There's a common trend with newer langs that all dependencies shall be bundled with the final program's source, what with Go, Rust and Nim providing no way to pull things from a system's central library store instead, let alone dynamic linking, so distributions can have control over the specific library versions that are used. Debian puts a tremendous effort towards doing this for both Rust and Go, but with no good distro-agnostic tooling for this, it's too difficult to manage for other distros. I don't write Zig, but I'm curious as to what its take on this is. Does it go full static no sysdeps final destination, or is it a bit more flexible?

>>21208 >Agreed. Saw a couple CLI projects that were in NodeJS and that physically pained me. Is that really any worse than the Python or Perl scripts your system is filled with?

>Zig Heil! hehe

>>13947 It has async/await these days

What is so good about this language? I just can't see anything new or interesting, plus the syntax is just absolutely horrible, I'd risk to say that is even worst than the C++ syntax.

>>24474 The stuff I like the most is comptime and that the standard library accepts memory allocators as parameters if they even need to allocate memory in the first place. It's useful when you cannot allocate heap memory left and right: you don't have to guess which functions could allocate memory behind you back. I know it's not the most innovative of languages, but I find it comfy. Which leads me to my second point, what do you dislike about the syntax? My only gripe with C++ syntax is templates and types, which are gone in this language (and nearly every modern language is staying clear of C-style type syntax anyway)

>>23744 It's easier when your target isn't a general distribution but rather a single target you need to deploy to in which you have a well defined configuration for. Static compilation means you don't need to care for the dependencies that exist thus won't run into the pitfalls of an update taking out most of production. My use of it (which I've used zig for) is deployment to embeded systems where anything else tends to be a pain. This is the kind that you'd build for using buildroot and sometimes yocto rather than your average distro. With static linking it's as easy as `zig build package-deploy -Dunit-ip=$address` to cross-compile, deploy, test in one go without having to interact with buildroot and other tools. This also works from any machine you have at hand and you're likely to never run into an issue where your program isn't compatible because someone used a different version of the compiler by mistake. Note that such systems are also relatively difficult to reach so a bad update could require a recall or could end in hours of debugging something which works on your side but you forgot that some of the units out there were on a closed network and haven't been updated for 5 years and the customer refuses to perform a full system update as "it's not needed because the device works". Outside of that, it's been fun to have the ability to share something I compiled with someone that doesn't want to build it from source without having to care much about the distro they use.

So... how do I actually get into Zig? Can anyone link me useful resources, live coding that isn't Andrew working on the compiler because I've seen those and they haven't helped, etc. I can see it's potential, I love the idea, but I'm having an awful lot of trouble starting to code in it. So far I've only tried programming in Zig a few times but every time I get frustrated at how little documentation there actually is. It usually already fails at simply reading in a file to use. Apparently right now you should use std.fs.Dir.readFileAlloc, but how do I actually get the Dir for the method. What is the Dir, how do I get an allocator, which one should I use, what does it's interface look like? Is there a function that avoids me having to pass a maximum size? This is just one example of what I'm really confused about.

>>26649 > Can anyone link me useful resources Reading stdlib code and issues is how I ended up learning it. There aren't really any good resources other than the ones on the ziglang.org/learn page and https://zig.news. Another would be to read other's code which you can search github for (this is how I learned) and ask more questions. > Apparently right now you should use std.fs.Dir.readFileAlloc, but how do I actually get the Dir for the method. The way to go about this currently is std.fs.cwd().readFileAlloc(...) unless you use the absolute path variants. Using an allocator is optional but when you need one you should use std.heap.GeneralPurposeAllocator like so: { // start scope // get an instance of the general purpose allocator (this should be done once from main) // here I'm passing the default configuration with `.{}` which is most likely // what you want. (I haven't needed any of the other options) var instance = std.heap.GeneralPurposeAllocator(.{}){}; // get a pointer to the allocator interface (this is what you pass around). // be careful here as moving the `instance` will invalidate the pointer // and cause a crash. There's a proposal to catch such mistakes as compile // errors but it will be a while until it's implemented. const gpa = &instance.allocator; // Read all contents of the file and allocate backing memory. const text = try fs.cwd().readFileAlloc(gpa, "example.txt", 0x7fff_ffff); // note: I don't see an issue with the limit as anything larger than the maximum // should really be using mmap or similar. // cleanup when we leave this scope (that between { and }). defer gpa.free(text); } // end scope > which one should I use If you don't know, the general purpose one is usually the right answer. However, if you allocate a lot of tiny objects in a loop then consider using the ArenaAllocator which defers deallocation to when you destroy the arena itself. Other than that, you'll just have to play around. I've found that the stream interface is easier to use with a fixed buffer in most cases where I would otherwise allocate memory. > what does it's interface look like? You should read the signatures and doc comments for std.mem.Allocator as they're rather well documented compared to most things in std. > This is just one example of what I'm really confused about. Have you considered joining any of the communities? The matrix ziglang room is active and so is IRC where most are willing to help. Otherwise you can ask here and I'll answer when/if I see it.

>>26649 this might be a little late but; check chapter 2 from https://ziglearn.org/

Hey, does anybody knows how to make zig interact with variadic functions?

>>28278 You might be interested in these few links: https://github.com/ziglang/zig/issues/208 https://ziglang.org/download/0.6.0/release-notes.html#Tuples-Added-Var-Args-Removed https://github.com/ziglang/zig/issues/4335

>>28282 That's cool, but how do I call C/asm variadic functions or create what would be variadic functions in those contexts for interfasing with other languages?

>>28286 check https://github.com/ziglang/zig/pull/6272

I'm not really sure Zig has a reason to exist. Functionally speaking it's a thin wrapper over LLVM IR, and bills itself as "simple" language with "no hidden X", and yet I have to write four keywords and some weird punctuation just to declare my entry point. A good chunk of its "safety" amounts to an optional mode where the compiler surreptitiously inserts runtime checks -- I guess "no hidden control flow" was a lie. That aside, all the "safety" is this opt-in granular thing and for the purposes of actually building robust software, that's... questionable. It has a built-in keyword for unit tests. Did you know that most of the reason pervasive unit testing was pushed in the first place was dynamic languages like Python taking off where you had no real assistance from static analysis? By all means, draw your own conclusions, but I have the feeling this is just about as much of a dead end as Nim and V.

>>28608 >Functionally speaking it's a thin wrapper over LLVM IR wrong >bills itself as "simple" language with "no hidden X" >yet I have to write four keywords and some weird punctuation just to declare my entry point. "pub fn main()" instead of "int main()" >optional mode where the compiler surreptitiously inserts runtime checks you have to set a compiler flag to enable the runtime checks. zig makes you choice between "no hidden control flow", which implies certain undefined behaviors, and the "safe" mode, which implies less undefined behaviors >all the "safety" is this opt-in granular thing error handling is not what people often call safety, zig is not a safe language, not even in the safe mode. you can't opt-out of error handling, and I wouldn't call it granular, it's as granular as ordinary c-style error codes >for the purposes of actually building robust software, that's... questionable how so? the rest about unit tests and dynamic languages is false. it was oop langs (java) that normalized exhaustive unit testing

>>28609 >wrong build some zig sometime and tell the compiler to emit ir. sorry but this is pretty self-evident >zig makes you choice between "no hidden control flow", which implies certain undefined behaviors, and the "safe" mode, which implies less undefined behaviors yes, this is a big part of the problem. an entire new language isnt really justified by "it lets us implement ubsan but worse" >how so? look at what's gone into implementing actual guarantees of robustness and correctness modulo spec in practical, real-world high-reliability systems: things like seL4, papers on formal verification from semiconductor manufacturers, machine code generation from F*, ... >it was oop langs (java) that normalized exhaustive unit testing that too -- in general, it fell out of nonexistent (smalltalk, python, ruby) or anaemic (java, c++) static typing "no real assistance from static analysis" applies to all of the above. java and their ilk didnt normalise it in a vacuum; you may as well say "well ACKSHUALLY the term was around since at least the 4th international symposium on software engineering in 1968"

>>28610 >build some zig sometime and tell the compiler to emit ir. wrong again. it can also produce x86. that doesn't mean that it's a thin wrapper over x86 >sorry but this is pretty self-evident chill, no need to argue in bad faith >yes, this is a big part of the problem. >"it lets us implement ubsan but worse" you can't statically detect every possible scenario that could produce UB. one of the interesting parts about zig is how it handles most UBs. it explicitly makes you to decide how you're going to handle the UBs, instead of silently letting them happen. and you can't opt-out of it; that alone makes it better than ubsan. you can disable (or rather, not enable) the runtime checks tho >look at what's gone into implementing actual guarantees of robustness and correctness modulo spec in practical, real-world high-reliability systems: things like seL4, papers on formal verification from semiconductor manufacturers, machine code generation from F*, ... different domain. I thought you would bring up rust's static analyzers, which is the only feasible alternative if you want short execution times in any case, if you can verify c programs, you can verify zig programs. plus the language has more tools to help you and is overall easier to use

The whole Zig "allocgate" thing is so bizarre. If the compiler emits poorly performant code for a specific programming pattern, shouldn't it be the compiler's responsibility and not be forced upon the programmer?

>>29800 Not really. I mean, to a degree it is the compiler's responsibility. However, it is also the programmer's responsibility to a degree to know their tools. C does not enforce tail-call optimization yet GCC can and will do tail-call optimization in certain cases. That being said in there are cases where GCC will not do tail-call optimization so the programmer should have written their recursive solution in an iterative fashion and obtained better performance.

It's nice to see the self-hosted Zig compiler (aka stage 2) maturing. It's not the default compiler yet, but it currently passes 92% of the Zig language tests. They're also compiling the self-hosted version with itself as a test suite, which is pretty neat.

The Zig compiler written in Zig can now completely compile itself to a working binary! It's a pretty good milestone. $ zig build -Denable-llvm $ zig2 build -p build-stage3 $ cat a.zig const std = @import("std"); pub fn main() void { const stderr = std.io.getStdErr(); stderr.writeAll("Hello, world!\n") catch {}; } $ build-stage3/bin/zig run a.zig Hello, world! https://github.com/ziglang/zig/pull/11442

>no closures >anti functional programming sentiment I really wants the Python crowd.

>>21050 > I don't think zig would ever become like that because it doesn't promise your programs to be better just by using it I believe one of Zig's main points is that you can "write-once-build-virtually-everywhere" because you can build runtime-free code, by enabling folk to accept Allocators as an argument, among other things. I conceive this would risk memeing Ziggers (that sounds terrible - Ziggas?) into rewriting everything in Zig, just like Go and Rust.

>>30882 Python actually does have closures, they're just terrible

>>30898 Really? I know nested def (not anonymous) and single expression lambdas, but what about closures?

>>30908 you can do multi-line lambdas its just awkward and yea you can do def def still. or def lambda. or lambda lambda.

>>30890 Ziguanas There's also been focus on zig cc along with integrating more with C through shipping a C compiler even when compiling without LLVM support to promote use of existing libraries where possible. >>30882 Issue with closures is memory, where do you store it? The current way around this is to create a struct with a single `call` method that does the same as a closure would do making closures somewhat unnecessary. As for functional programming, issue is mainly where to store results as zig cannot allocate memory on the behalf of the user. Do note that you can (at present) pretend zig is pure lazy functional programming language at comptime as comptime cannot perform i/o and decls outside of function bodies are lazily resolved.

>>30964 >Do note that you can (at present) pretend Zig is pure lazy functional programming language at comptime as comptime You can also return a pointer to stack allocated memory at comptime. It's explicitly supported, even the Zig compiler takes advantage of it. Ziggers can also capture by value at comptime. fn outer(comptime foo: Foo) type { return struct { fn inner() void { // We can access foo here. } }; }

https://github.com/ziglang/zig/pull/12368 >make self-hosted the default compiler I hope the quality of the compiler improves. Way too many times the compiler fails an assert or just straight up segfaults.

>>13884 how do i accept a HashMap as an argument for my function without writing a longass type?

>>21402 Zig's main advantage over Jai is that it exists. It's been two years since your post, and Jai is still in limbo. Both suffer from the same problem, which is that C and C++ have been around for decades, have much stronger ecosystems, and do everything they set out to do just as well. If Rust is just barely scraping by with support from giant corporations, how the fuarrrk do you expect these languages to get anywhere.

>>33034 Define a type alias. For example: const FooMap = std.AutoArrayHashMap([16]u8, Foo); fn frobnicate(map: FooMap) void { ... }

Finally zig supports iterating over ranges without var count: u32 = 1 << 32; while (count > 0) : (count -= 1) { ... } using for for (0..1 << 32) |count| { ... }

I will start learning this once it reaches 1.0.1

>>34476 That's not going to be happening for a long time, don't hold your breath. Their policy for upgrading from 0.x to 0.y is still "you may have to rewrite everything".