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

31–40 of 246 posts

Re: Zig's Lovely Syntax

#31

Post by flohofwoe »

the__alchemist wrote: post #19

I wish Zig had lovely vector, quaternion, matrix etx syntax. The team's refusal to add operator overloading will prevent this.

You don't need operator overloading for vector and matrix math, see pretty much all GPU languages. What Zig is missing is a complete mapping of the Clang Extended Vector and Matrix extensions (instead of the quite limited `@Vector` type):

https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...

https://clang.llvm.org/docs/LanguageExtensions.html#matrix-t...

Re: Zig's Lovely Syntax

#33

Post by reactordev »

bscphil wrote: post #12

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

I’m in the same boat. It’s faster mentally to grok the type of something when it comes first. The name of the thing is less important (but still important!) than the type of the thing and so I prefer types to come before names.

From a parser perspective, it’s easier to go name first so you can add it to the AST and pass it off to the type determiner to finish the declaration. So I get it. In typescript I believe it’s this way so parsers can just drop types all together to make it compatible with JavaScript (it’s still trivial to strip typing, though why would you?) without transpiling.

In go, well, you have even more crazier conventions. Uppercase vs lowercase public vs private, no inheritance, a gc that shuns away performance minded devs.

In the end, I just want a working std library that’s easy to use so I can build applications. I don’t care for:

    type Add = [
      …Array,
      …Array,
    ][“length”]
This is the kind of abuse of the type system that drives me bonkers. You don’t have to be clever, just export a function. I don’t need a type to represent every state, I need intent.

Re: Zig's Lovely Syntax

#34

Post by tapirl »

pton_xd wrote: 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.

Re: Zig's Lovely Syntax

#35

Post by nine_k »

nromiun wrote: post #28

I like Zig as well, but I won't call its syntax lovely. Go shows you can do pretty well without ; for line breaks, without : for variable types etc. But sure, if you only compare it with Rust, it is a big improvement.

I personally find Go's bare syntax harder to parse when reading, and I spend more time reading code than typing it (even while writing).

An excessively terse syntax becomes very unforgiving, when a typo is not noticed by the compiler / language server, but results in another syntactically correct but unexpected program, or registers as a cryptic error much farther downstream. Cases in point: CoffeeScript, J.

Re: Zig's Lovely Syntax

#36

Post by darthrupert »

Western0 wrote: post #32

Love Ruby and Cristal syntax ;-)

Absolutely. Kinda of the best of many worlds, because it has what looks like an indentation-based syntax but actually blocks are delimited by start and end keywords. This makes it possible (unlike, say, python) to programmatically derive correct code formatting more reliably.

And no pointless semicolons.

Re: Zig's Lovely Syntax

#37

Post by nine_k »

flohofwoe wrote: post #29
tsimionescu wrote: post #24

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

...or escape analysis and lifetimes, but we already have Rust %)

Re: Zig's Lovely Syntax

#39

Post by pton_xd »

flohofwoe wrote: post #29
tsimionescu wrote: post #24

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

As far as I know lambdas in C++ will not heap allocate. Basically equivalent to manually defining a struct, with all your captures, and then stack allocating it. However if you assign a lambda to a std::function, and it's large enough, then you may get a heap allocation.

Making all allocations explicit is one thing I do really like about Zig.

Re: Zig's Lovely Syntax

#40

Post by pjmlp »

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

Real programmers deliver business value, regardless of what keyboard they have at their disposal.

Just like great musicians make the difference in the band, regardless of the instruments scattered around the studio.

Post reply on HN