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

101–110 of 246 posts

Re: Zig's Lovely Syntax

#101

Post by brabel »

nromiun wrote: post #44
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…

That saying never made any sense to me either. After all syntax is your main interface to a language. Anything you do has to go through the syntax. Some people say the syntax just kind of disappears for them after some time. That never seems to happen with me. When I am reading any code the syntax gets even more highlighted.

I always thought that languages (or at least editors) should allow the user to use whatever syntax they want! It's possible. Just look at Kotlin and Java... you can write the exact same code in both, even if you discount the actual differences in the languages. It's not hard to see how you could use Haskell, or Python syntax, to write the exact same thing. People don't like the idea too much because they think that makes it sharing code and reading code together harder, but I don't buy that because at least I myself, read code by myself 99% of the time, and the few times I read code with someone else, I can imagine we can just agree quite easily on which syntax to use - or just agree to always use the "default" syntax to avoid disagreements.

I dream to one day get the time to write an editor plugin that lets you read and write in any syntax... then commit the code in the "standard" syntax. How hard would that be?!

Re: Zig's Lovely Syntax

#102

Post by brabel »

zabzonk wrote: post #100
aeonik wrote: post #30

Earlier quoted context omitted.

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.

No, it's an s-expression... it may be a function call, but it may also be a macro, and inside a macro it may be a parameter list or a number of other things.

Re: Zig's Lovely Syntax

#103

Post by flipgimble »

veber-alex wrote: post #75
jmull wrote: post #58

Earlier quoted context omitted.

You can declare an anonymous struct that has a function and reference that function inline (if you want). There's a little more syntax than a dedicated language feature, but not a lot more. What's "missing" in zig that lambda implementations normally have is capturing. In zig that's typically accomplished with a context parameter, again typically a struct.

So basically, Zig doesn't have lambdas, but because you still need lambdas, you need to reinvent the wheel each time you need it? Why don't they just add lambdas?

Because to use lambdas you're asking the language to make implicit heap allocations for captured variables. Zig has a policy that all allocation and control flow are explicit and visible in the code, which you call re-inventing the wheel.

Lambdas are great for convenience and productivity. Eventually they can lead to memory cycles and leaks. The side-effect is that software starts to consume gigabytes of memory and many seconds for a task that should take a tiny fraction of that. Then developers either call someone who understands memory management and profiling, or their competition writes a better version of that software that is unimaginably faster. ex. https://filepilot.tech/

Re: Zig's Lovely Syntax

#104

Post by hinkley »

nromiun wrote: post #44
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…

That saying never made any sense to me either. After all syntax is your main interface to a language. Anything you do has to go through the syntax. Some people say the syntax just kind of disappears for them after some time. That never seems to happen with me. When I am reading any code the syntax gets even more highlighted.

People who do a lot of deep work on code, particularly debugging and rearchitecting, tend to have opinions about syntax and code style that are more exacting. As one of those people I’ve always felt that the people working the code the hardest deserve to have an outsized vote on how to organize the code.

Would that potentially reduce throughput a bit? Probably. But here’s the thing: most management notice how the bad situations go more than the happiest path. They will kick you when you’re down. So tuning the project a bit for the stressful days is like Safety. Sure it would be great to put a shelf here but that’s where the fire extinguishers need to go. And sure it would be great not interrupting the workday for fire safety drills, but you won’t be around to complain about it if we don’t have them. It’s one of those counterintuitive things, like mise en place is for a lot of people. Discipline is a bit more work now for less stress later.

You get more predictable throughput from a system by making the fastest things a little slower to make the slow things a lot faster. And management needs predictability.

Re: Zig's Lovely Syntax

#105

Post by [deleted] »

hinkley wrote: post #89
n42 wrote: post #79

Earlier quoted context omitted.

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

[deleted]

Re: Zig's Lovely Syntax

#106

Post by IshKebab »

z_open wrote: post #69
IshKebab wrote: post #64

Earlier quoted context omitted.

Maybe if you've never tried formatting a traditional multiline string (e.g. in Python, C++ or Rust) before. If it isn't obvious, the problem is that you can't indent them properly because the indentation becomes part of the string itself. Some languages have magical "removed the indent" modes for strings (e.g. YAML) but they generally suck and just add confusion. This syntax is quite clear (at least with respect to i…

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.

Yeah I agree \\ is not the best choice visually (and because it looks quite similar to //

I would have probably gone with ` or something.

Re: Zig's Lovely Syntax

#107

Post by flohofwoe »

andrepd wrote: post #87
flohofwoe wrote: post #29

Earlier quoted context omitted.

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.

You need to store the captured data somewhere if the lambda is called after the outer function returns. AFAIK C++ (or rather std::function) will heap-allocate if the capture size goes above some arbitrary limit (similar to small-string optimizations in std::string). Not sure how Rust handles this case, probably through some "I can't let you do that, Dave" restrictions ;)

Re: Zig's Lovely Syntax

#108

Post by brabel »

lenkite wrote: post #88
qcnguy wrote: 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…

> 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 semantic understanding of the code that an IDE has, and they should never do that again.

EDIT: IntelliJ is better than grep even at "free text" search... Much better as it will show you the results as you type, extremely fast, and lets you preview them and see their "surrounding code"... and you can then choose to navigate to a place instantly... and yes, you can scope the search to a particular directory if you want... if you can't see how this is miles superior to CLI grep, then there's no use arguing as you've made up your mind you just love being in the CLI for no actual rational reason.

Re: Zig's Lovely Syntax

#109

Post by Metasyntactic »

kcartlidge wrote: post #62

I much prefer C# 11's raw string literals. It takes the indentation of the first line and assumes the subsequent ones have the same indentation. string json = $""" {title} Welcome to {sitename}. """; And it even allows for using embedded curly braces as real characters: string json = $$""" {{title}} Welcome to {{sitename}}, which uses the {sitename} syntax. """; The $ (meaning to interpolate curly braces) appears twi…

Just a minor correction (as I'm the author of c#'s raw string literal feature).

The indentation of the final ` """` line is what is removed from all other lines. Not the indentation of the first line. This allows the first line to be indented as well.

Cheers, and I'm glad you like it. I thought we did a really good job with that feature :-)

Re: Zig's Lovely Syntax

#110

Post by Twey »

n42 wrote: post #91

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 d…

> it's not the kind of surface level "aesthetically beautiful" readability that tickles the mind of an abstract thinker

Rather, the sort of beauty it's going for here is exactly the type of beauty that requires a bit of abstraction to appreciate: it's not that the concrete syntax is visually beautiful per se so much as that it's elegantly exposing the abstract syntax, which is inherently more regular and unambiguous than the concrete syntax. It's the same reason S-exprs won over M-exprs: consistently good often wins over special-case great because the latter imposes the mental burden of trying to fit into the special case, while the former allows you to forget that the problem ever existed. To see a language do the opposite of this, look at C++: the syntax has been designed with many, many special cases that make specific constructs nicer to write, but the cost of that is that now you have to remember all of them (and account for all of them, if templating — hence the ‘new’ uniform initialization syntax[1]).

[1]: https://xkcd.com/927/

This trade-off happens all the time in language design: you're looking for language that makes all the special cases nice _as a consequence of_ the general case, because _just_ being simple and consistent leads you to the Turing tarpit: you simplify the language by pushing all the complexity onto the programmer.

Post reply on HN