181–190 of 246 posts
> 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.
[deleted]
> 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.
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…
Earlier quoted context omitted.
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
Go has a similar function declaration, and it supports anonymous functions/lambdas.
E.g. in go, an anonymous func like this could be defined as
foo := func(x int, _ int) int { … }
So I’d imagine in Zig it should be feasible to do something like
var foo = fn(x: i32, i32) i32 { … }
unless I’m missing something?
> 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.
If I understood `abort` semantics correctly, it has a type of `never` or Rust's `!`. Which has a meaning "unobtainable value because control flow went somwhere else". `void` is closer to `unit` or `()` because it's the type with no allowed values. Cool trick: some languages (e.g. TypeScript) allow `void` generics making parameters of that type optional.
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…
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…
> 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.
const still_raw =
"const raw =
" "Roses are red
" " Violets are blue,
" "Sugar is sweet
" " And so are you.
" "
";
"
;
Earlier quoted context omitted.
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
Why “perma goodbye”? Go has a similar function declaration, and it supports anonymous functions/lambdas. E.g. in go, an anonymous func like this could be defined as foo := func(x int, _ int) int { … } So I’d imagine in Zig it should be feasible to do something like var foo = fn(x: i32, i32) i32 { … } unless I’m missing something?
See
https://github.com/golang/go/issues/59122
https://github.com/golang/go/issues/21498
res := is.Map(func(i int)int{return i+1}).Filter(func(i int) bool { return i % 2 == 0 }).
Reduce(func(a, b int) int { return a + b })
res := is.Map((i) => i+1).Filter((i)=>i % 2 == 0).Reduce((a,b)=>a+b)Earlier quoted context omitted.
> 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.
Zig comptime operates a lot like very old school Lisp FEXPRS before the Lisp intelligentsia booted them out because FEXPRS were theoretically messy and hard to compile.