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

11–20 of 246 posts

Re: Zig's Lovely Syntax

#12

Post by bscphil »

> Like Rust, Zig uses 'name' (':' Type)? syntax for ascribing types, which is better than Type 'name'

I'm definitely an outlier on this given the direction all syntactically C-like new languages have taken, but I have the opposite preference. I find that the most common reason I go back to check a variable declaration is to determine the type of the variable, and the harder it is to visually find that, the more annoyed I'm going to be. In particular, with statically typed languages, my mental model tends to be "this is an int" rather than "this is a variable that happens to have the type 'int'".

In Rust, in particular, this leads to some awkward syntactic verbosity, because mutable variables are declared with `let mut`, meaning that `let` is used in every declaration. In C or C++ the type would take the place of that unnecessary `let`. And even C (as of C23) will do type inference with the `auto` keyword. My tendency is to use optional type inference in places where needing to know the type isn't important to understand the code, and to specify the type when it would serve as helpful commentary when reading it back.

Re: Zig's Lovely Syntax

#13

Post by do_not_redeem »

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…

Zig is planning to get rid of explicit `T{}` syntax, in favor of only supporting inferred types.

https://github.com/ziglang/zig/issues/5038

So the explanation of a dot standing in for a type doesn't make sense in the long run.

Re: Zig's Lovely Syntax

#14

Post by zabzonk »

jeltz wrote: post #7
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.

I don't think many people would start to use a language unless the found the syntax at least a little simpatico - but I guess they could be drawn by the semantics it provides.

Re: Zig's Lovely Syntax

#15

Post by Y_Y »

> C uses a needlessly confusing spiral rule

Libellous! The "spiral rule" for C is an abomination and not part of the language. I happen to find C's type syntax a bit too clever for beginners, but it's marvellously consistent and straightforward. I can read types fine without that spiral nonsense, even if a couple of judicious typedefs are generally a good idea for any fancy function types.

Re: Zig's Lovely Syntax

#16

Post by flohofwoe »

do_not_redeem wrote: post #13
flohofwoe wrote: post #9

Earlier quoted context omitted.

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…

Zig is planning to get rid of explicit `T{}` syntax, in favor of only supporting inferred types. https://github.com/ziglang/zig/issues/5038 So the explanation of a dot standing in for a type doesn't make sense in the long run.

Ah, I wasn't aware of that proposal. But yeah in that case I would also heavily prefer to "drop the dot" :)

IMHO Odin got it exactly right. For a variable with explicit type:

   a_variable : type = val;
...or for inferred type:

   a_variable := val;
...and the same for constants:

   a_const : type : val;
   a_const :: val;
...but I think that doesn't fit into Zig's parser design philosophy (e.g. requiring some sort of keyword upfront so that the parser knows the context it's in right from the start instead of delaying that decision to a later time).

Re: Zig's Lovely Syntax

#17

Post by throwawaymaths »

Y_Y wrote: post #15

> C uses a needlessly confusing spiral rule Libellous! The "spiral rule" for C is an abomination and not part of the language. I happen to find C's type syntax a bit too clever for beginners, but it's marvellously consistent and straightforward. I can read types fine without that spiral nonsense, even if a couple of judicious typedefs are generally a good idea for any fancy function types.

It's not context free though.
Post reply on HN