Live data from Hacker News

Zig's Lovely Syntax

matklad.github.io

81–90 of 246 posts

Re: Zig's Lovely Syntax

#81
post #34
post #8

"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?

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

Re: Zig's Lovely Syntax

#82

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.

There was a recent Zig podcast where Andrew Kelley explicitly states that manually defining a VTable is their solution to runtime polymorphism [1]. In general this means wrapping your data in a struct, which is reasonable for almost anything other than base value types.

1. https://youtu.be/x3hOiOcbgeA?si=Kb7SrhdammEiVvDN&t=7620

Re: Zig's Lovely Syntax

#84
Zig is great. I have fun writing in it. But there’re a few things bug me.

- Difficult to return a value from a block. Rust treats the value of the last expression of a block as the return value of the block. Have to jump through hoops in Zig to do it with label.

- Unable to chain optional checks, e.g. a?.b?.c. Support for monadic types would be great so general chaining operations are supported.

- Lack of lambda support. Function blocks are already supported in a number of places, i.e. the for-loop block and the catch block.

Re: Zig's Lovely Syntax

#85
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.

It seems very reasonable and comes with several technical and cognitive advantages. I think you're just having a knee-jerk emotional reaction because it's different than what you're used to, not because it's actually bad.

Re: Zig's Lovely Syntax

#86
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 had the exact opposite reaction.

Re: Zig's Lovely Syntax

#87

Earlier quoted context omitted.

And what if you need to close over some local variable?

Not possible, you'll need to pass the captured variables explicitly into the 'lambda' via some sort of context parameter. And considering the memory management magic that would need to be implemented by the compiler for 'painless capture' that's probably a good thing (e.g. there would almost certainly be a hidden heap allocation required which is a big no-no in Zig).

Why would capturing require a heap allocation? Neither Rust nor C++ do this.

Re: Zig's Lovely Syntax

#88
post #56

Weird the author finds it lovely and compares to Kotlin, but doesn't find Kotlin superior. Kotlin invested heavily in a really nice curly brace syntax. It is actually the nicest out there. In every point the author makes, it feels like Kotlin did it the same or better. For example: 1. Integer literals. "var a = 1" doesn't work, seems absurd. In Kotlin literals do have strong types, but coercion is allowed when defini…

> 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 syntax, I agree with you. It was a mistake not to use fn:ReturnType. It has destroyed future lambdas.

Re: Zig's Lovely Syntax

#89
post #79
post #69

Earlier quoted context omitted.

Even if we ignore solutions other languages have come up with, it's even worse that they landed on // for the syntax given that it's apparently used the same way for real comments.

> it's even worse that they landed on // for the syntax .. it is using \\

I worked with browsers since before most people knew what a browser was and it will never cease to amaze me how often people confuse slash and backslash, / and \

It’s some sort of mental glitch that a number of people fall into and I have absolutely no idea why.

Re: Zig's Lovely Syntax

#90

Earlier quoted context omitted.

Zig: fn ArrayListType(comptime T: type) type { D: T ArrayListType(T)() {

I don't know D but shouldn't that be struct ArrayListType(T) { ?

Walter is showing the equivalent function declaration... you will eventually create a generic type as you say, but in the Zig example, that was a function, not a struct.
Post reply on HN