Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig's Lovely Syntax

matklad.github.io

Post reply on HN
Print view View original

1–10 of 246 posts

Re: Zig's Lovely Syntax

#2

Post by do_not_redeem »

Since we're talking syntax... it's mildly infuriating that the zig parser is not smart enough to understand expressions like `const x=a()orelse b();`. You have to manually add a space before `orelse` -- but isn't that what `zig fmt` is for? I have RSI and it's maddening having to mash the arrow keys and add/remove whitespace until the parser is happy.

I've heard the argument that people might confuse binary operators for prefix/postfix operators, but I don't buy it. Who would think an operator named `orelse` is anything but binary?

Re: Zig's Lovely Syntax

#3

Post by phplovesong »

I find Zig syntax noicy. I dont like the @TypeOf (at symbol) and pals, and the weird .{.x} syntax feels off.

Zig has some nice things going on but somehow code is really hard to read, admitting its a skill issue as im not that versed in zig.

Re: Zig's Lovely Syntax

#4

Post by hmry »

do_not_redeem wrote: post #2

Since we're talking syntax... it's mildly infuriating that the zig parser is not smart enough to understand expressions like `const x=a()orelse b();`. You have to manually add a space before `orelse` -- but isn't that what `zig fmt` is for? I have RSI and it's maddening having to mash the arrow keys and add/remove whitespace until the parser is happy. I've heard the argument that people might confuse binary operators…

"Read the file, or else!" The threatening postfix operator

Re: Zig's Lovely Syntax

#6

Post by MrResearcher »

It's still not clear to me how you can make two comptime closures with different contents and pass those as a functor into the same function. It needs to have a sort of VTable to invoke the function, and yet since the contents are different, the objects are different, and their deallocation will be different too. Defining VTable in zig seems to be a pretty laborious endeavor, with each piece sewn manually.

Re: Zig's Lovely Syntax

#7

Post by jeltz »

zabzonk wrote: post #5

In my experience, everyone finds the syntax of their favourite language lovely - I love (mostly) C++.

I am an exception then. Rust may be my favourite language but the syntax is pretty awful and one of its biggest weaknesses. I also love Ruby but I am pretty meh about its syntax.

Re: Zig's Lovely Syntax

#8

Post by pton_xd »

"Zig doesn’t have lambdas"

This surprises me (as a C++ guy). I use lambdas everywhere. What's the standard way of say defining a comparator when sorting an array in Zig?

Re: Zig's Lovely Syntax

#9

Post by flohofwoe »

phplovesong wrote: post #3

I find Zig syntax noicy. I dont like the @TypeOf (at symbol) and pals, and the weird .{.x} syntax feels off. Zig has some nice things going on but somehow code is really hard to read, admitting its a skill issue as im not that versed in zig.

The dot is just a placeholder for an inferred type, and IMHO that makes a lot of sense. E.g. you can either write this:

    const p = Point{ .x = 123, .y = 234 };
...or this:

    const p: Point = .{ .x = 123, .y = 234 };
When calling a function which expects a Point you can omit the verbose type:

    takePoint(.{ .x = 123, .y = 234 });
In Rust I need to explicitly write the type:

    takePoint(Point{ x: 123, y: 234);
...and in nested struct initializations the inferred form is very handy, e.g. Rust requires you to write this (not sure if I got the syntax right):

    const x = Rect{
        top_left: Point{ x: 123, y: 234 },
        bottom_right: Point{ x: 456, y: 456 },
    };
...but the compiler already knows that Rect consists of two nested Points, so what's the point of requiring the user to type that out? So in Zig it's just:

    const x = Rect{
        .top_left = .{ .x = 123, .y = 234 },
        .bottom_right = .{ .x = 456, .y = 456 },
    };
Requiring the explicit type on everything can get noisy really fast in Rust.

Of course the question is whether the leading dot in '.{' could be omitted, and personally I would be in favour of that. Apparently it simplifies the parser, but such implementation details should get in the way of convenience IMHO.

And then there's `.x = 123` vs `x: 123`. The Zig form is copied from C99, the Rust form from Javascript. Since I write both a lot of C99 and Typescript I don't either form (and both Zig and Rust are not even close to the flexibility and convenience of the C99 designated initialization syntax unfortunately).

Edit: fixed the Rust struct init syntax.

Re: Zig's Lovely Syntax

#10

Post by hardwaregeek »

Everyone agrees that "syntax doesn't matter", but implicit in that is "syntax doesn't matter, so let's do what I prefer". So really, syntax does matter. Personally I prefer the Rust/Zig/Go syntax of vaguely C inspired with some nice fixes, as detailed in the post. Judging by the general success of that style, I do wonder if more functional languages should consider an alternative syntax in that style. The Haskell/OCaml concatenative currying style with whitespace is elegant, but sufficiently unfamiliar that I do think it hurts adoption.

After all, Rust's big success is hiding the spinach of functional programming in the brownie of a systems programming language. Why not imitate that?

Post reply on HN