Wouldn't these be better off as "zig init lib" and "zig init exe"? I.e. do what git did when it switched from stuff like "git-annex" to "git annex": switch from compound command names to subcommands. Easier mentally to follow and remember.
There's also this:
> all control flow occurs exclusively via keywords.
This will probably never happen cause C looms too large in Zig's world, but I wish "*" and especially the super non-intuitive "&" go the way of the dodo and some short keywords replace them. Perhaps "ptr" and "deref"? This is technically just bikeshedding, but look at Rust threads: besides the obvious #1 difficulty of the borrow checker and ownership, the #2 complaint is that the syntax is weird due to sigils. "Modern" programming languages don't use many sigils, if any: Javascript, Python, Java, C#, etc.
It's not fair since those languages are GCed, but most people will be familiar with them, not with C, these days.
I know that it's doubly unfair since Zig's target is C, so it's expected that new Zig developers know C, but you want to get new developers wherever you can get them, in my opinion :)
The sigil thing is definitively a bikeshed. For one thing besides Python I don't don't know why you consider that JS, Java or C# don't use many sigils, these languages just happen not to have C-style pointers so they don't need that particular bit of syntax.
More generally using C-style syntax means that C and C++ coders will be at home, while people from other languages will have to familiarize themselves with the concept anyway, sigil or not.
Beyond that, I don't think I've seen any serious study on the acceptable level of sigils to maximize productivity and readability in source code, as far as I can tell it's really just a matter of opinion. Personally I'd take C syntax over Python every day of the month, and I've written quite a bit of Python. My only sigil-related problem with C is that '->' should really just be '.' IMO.
There's was a talk at StrangeLoop a few years back about a language syntax being designed based on user feedback from its ongoing usability studies. I'm on my phone now, but I'll try to find and post the link later when I'm at my computer if someone else doesn't find it first.
> his will probably never happen cause C looms too large in Zig's world, but I wish "*" and especially the super non-intuitive "&" go the way of the dodo and some short keywords replace them. Perhaps "ptr" and "deref"?
Well, I was expressing more of a personal preference but I can't miss the opportunity to take a jab at Stroustroup, even if the rule seems good and valid, something went astray when he designed C++, so I guess Rule[0] was ok, the problem was with rules [1] to [99] :p
On a more serious note, I think that this word form is concise enough and might emphasize code smells in a more modern language, where stuff like * *a should be super rare, IMHO.
So happy to see this language develop rapidly. I want Zig for simple, rapid and fun microcontroller development. There's just no satisfying options right now.
I played around with it some months ago. It was an adventure so to speak. Even discovered bugs in LLVM itself. Andy was very responsive to bug requests, so I got a demo working pretty quickly.
I'm hoping to do another pass soon, perhaps contribute a bit to the compiler.
I've had fun writing some stuff in CircuitPython [0] (a fork of MicroPython mostly geared towards Adafruit microcontroller boards). At the moment it is geared more towards educational and hobbyist uses, but there is a quite a bit you can do with it.
> Zig intends to be so practical that people find themselves using it even if they dislike it.
feels awfully condescending to my ears personally, in an I'm-smarter-and-know-better-than-you kind of way, even if you didn't intend it like that.
Just my unsolicited $0.02, but I'd recommend a more objective and non-loaded description something along the lines of "Zig's primary motivation is practicality, and therefore avoids issues with C such as <x, y, z>".
Can anyone with more experience/understanding of Zig give an elevator pitch about why and when I would use Zig? I love the concept of a low level language that's not C, but the home page doesn't paint a clear picture to me about what its strengths are and in what situations it really shines, and what trade-offs it makes to get there.
The short of it is C without the warts plus a few small quality of life improvements.
The long of it: The competition right now in this space as I see it is: C, Rust, C++. Even C++ doesn't fully fit because you have to turn off language features like exceptions to have the guarantees you need for systems programming. So in turn.
C hasn't really changed in 40 years so all it's warts are still intact and has specific pain points that will never be addressed.
C++ conversely has added every language feature plus the kitchen sink over the past 30 years. People say: "Just don't use the features you don't want", but that is unrealistic when you have to interoperate with third party libraries etc. If you have to drop a large portion of the C++ ecosystem to use the subset of the language you like then you've lost a major benefit of choosing C++ in the first place.
Rust, while being more thoughtful about it than C++, has provided a large set of features to work with. It is a much bigger language than C. It's also taken a very opinionated stance on safety with the borrow checker which causes a large learning curve and a lot of mental overhead.
Finally Zig is an attempt to be more safe than C where it can without being as overbearing as Rust. Add just the necessary features that a huge boost to quality of life while not flooding the programmers mental model of the language. I think of it as kind of a C+.
I know that is superficial, but although Rust has many great features it looks too much like C++ for me. All those :: and template<likes> are making it look too busy for me. Also type inference looks a bit too powerful - it may make things easier to write, but harder to read.
Personally I cheer for Zig and think that it has the biggest potential to really become a C replacement for me. Other then that I hope that Myrddin [0] will see stable development till 1.0 and beyond. Myrddin has my vote, because it uses QBE [1] compiler backend instead of LLVM. Now that I think about it it would be cool to see Zig on QBE. I just don't think that the current LLVM monoculture is healthy in a long run.
Maybe I'm weird, but I would like to imagine a language like Zig compiled also to DEX for Android and CIL for Windows. Then it could have mostly free platform-native calls. So one could really write truly first-class cross-platform apps.
> Text input only. A C library interface is work in progress.
this is a bit of a non-starter
> Some ongoing work on the Myrddin compiler aims to use QBE as backend.
sounds like myrddin does not use QBE as a backend.
----
It is unlikely that Zig will ever use QBE as a backend, optional or otherwise. However, it is quite possible that in some distant future Zig has its own backend that avoids the LLVM dependency entirely. This would be in pursuit of fast compile times.
Oh. You're right. My bad. I thought that they are pretty focused on QBE switch and as Myrddin is still in quite early phase of development I thought it's not much of a difference. Well looking at public commits in main branches it seems that QBE development is not really active. Too bad. I hope that there's a flame remaining. I'm not tracking mailing lists either.
It's great to hear that a home grown backend is something even considered for future. I know that it's a long way there, but that's life.
Thank you for your efforts with Zig. From all the new systemish languages I find Zig with it's current momentum the most probable to become the C replacement for me.
> It imposes design constraints that in the end work out for the better.
I feel the jury is still out on this. It does impose design constraints that remove a certain subclass of errors, whether this correlates to actually causing better designed programs in the sense of readability, maintainability, etc. I'm unsure. I understand the desire for this to be true and I feel that some of the fanaticism around the language is the belief that this is true. Developers like to have the 'one true way' to solve problems. Go's popularity I feel is in part because of this as well but achieved it by having a bare bones language with less options instead of a restrictive compiler. If you take the 'restrictive compiler' argument to its logical conclusion for a program that accepts input x and produces output y there would only be one valid way to code this program. This would be good in the sense that presumably the compiler has proven that your program works and is correct. On the other hand though I have no inclination to believe that this program would be the most understandable, modifiable way to get from x -> y.
Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve, which can be confusing and counterproductive when choosing a language because of the classes of errors it aims to solve (often a big motivator in both designing and choosing a language; see Swift and Go).
This is only true in cases where a single ownership model makes sense. In cases where it doesn't, there is a definite overhead. I think even the strongest Rust advocates would not deny the existence of this overhead. They'd just point out that you'd have the same overhead in C++, but without the compiler helpfully telling you when you've made a mistake.
I'd also add that there are (small) warts on Rust's current implementation of borrow checking which everyone agrees are minor annoyances, even to experienced users:
"If you have to drop a large portion of the C++ ecosystem to use the subset of the language you like then you've lost a major benefit of choosing C++ in the first place."
But, it'll still be orders of magnitude larger than the Zig ecosystem is likely to be anytime in the next couple of decades.
I'm not saying one shouldn't use Zig or that one should use C++...I've never been able to grok C++, as it is far too large for the small amount of time I have to spend on learning about systems languages (I can barely read it, much less write it effectively). I just think it's weird to argue for Zig with a point about ecosystem size. Zig will likely never look good on that metric, compared to C or C++.
the amount of development described in detail the release notes is simply amazing. thanks for your work and i'm excited to see zig continue to progress.
If anyone is interested, I'm using Zig full-time. I switched from C# to C++ for game development but I had immense difficulty accepting the language, so when I heard of Zig I gave it a go and I've been very happy with it.
This is a serious project that I'm working on. The 'engine' uses the Vulkan graphics API, cache efficient design, scales to the number of cores, game logic is multithreaded, AVX is used, and so on.
I only mention this to hopefully get people interested in Zig. I'm not ready to share screenshots yet and I'm certainly not going to be advertising my game here.
I've followed Zig's progress with some enthusiasm, but would have considered it too immature for a serious project at this point. In that vein, a few questions about your experience:
1) What's your workflow like in terms of tooling? Coming from C# and C++ people are typically used to great IDE support, debugging and profiling tools, etc. Zig doesn't have any of that. How do you work around it and do you find the experience reasonably productive?
2) How do you deal with the language still rapidly evolving? Do you run the latest nightlies or freeze a particular compiler version and update periodically?
3) What are the most important things Zig gets you over the traditional gamedev approach of using a restricted subset of C++ (in some cases literally just C with function/operator overloading for basic math and a few other convenience features)?
1) When I programmed in C++ I was using Vim and the YouCompleteMe plugin for IDE-like features. Now I use Vim + CTags. For CTags I use the following which uses the Zig standard library to parse Zig code: https://github.com/isaachier/ztags. In the future there will be support for the Language Server Protocol.
2) I git pull every few days to run on the latest compiler. The bugs that I've hit have been minor inconveniences, nothing serious. I think Andrew would agree with you though that Zig is probably too immature for a serious project at this point. The transition to the self-hosted compiler has yet to take place, that compiler is in its infancy.
3) I'm afraid that my verbal inability will never do Zig justice. The built in slices and optionals are really nice. Pointers are non-null by default (but can be undefined). Stack traces on crashes. Much better casting in my opinion (once I got used to it). Error handling that's similar to Herb's C++ deterministic exception proposal. No headers. Not having to decide between fast compile times and comfortable printing. Defer statements instead of destructors or nothing work really well in my opinion. Built in testing (maybe not something you use much in gamedev). +% means add with overflow, + means overflow is undefined. Everything feels nicer, that's as good as I can put it.
edit: You can Ctrl+F "pub fn" to browse all public functions. Great when browsing Github. It's easy to grep for the definition of anything. Overflow and other undefined behavior is detected in debug mode, this saves me so much time. Guaranteed inline is nice. No more make/cmake and manually listing which files to compile.
Thank you for the detailed responses. One, possibly silly, followup question, since you mentioned using AVX. If I understand correctly, Zig deliberately avoids macros, metaprogramming and doesn't have operator overloading. Given those limitations, how do you deal with vector math over different SIMD widths without insane verbosity? I feel like I'd be tempted to write a simple code generator before starting on something like that.
For SIMD I'm using ispc which is a shader-like language/compiler from Intel. You write your code from the point of view of a single SIMD lane and the compiler takes care of the rest. Intel kind of screwed the project over with their stupid naming and terrible website but it's a very cool project. I take the resulting object file and link it with the rest of the project. This is very different from trusting a compiler to vectorize your code, with a shading language you know it's going to vectorize. What's absolutely brilliant is when you start to use divergent control flow and see how well it handles it.
I am very interested. I support Zig on Patreon, because I really believe Andrew has hit the sweet spot when you are looking at staying with C, or C++, or moving on to Rust, but can't quite get it. I have been playing recently with Lua/Terra for game dev stuff (scriptable and low-level, but no big user base yet), but I am really a Lisp guy. Zig may help me to bridge a few of my toy program ideas and aspirations to go bigger as you have.
I tried, and really liked Nim, and I believe the custom GC settings would allow for game dev for the types of games I try and make, however, I am biased against the sort of Python syntax and prefer Lisps or standard C-style syntax. This is totally subjective. I can't speak to Go or Crystal, although Go looks like C to me!
Heh, if you ever came into a place that had used Zig and we're now transitioning to a different language, your job would be to--literally--"remove all Zig".
Two minor things:
> zig init-lib and init-exe
Wouldn't these be better off as "zig init lib" and "zig init exe"? I.e. do what git did when it switched from stuff like "git-annex" to "git annex": switch from compound command names to subcommands. Easier mentally to follow and remember.
There's also this:
> all control flow occurs exclusively via keywords.
This will probably never happen cause C looms too large in Zig's world, but I wish "*" and especially the super non-intuitive "&" go the way of the dodo and some short keywords replace them. Perhaps "ptr" and "deref"? This is technically just bikeshedding, but look at Rust threads: besides the obvious #1 difficulty of the borrow checker and ownership, the #2 complaint is that the syntax is weird due to sigils. "Modern" programming languages don't use many sigils, if any: Javascript, Python, Java, C#, etc.
It's not fair since those languages are GCed, but most people will be familiar with them, not with C, these days.
I know that it's doubly unfair since Zig's target is C, so it's expected that new Zig developers know C, but you want to get new developers wherever you can get them, in my opinion :)