Zig 0.5.0 Release Notes(ziglang.org) |
Zig 0.5.0 Release Notes(ziglang.org) |
Out of curiosity, what's the state of the world regarding Zig's stdlib? While the base language docs seem like they're in a pretty good state, the stdlib is still largely undocumented. Is this because it's unstable? Or is the lack of docs there due to lack of time/resources? Would love to get some clarification. Thanks!
[1]: https://ziglang.org/download/0.5.0/release-notes.html#toc-UE...
[0] https://twitter.com/andy_kelley/status/1176561072398098432
Perhaps I could see some toy ransomware bootkit demanding the user to pay up or face using your computer with comic neue or comic sans as the default unchangeable font.
For the uninitiated:
As far as Comic Sans-like fonts go it's quite nice
[1] https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Al...
There is really only one thing that I would say goes beyond keeping the language simple as possible: the async stuff. But I think it will probably be totally worth it. The async implementation looks a lot more elegant than anything I've seen so far, and it could be extremely useful in the embedded world, which is one of the places where C is dominant. It might make the language a bit more complicated, but it will make the resulting code much more simpler for a lot of applications, without compromising other goals like safety and efficiency.
Zig is still much, much closer to C than C++. If you don't think so, then you're vastly underestimating the complexity of C++.
make a feature unwanted in C, worse. nice.
These kinds of claims make me so dubious for a language. Also who is trying to switch from C to get an ever-so-slightly performance improvement? That use-case goes to specialized hardware such as FPGAs.
* The reference implementation uses LLVM as a backend for state of the art optimizations.
* What other projects call "Link Time Optimization" Zig does automatically.
* For native targets, advanced CPU features are enabled (-march=native), thanks to the fact that Cross-compiling is a first-class use case.
* Carefully chosen undefined behavior. For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. This facilitates optimizations that are not available in C. Zig directly exposes a SIMD vector type, making it easy to write portable vectorized code.
So the argument is "exact same compiler as C/C++, but more opportunities for optimization thanks to better semantics and better access to native instructions". This seems reasonable on its face, so care to elaborate on the doubt?
The arguments for not switching from C are often performance or target related, so a language that purports to be an alternative to C would want to point out that those issues aren't a problem.
The reasons to switch away from C are numerous and well documented.
Huh, that's a strange choice. What's the safety story for Zig? Are these always undefined, or is that only in an "unchecked" build?
https://github.com/ziglang/zig/issues/2007
I wonder though, does it already have socket support? that could be a stopgap for me. Edit, looks like it doesnt have sockets either:
https://github.com/ziglang/zig/issues/1271
Edit 2, looks like it does:
https://github.com/ziglang/zig/blob/5026db1d/lib/std/net.zig...
https://github.com/ziglang/zig/blob/5026db1d/lib/std/os.zig#...
example: https://github.com/donpdonp/zootdeck/blob/master/src/net.zig
For me this is sort of important because languages not having standard coding style end up 10000 coding styles. Rust fmt is an excellent example for avoiding that. Does anybody use Zig + fmt?
I know they have something. https://github.com/ziglang/zig/issues/1523
The end even has a link to a web-based version of it.
I'm curious about the tools zig offers around doing asyc work while guaranteeing certain invariants, and how the @Frame builtins work with that, but I'm guessing that's going to be elaborated on in a future post.
I'm quite enjoying watching progress updates, relevant examples and Q&A :)
Can we have a consistent function notation
fn name(a: int, b: int) -> void {}
This also helps with clean functional type arguments.
swift and rust support this.
A single consistent notation will be helpful for new polyglots.
Can anyone familiar with zig tell me how well it works with more macro heavy libraries? Something like GTK (https://developer.gnome.org/gtk-tutorial/stable/c450.html) or something with generics.
function xxx()
fn xxx()
Also would be nice to do import instead of @import. More readable I think.
Afraid to dig deeper as I do not have time to play with the languages that I can not yet use in production.
Re: fn v. function (v. fun v. def v. defun v. defn v. define v. proc v. sub v. label v. the cornucopia of other options here): I don't think it's all that big of a deal. fn does happen to be short, which means more actually-useful information can fit into the same line, so I guess that's nice. The choice of keyword for function definition feels like a really weird criticism.
All of these languages seem to be statically compiled, and they all seem to promise both performance and safety. Rust and Go are discussed all the time on HN, so I expect most of us here have a reasonable notion of their relative benefits, for example, performance compared to ease of learning.
What about these lesser discussed languages Zig, Nim, and Crystal? Are their runtime performances comparable to one another? Are they equally safe to program in? What are their relative strengths? Or does it just come down to syntax preference?
I think there's value in having a lot of choices to program in, so I'm not asking which language is "best" any absolute sense. We're better off for having all of these languages coexisting. I'm just asking if anyone with experience in the three of them has any insight or impressions of their relative merits.
I think in the end it's really up to your tastes which you prefer. Have a look at the tenets of each of the languages and see which resonates with you.
- Cross-compilation is trivial (I haven't dug too deeply into the cross-compilation story on Nim and Crystal, but Zig's is front-and-center)
- Allocations are explicit (functions that require allocating memory do so by accepting an allocator as an argument)
- Windows support seems to be better than with Crystal (which means I can use Zig for desktop programming for my dayjob, since at work most of the PCs here run Windows 10; not that I would at the moment, given that it's very much not production ready yet, but still)
- I strongly dislike Python's syntax, and therefore strongly dislike Nim's syntax (I also somewhat dislike C's syntax - and therefore Zig's - but not nearly as strongly)
- Zig's build system is pretty great (albeit not exactly intelligent when it comes to finding system header and library paths, I've noticed)
That said, there are some downsides to Zig that I'm hoping can be resolved (whether by someone else or - if I get comfortable enough with it - myself):
- Profound lack of standard library documentation
- I like Crystal's syntax better
- C++ interoperability is practically nonexistent (though it might be possible to write small C++ shims that link against Zig-outputted headers; not sure if Zig's included C compiler can compile those, but if it can, then this would be easy to integrate into the build process)
Pairs nicely with Fantasque Sans Mono (though if there was a more Comic Sans/Neue-like typeface, I'd set that as my terminal/editor font in a heartbeat).
// curl-test.zig
// Direct hand-translation from curl's simple.c example
usingnamespace @cImport({
@cInclude("stdio.h");
@cInclude("curl/curl.h");
});
pub fn main() anyerror!void {
var curl = curl_easy_init();
var res: CURLcode = undefined;
if(curl != null) {
_ = curl_easy_setopt(curl, CURLoption.CURLOPT_URL,
c"https://example.com");
_ = curl_easy_setopt(curl, CURLoption.CURLOPT_FOLLOWLOCATION, c_long(1));
res = curl_easy_perform(curl);
if(res != CURLcode.CURLE_OK) {
_ = fprintf(stderr, c"curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
}
curl_easy_cleanup(curl);
}
}
But yes, now it is Zig's time! I'm happy for all of them.
Use plain object and you are on the stack Use ptr object and you can use any allocator you want (Nim's default, malloc/free or jemalloc, mimalloc, ...) Use ref object and your reference will be managed by the GC.
In terms of GC, you the default is deferred reference counting (no ref counting if object is created and destroyed at the end of the scope). It accepts real-time and max-pause tunings parameters, to allow it to stay beyond those 60FPS / 144 FPS requirements
You can also choose java-like mark-and-sweep, the Boehm GC, the go GC, or no GC and get a warning everytime you try to use a type that uses the GC.
In other words, the compiler will enforce that `a + b` does not overflow through all your testing and wherever you explicitly say such checks are required, but turns them into nops for you when you desire speed. You can let the compiler know that you explicitly want wrapping overflow (and not some undefined kind) using the wrapping operator `a +% b`.
But yeah, the use case ain't to work with C++ code I've written (if I'm writing it, then my goal is to write as close to zero lines of C++ as possible ;) ), but rather to work with third-party C++ codebases that do not expose a C-compatible API (or do so poorly).
- to map cleanly with what compilers know to optimize best
- fine control over stack and heap allocation
- has intrinsics / assembly escape hatch
- allows you to specify that pointers don't alias (restrict in C, or default in Fortran)
- gives you prefetching primitives
You will be able to reach hand-tuned Assembly-like performance (and not just C-like performance).
Case in-point, I tuned my own matrix multiplication algorithms in Nim to carefully control register allocations, L1, L2 and L3 cache usage, and vector intrinsics to reach the speed of assembly tuned OpenBLAS and Intel MKL-DNN (no assembly at all):
bench: https://github.com/numforge/laser/blob/c7ddceb0/benchmarks/g...
code: https://github.com/numforge/laser/tree/c7ddceb0/laser/primit...
And matrix multiplication has decades of research and now dedicated hardware (tensor cores, EPU, TPU, NPU, ...) as this is a key algorithm for most numerical workloads.
Why not? For instance, with current hardware, the good use of SIMD is critical. If you can't write vectorized code in (standard) C while you can do it in another Language, that would be a "faster" language. Same for other language features that enable faster code: Compile-time computations, better memory model with different pointer aliasing semantic, ...
Actually you can use just plain (stack) objects and ptr object and you have no GC involved.
Pass the flag -d:useMalloc (or just call your preferred allocator) and you have the full C experience and speed.
It is. The GC is inline, thread-local and can be run manually, disabled completely, or switched to the new owned reference.
I think there's a good answer to this which is, "because people really, really need documentation." So I am kicking around ideas of how this can be done without too much duplicate effort.
This may seem like a weird place to draw experience from, but in my early days of programming, I've found the PHP docs extremely helpful largely thanks to community comments sections giving examples of how to do various things. Just some food for thought.
One of the tenets of my development process with Zig is "avoid local maximums". A wiki for std lib documentation is not the long term solution to the problem, and so I won't be investing any time into it. All my time is invested in the long term solution.
So, while it is technically correct to say that it has undefined behavior for overflow, the practical reality is quite different.
I'm not sure if Zig inherited the defined/implementation defined/undefined hierarchy from C and C++ though.
As well as some followups to see if Zig can detect all of these errors: * https://github.com/ziglang/zig/issues/1966 * https://github.com/ziglang/zig/issues/2301
What you’re now bringing up is something different: should a specification define this behavior, or not? I think you’ve properly identified a trade off, but mid-identified the details. Defining a behavior here does privilege certain architectures, but it doesn’t make it impossible. It means the behavior must be replicated in code on some architectures, which is slower.
This is the trade off that Rust (and apparently Zig) are making. This is informed by the architectures that exist, and which ones are wished to support. At this point, two’s compliment is overwhelmingly used, and so the decision was made that defined behavior is worth it. Note the parallel here with POSIX specifying that CHAR_BIT must be set to 8.
Notably, the situation here is so overwhelming that even C++ is specifying two’s compliment: C++20 says that signed integers must be. This was recently voted in. I haven’t read the paper recently and I don’t remember if it changes the UB rule here or not, but it does define the representation of integers, a very similar thing that’s the motivation for UB here.