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

111–120 of 246 posts

Re: Zig's Lovely Syntax

#111

Post by dpassens »

brabel wrote: post #90
dpassens wrote: post #74

Earlier quoted context omitted.

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.

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.

Re: Zig's Lovely Syntax

#112

Post by melodyogonna »

Very interesting, Zig seems really nice. There was a severe lack of resources when I tried to get into it few years ago, it is nice to see that situation improving in real time.

The part about integer literal is similar to Mojo, with a comp-time type that has to be materialized to another type at runtime. In Mojo though this can be done implicitly so you don't need explicit casting.

Re: Zig's Lovely Syntax

#113

Post by do_not_redeem »

flipgimble wrote: post #103
veber-alex wrote: post #75

Earlier quoted context omitted.

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

Nothing about lambdas requires heap allocation. See also: C++, Rust

Re: Zig's Lovely Syntax

#114

Post by steveklabnik »

flohofwoe wrote: post #107
andrepd wrote: post #87

Earlier quoted context omitted.

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

The trick is that “if”. Rust won’t ever automatically heap allocate, but if your closure does get returned to a place where the capture would be dangling, it will fail to compile. You can then choose to heap allocate it if you wish, or do something else instead.

Heap allocating them is fairly rare, because most usages are in things like combinators, which have no reason to enlarge their scope like that.

Re: Zig's Lovely Syntax

#115

Post by fallow64 »

pjmlp wrote: post #18

Having @ and .{ } all over the place is hardly lovely, as is having modules like JavaScript's CJS.

Every file is an implicit struct, so importing a module is just importing a struct with static members.

You can also do something like:

```Point.zig x: i32, y: i32,

const Self = @This(); fn add(self: Self, other: Self) Self { // ... } ```

Re: Zig's Lovely Syntax

#116

Post by do_not_redeem »

WalterBright wrote: post #51
WalterBright wrote: post #45

const x: i32 = 92; D has less syntax: const int x = 92; Just for fun, read each declaration out loud.

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

Why is omitting the fact that T is a type useful? T could be a normal value too.

This reminds me of C in the 1970s where the compiler assumed every typo was a new variable of type int. Explicit is good.

Re: Zig's Lovely Syntax

#117

Post by n42 »

Twey wrote: post #110
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…

I considered making the case for the parallels to Lisp, but it's not an easy case to make. Zig is profoundly not a Lisp. However, in my opinion it embodies a lot of the spirit of it. A singular syntax for programming and metaprogramming, built around an internally consistent mental model.

I don't really know how else to put it, but it's vaguely like a C derived spiritual cousin of Lisp with structs instead of lists.

Re: Zig's Lovely Syntax

#118

Post by culebron21 »

I've been seeing articles on Zig for the last 2 years, and was interested, but it seems the language community is too far from my area of interest -- data and geospatial, and the tools in my sphere in Zig aren't mature enough. E.g. to parse a CSV, you have to use very simple packages or just use a tokenizer and parse the tokens yourself.

Re: Zig's Lovely Syntax

#119

Post by pjmlp »

fallow64 wrote: post #115
pjmlp wrote: post #18

Having @ and .{ } all over the place is hardly lovely, as is having modules like JavaScript's CJS.

Every file is an implicit struct, so importing a module is just importing a struct with static members. You can also do something like: ```Point.zig x: i32, y: i32, const Self = @This(); fn add(self: Self, other: Self) Self { // ... } ```

Yeah, which is basically how requires() kind of works.

Re: Zig's Lovely Syntax

#120

Post by pjmlp »

christophilus wrote: post #52
Akronymus wrote: post #26

Earlier quoted context omitted.

Oh for sure. I am using qwerty myself. And my fav language (f#) has relatively few curly braces.

F# is wonderful. I wish someone would make an F# that compiled as fast as OCaml or Go and which had Go’s standard library and simple tooling.

.NET ecosystem is only matched by Java, and Native AOT exists, even if there are some issues with printf, due to its current implementation.
Post reply on HN