Live data from Hacker News

Zig 0.5.0 Release Notes

ziglang.org

61–70 of 80 posts

Re: Zig 0.5.0 Release Notes

#61
post #16

Earlier quoted context omitted.

You can use any c libraries networking or socket implementations in zig but I think thats as far as it goes at the moment.

Can you though? I cant get cURL to work: https://github.com/ziglang/zig/issues/988

After a few minutes of trial and error (mostly around convincing Zig's type checker that various things are indeed enum members, and fixing cases where the C version outright ignores return values), I was able to produce a working example:

    // 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);
        }
    }
Buildable with "zig build-exe curl-test.zig --library c --library curl" (I have to add "-isystem /usr/include --library-path /usr/lib64" to the end of that on Slackware64 14.2; YMMV). Should produce a runnable "curl-test" (or "curl-test.exe") binary executable in the current dir.

Re: Zig 0.5.0 Release Notes

#62
post #29
post #2

It's an exciting week for programming languages. First Nim, then Zig. Keep up the great work!

Does anyone here have a good understanding of the relative merits of Zig, Crystal, and Nim? Especially compared to higher profile languages like Rust and Go? 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, performan…

Having looked at all three, I've so far settled on Zig for a couple reasons:

- 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)

Re: Zig 0.5.0 Release Notes

#63
post #60
post #3

Earlier quoted context omitted.

And Crystal! https://crystal-lang.org/2019/09/23/crystal-0.31.0-released....

I wonder why scrolling is broken once the page fully loads.

Seems to be fine on Firefox (both with the mousewheel and arrow keys).

Re: Zig 0.5.0 Release Notes

#64
post #57

At the very first glance: what is wrong with function xxx() instead of fn xxx() what are we trying to save here? 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.

The @ indicates that the function's built into the compiler itself. Yeah, it looks ugly, but it's nice to be able to visually identify "okay, yeah, this didn't come from any of my imports", and also (I'd assume) avoids cases where one might inadvertently shadow them with their own function definitions.

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.

Re: Zig 0.5.0 Release Notes

#65
post #59
post #54

Earlier quoted context omitted.

I would, first of all, call bullshit on this claim. A language can't be "faster than C". Comparing a good implementation with a bad C implementation is where these claims come from.

You can dispute Zig, but in practice there is FORTRAN that is faster for many math procedures.

Yea. It's always funny when people say C is faster than Fortran for scientific computing. I mean, it's true, but only for a very limited amount of people who want to do serious numeric work. C/C++ certainly aren't rare in this area, but Fortran is pleasant to work with for most numeric work and has lots of helpful built-ins and runs close to C in speed.

Re: Zig 0.5.0 Release Notes

#66

Earlier quoted context omitted.

We do the same thing in Rust, but I think that characterizing this as UB is misleading, personally. We created a new category, "program error", for this, to distinguish from UB proper. I'm not sure if Zig inherited the defined/implementation defined/undefined hierarchy from C and C++ though.

Undefined as in undefined by language spec. There are various processor implementations that have different results that are often quite useful. Would you preclude their use?

Right, the key here is that the behavior is defined. That’s why calling it “undefined behavior” is misleading.

Re: Zig 0.5.0 Release Notes

#67
post #10

Earlier quoted context omitted.

Zig + UEFI = Comic Neue in the BIOS. [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.

> Comic Neue For the uninitiated: http://www.comicneue.com/ As far as Comic Sans-like fonts go it's quite nice

It's currently my main UI font: https://imgur.com/cTLq6Oo.png

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).

Re: Zig 0.5.0 Release Notes

#68

Earlier quoted context omitted.

Undefined as in undefined by language spec. There are various processor implementations that have different results that are often quite useful. Would you preclude their use?

Right, the key here is that the behavior is defined. That’s why calling it “undefined behavior” is misleading.

It is defined if you want to restrict where your program runs.

Re: Zig 0.5.0 Release Notes

#69

Earlier quoted context omitted.

Right, the key here is that the behavior is defined. That’s why calling it “undefined behavior” is misleading.

It is defined if you want to restrict where your program runs .

If something is defined or not is a property of the language specification, as you stated.

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.

Re: Zig 0.5.0 Release Notes

#70
Zig, Crystal, Nim, Rust, Go. It seems like the industry is responding to the end of moores law and is refocusing on performance. Contrast this with 90's languages like python, ruby, java and c# where computers were expected to get exponentially faster and they focused on developer ergonomics instead.

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.

Post reply on HN