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

91–100 of 246 posts

Re: Zig's Lovely Syntax

#91

Post by n42 »

this is a really, really good article with a lot of nuance and a deep understanding of the tradeoffs in syntax design. unfortunately, it is evoking a lot of knee-jerk reactions from the title and emotional responses to surface level syntax aesthetics.

the thing that stands out to me about Zig's syntax that makes it "lovely" (and I think matklad is getting at here), is there is both minimalism and consistency to the design, while ruthlessly prioritizing readability. and it's not the kind of surface level "aesthetically beautiful" readability that tickles the mind of an abstract thinker; it is brutalist in a way that leaves no room for surprise in an industrial application. it's really, really hard to balance syntax design like this, and Zig has done a lovely and respectable job at doing so.

Re: Zig's Lovely Syntax

#92

Post by hinkley »

flohofwoe wrote: post #9
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 neste…

Thanks for the explanation, but I don’t think you’ve sold me on .x

Think I’d rather do the Point{} syntax.

Re: Zig's Lovely Syntax

#93

Post by brabel »

WalterBright wrote: post #50
WalterBright wrote: post #45

const x: i32 = 92; D has less syntax: const int x = 92; Just for fun, read each declaration out loud.

Zig: const std = @import("std"); D: import std;

I think this is not equivalent because in D, this imports all symbols in the package `std` while in Zig, you just get a "struct" called `std`. I think the equivalent D is:

    import std=std;

Re: Zig's Lovely Syntax

#94

Post by lenkite »

flohofwoe wrote: post #23
Akronymus wrote: post #20

Earlier quoted context omitted.

It's especially bad on a qwertz keyboard as well.

That's why "real programmers" use English keyboard layout regardless of the physical keyboard ;) Curly brace syntax would never have been invented in Europe (case in point: Python and Pascal).

JSON is everywhere nowadays - How can one complain about curly braces {} ? EU programmers would have already mapped {} after their first REST API.

Re: Zig's Lovely Syntax

#95

Post by conorbergin »

z_open wrote: post #54

> Raw or multiline strings are spelled like this: const still_raw = \\const raw = \\ \\Roses are red \\ \\ Violets are blue, \\ \\Sugar is sweet \\ \\ And so are you. \\ \\ \\; \\ ; This syntax seems fairly insane to me.

I think everyone has this reaction until they start using it, then it makes perfect sense, especially when using editors that have multiple cursors and can operate on selections.

Re: Zig's Lovely Syntax

#96

Post by hinkley »

lenkite wrote: post #81
tapirl wrote: post #34

Earlier quoted context omitted.

Normal function declarations. This is indeed a point which makes Zig inflexible.

By adopting a syntax like fn add(x: i32, i32) i32 they have said perma-goodbye to lambdas. They should have at-least considered fn add(x: i32, i32): i32

They could still fix it with arrow functions, but it’s always gonna look weird.

Some other people have tried to explain how they prefer types before variable declarations, and they’ve done a decent job of it, but it’s the function return type being buried that bothers me the most. Since I read method signatures far more often than method bodies.

fn i32 add(…) is always going to scan better to me.

Re: Zig's Lovely Syntax

#97

Post by klas_segeljakt »

z_open wrote: post #54

> Raw or multiline strings are spelled like this: const still_raw = \\const raw = \\ \\Roses are red \\ \\ Violets are blue, \\ \\Sugar is sweet \\ \\ And so are you. \\ \\ \\; \\ ; This syntax seems fairly insane to me.

When I first read it I thought it was line comments.

Re: Zig's Lovely Syntax

#98

Post by brabel »

hardwaregeek wrote: post #10

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/OCa…

If you like C-like syntax and want a functional language that uses it, try Gleam: https://gleam.run/

Quite lovely looking code.

    fn spawn_greeter(i: Int) {
      process.spawn(fn() {
        let n = int.to_string(i)
        io.println("Hello from "  n)
      })
    }
There's also Reason, which is basically OCaml (also compiles to JS - funnily enough, Gleam does that too.. but the default is the Erlang VM) with C-like syntax: https://reasonml.github.io/

Re: Zig's Lovely Syntax

#100

Post by zabzonk »

aeonik wrote: post #30
zabzonk wrote: post #5

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

Not me! I don't like the syntax of Lisps, with the leading parenthesis to begin every expression. I use it anyway because it's so useful and powerful. And I don't have any better ideas.

> leading parenthesis to begin every expression

well, that's not really what it is doing - it is saying apply this function to these parameters.

Post reply on HN