Live data from Hacker News

Zig: The Modern Alternative to C

infoworld.com

121–130 of 181 posts

Re: Zig: The Modern Alternative to C

#121

Earlier quoted context omitted.

> pretty much all operating systems and fundamental C libraries expect strings to be zero terminated C libraries are going to mostly be like that because it's how C works. If that's our high bar we're never getting anywhere. Operating systems don't use many strings -- strings are awful because they're variable size and need parsing. Filenames are the most obvious place the kernel needs strings, and here the 0 termina…

GP made a great point and I get the impression you're fighting really hard to ignore reality. Idealistic thinking doesn't win the practical exams. Zero-terminated strings are a fact of life and essential to using many useful APIs. Like it or not, if a new ecosystem wants adoption it had better interoperate with the established ones without much friction. Apart from that, zero-terminated strings aren't strictly bad. T…

I've been on both sides of this fence, decades writing C before I wrote any Rust - and no, IMNSHO the Yak barbering necessary is much more extensive and annoying with zero terminated strings.

The on-disk fixed size structure stuff is actually nicer in a language that favours slices, because with C-strings we're incurring a special case, what happens when the sub-structure is full? With slices that's just fine, but with zero termination that's not a valid string (because the sentinel is missing) and so you have to decide what to do about that.

Re: Zig: The Modern Alternative to C

#122

I tried using Zig for a little bit, and it just doesn't feel ergonomic to use _for me_. It's not 1.0 so I'm hoping that a lot of that will be ironed out, but some of it is baked into the language. Being forced to assign variables to _ if you aren't using them somewhere else in the program annoyed me a lot more than I expected. Especially in the learning phase when you are asking a lot of questions and have to write u…

var arr: [30_000]u8 = undefined; for (&arr) |*x| x.* = 0;

That sounds like a loop.

Re: Zig: The Modern Alternative to C

#123

I tried using Zig for a little bit, and it just doesn't feel ergonomic to use _for me_. It's not 1.0 so I'm hoping that a lot of that will be ironed out, but some of it is baked into the language. Being forced to assign variables to _ if you aren't using them somewhere else in the program annoyed me a lot more than I expected. Especially in the learning phase when you are asking a lot of questions and have to write u…

var arr: [30_000]u8 = undefined; for (&arr) |*x| x.* = 0;

  var arr = std.mem.zeroes([30_000]u8);
P.S: Not a loop. The implementation of std.mem.zeroes for an non-sentineled array is:

  return [_]info.child{zeroes(info.child)} ** info.len;
Which in this case will be equivalent to:

  return [_]u8{0} ** 30_000;
Which uses the comptime-only `*` operator to expand the single-item u8 array with value 0 into an array of 30k 0s.

Re: Zig: The Modern Alternative to C

#124
post #46

Does Zig still have that insane compiler enforced no unused variables policy? Honestly, that is such a stupid thing that it literally kept me away from the language, which I otherwise find interesting for its niche.

I think forgetting to assign a variable to the return value and ignoring the return value are two different things.

Zig regards forgetting to assign a variable to a return value as a compile time error because there's an entire class of bugs that stem from it, e.g. resource leaks.

Re: Zig: The Modern Alternative to C

#125

Earlier quoted context omitted.

Short answer: not exactly, no. Long answer: Zig does a lot of stuff to make the easy way of dealing with memory the correct way. The typical pattern is to use defer/errdefer statements to clean up on end of scope or in case of error. One of the included allocators checks for leaks and use after free, and it is trivial to change which allocator is used based on build mode. It is also very strict about pointers and has…

Longer answer: I think it's inevitable that someone will write a static checker for lifetime analysis.

That’s pretty much impossible in the general case, thanks to Rice’s theorem. Rust can only do so because it limits the possible lifetime “shapes”.

Otherwise why don’t build it for C instead?

Re: Zig: The Modern Alternative to C

#126
post #87

Is zig used for Linux kernel at all?

I should hope not. Zig is not even 1.0 yet, using it on anything as relied upon as the Linux kernel would be a bad idea.

That said, I do all my projects in it these days if I can get away with it because I like it so much and it is reliable enough for me... well, except for the fact that the current master doesn't actually implement suspend/resume yet and I use that for coroutines.

Re: Zig: The Modern Alternative to C

#129
Tried Zig over a weekend, liked it, but not going to use it in real projects, yet.

Two concerns to remain for me:

    * version 1.0 release
    * bus factor, the major contributor seems still mainly a single person
I hope it can take off soon.

Re: Zig: The Modern Alternative to C

#130

const std = @import("std"); pub fn main() !void { const stdout = std.io.getStdOut().writer(); try stdout.print("Hello, {s}!\n", .{"world"}); } To me, this looks worse than anything I have seen before.

Alternatively:

    const print = @import("std").debug.print;

    pub fn main() void {
        print("Hello {s}!", .{"World"});
    }
Or using the logging API:

    const info = @import("std").log.info;

    pub fn main() void {
        info("Hello {s}!", .{"World"});
    }
(I'm actually not sure why Zig doesn't have a simple way to print to stdout, but I guess there are 'reasons')
Post reply on HN