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

161–170 of 246 posts

Re: Zig's Lovely Syntax

#161

Post by dpassens »

brabel wrote: post #123
dpassens wrote: post #111

Earlier quoted context omitted.

If my understanding of D's template syntax is correct, then Walter is showing a the declaration of a function called ArrayListType which is generic over T and returns a T. The original Zig code returns the struct type itself, so it is functionally equivalent to my example, provided I understood how D templates work.

The Zig code returns any `type`, it's impossible to say what that is without looking at the implementation. It can be different types completely depending on the comptime arguments. But I agree it probably returns a struct type. Assuming that's the case, you're right and the equivalent would be: Zig: fn ArrayListType(comptime T: type) type { D: ArrayList!T ArrayListType(T)() { But now the D version is more specific a…

No, you misunderstand. The function doesn't return any type, it returns _a_ type. Types are values in Zig and returning them from function is how generics are implemented.

Re: Zig's Lovely Syntax

#162

Post by dminik »

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.

Ahh, a perfect example of why Zig is uninteresting to me:

https://github.com/ziglang/zig/issues/5038#issuecomment-2441...

A language hostile to LSP/intellisense.

Re: Zig's Lovely Syntax

#163

Post by ruuda »

> as name of the type, I think I like void more than ()

It's the wrong name though. In type theory, (), the type with one member, is traditionally called "Unit", while "Void" is the uninhabited type. Void is the return type of e.g. abort.

Re: Zig's Lovely Syntax

#164

Post by johnisgood »

brabel wrote: post #108
lenkite wrote: post #88

Earlier quoted context omitted.

> There's no need to design the syntax for grep because Kotlin is intended to be used with a good IDE that can answer this query instantly and precisely. On large projects its still cheaper and faster to grep from the CLI than to use Intellij IDE search. Esp if you wish to restrict search to subsets of dirs. Command-line greppability is a serious use case. Zig is also 5-10x faster to compile than Kotlin. On function…

> On large projects its still cheaper and faster to grep from the CLI than to use Intellij IDE search. Esp if you wish to restrict search to subsets of dirs. You must never have used Intellij to say that... it hurts me to hear this. If I catch a developer "grepping" for some type in the CLI, I will sit down with them for a few hours explaining how to use an IDE and how grep is just dumb text search without any of the…

He said cheaper and faster. It takes 5-10 minutes for IntelliJ to start up properly for me, and doing anything in it is just too slow. (rip)grep is way faster.

Yes yes, I need a better PC. (rip)grep would still be faster, however, but I would use the IDE.

Re: Zig's Lovely Syntax

#165

Post by tialaramex »

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…

Because we've said x is a constant we're obliged to specify its type. For variables we're allowed to use inference and in most cases the type can be correctly inferred, but for constants or function signatures inference is deliberately prohibited.

    const x: Rect = ....
[Note that in Zig what you've written isn't a constant, Zig takes the same attitude as C and C++ of using const to indicate an immutable rather than a constant]

Re: Zig's Lovely Syntax

#166

Post by dsego »

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.

Zig is noisy and and the syntax is really not elegant. One reason I like odin's syntax, it's minimal and so well thought out.

Re: Zig's Lovely Syntax

#167

Post by gf000 »

throwawaymaths wrote: post #73
lvl155 wrote: post #46

Zig is just fun to write. And to me, it’s actually what I wish Rust was like. Rust is a great language, and no one’s going to argue that point but writing Zig for the first time was so refreshing. That said, Rust is now basically default for systems and Zig came too late.

never underestimate second mover advantage. if zig gets static borrow checking, it would be amazing

I really doubt a borrow checker could fit with zig's design goals, and you can't just add it after the fact.

Re: Zig's Lovely Syntax

#168

Post by IshKebab »

gf000 wrote: post #152
Twey wrote: post #131

Earlier quoted context omitted.

And what if you do want to include two spaces at the beginning of the block (but not any of the rest of the indentation)? Choice of specific line-start marker aside, I think this is the best solution to the indented-string problem I've seen so far.

I think Java's solution is much cleaner.

For those of us that haven't used Java for a decade...

> In text blocks, the leftmost non-whitespace character on any of the lines or the leftmost closing delimiter defines where meaningful white space begins.

From https://blogs.oracle.com/javamagazine/post/text-blocks-come-...

It's not a bad option but it does mean you can't have text where every line is indented. This isn't uncommon - e.g. think about code generation of a function body.

Re: Zig's Lovely Syntax

#169

Post by quesera »

hinkley wrote: post #157
Twey wrote: post #128

Earlier quoted context omitted.

I wonder if it's dyslexia-adjacent. Dyslexic people famously have particular difficulty distinguishing rotated and reflected letterforms.

Could be. The frequency is such that it could be dyslexics. It's not all the time, but it's a steady rate of incidence.

I think in the 90's it was just people repeating a pattern they learned from Windows/DOS.

It used to grate on my nerves to hear people say, e.g. "H T T P colon backslash backslash yahoo dot com".

But I think they always typed forward slash, like they knew the correct slash to use based on the context, but somehow always spoke it in DOSish.

Re: Zig's Lovely Syntax

#170

Post by ivanjermakov »

> Almost always there is an up-front bound for the number of iterations until the break, and its worth asserting this bound, because debugging crashes is easier than debugging hangs.

Perhaps in database systems domain yes, but in everything else unconditional loop is meant to loop indefinitely. Think event loops, web servers, dynamic length iterations. And in many cases `while` loop reads nicer when it has a break condition instead of a condition variable defined outside of the loop.

Post reply on HN