Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Failing to Learn Zig via Advent of Code

forrestthewoods.com

Post reply on HN
Print view View original

41–50 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#41

Post by benttoothpaste »

ReleaseCandidat wrote: post #25

> No one in the history of the world has ever been confused or upset by a + b calling a function. That depends on `a`, `b` and the function - I have seen way too many `+` that weren't commutative and/or associative. Languages which do not allow to use _other_ symbols like `⊕` too almost always lead to confusing behavior of 'usual' operators. And what does `a * b` do for vectors `a` and `b`? Is it the 'usual' 'dot pro…

If zig supports + for floating point addition, then it is already fine with ‘+’ being non commutative. The rest of the argument can also be applied to functions. What does product(a, b) do?

Re: Failing to Learn Zig via Advent of Code

#42

Post by delphLonepaw »

andi999 wrote: post #17
Comevius wrote: post #2

I see what went wrong here. You tried to lean on documentation and Google, you should have just go for the source code. It's quite readable, and it's the recommended way to learn for now. Zig has a few peculiarities, it's not stable yet, you kind of have to follow it's development. https://github.com/ziglang/zig/tree/master/lib/std

Recommended way to learn for now? Any sources for that?

Read the language reference, use ziglings, use ziglearn.org, use zls (don't trust it too much tho, but it will help a bit) and vscode or any text editor that supports jumping to the source, and of course, RTFS

Re: Failing to Learn Zig via Advent of Code

#43

Post by user-the-name »

thom wrote: post #23
brabel wrote: post #14

Nice to see a "brain dump" as someone who learned many languages and can easily relate with most of the issues the author faced. But I take issue with this: // Obviously good and easy to read return a*(1.0-t) + b*t; // Obviously bad and hard to read return add(mul(a, 1.0 - t), mul(b, t)); Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad). Here's what I would…

The LISP version can be more readable with (e.g. Clojure’s) threading macros: (-> 1 (- t) (* a) (+ (* t b))) Obviously use more or less whitespace to taste.

I can not read that at all.

Re: Failing to Learn Zig via Advent of Code

#44

Post by user-the-name »

rak1507 wrote: post #16
brabel wrote: post #14

Nice to see a "brain dump" as someone who learned many languages and can easily relate with most of the issues the author faced. But I take issue with this: // Obviously good and easy to read return a*(1.0-t) + b*t; // Obviously bad and hard to read return add(mul(a, 1.0 - t), mul(b, t)); Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad). Here's what I would…

I think there's a compromise between being recognisable as a mathematical formula and removing operator precedence which is what APL and other array languages do. (a×1-t)+b×t is how you'd write it in APL, no operator precedence but still more familiar.

That absolutely breaks the law of least astonishment. It's worse to look familiar but have hidden differences than to just look completely different.

Re: Failing to Learn Zig via Advent of Code

#45

Post by delphLonepaw »

eterm wrote: post #38

> [Compiling] takes about ~3 seconds minimum which is frustratingly slow I feel old, I know that any time is an opportunity to get distracted but 3 seconds doesn't strike me as a long compile time. Or is that a typo for 30, which would make more sense, which is definitely long enough to be a frustration?

Depends on the machine, on large projects, zig can take up to 10-15 seconds in my i5 12gb, ofc, after the first hit it becomes 0.01 recompiling without change (in case you removed the out and not the cache) and the first time you compile it takes a bit (not counted) since it will precompile std (or that is what I've seen) in a global cache (just so std does not make your code take longer to compile), small things takes 1-3 seconds depending on how comptime heavy I make my code do.

Zig comptime is the part that takes a bit more time compiling for being an interpreted version of the language, and the more comptime you use, the more time it takes (for a bit, even comptime heavy code can gain just a few seconds out of it, of course can gain 30 minutes, but you would be making like, weird jumps and generating strings on comptime that gets used on runtime, or an expensive algorithm that will take a long time to execute)

Re: Failing to Learn Zig via Advent of Code

#46

Post by ayende »

flohofwoe wrote: post #36
messe wrote: post #24

I like zig, but agree with many of the points here. A couple of thoughts below, > Zig reference documentation badly needs examples. Can't figure out how to use std.fmt.parseInt. While yes, Zig documentation badly needs examples, I'm not sure this particular criticism is justified. I would have thought that the usage of parseInt, was fairly obvious from the type-signature: parseInt(comptime T: type, buf: []const u8, r…

> It's not. It could be any unsigned type of smaller size than usize. I think it refers to Rust's ability to "indirectly" infer a type by it's later usage which can be somewhere entirely else in the function (for instance when it's used as return value), while Zig has a more direct type inference (but IMHO Rust's approach definitely isn't "obviously better", because sometimes one needs to read and understand the enti…

For the record, I find Rust's ability to change the type of the variable _after_ it was declared to be absolutely bonkers for my ability to understand what is going on in the code.

I understand what it is doing, but the fact that changing the return type of a method will change what previous code will compile to is something that I find extremely non obvious and surprising.

Inferring what the type is from the current code, sure. That saves me typing, but from what happens elsewhere looks like time travel.

Re: Failing to Learn Zig via Advent of Code

#47

Post by dnautics »

NeutralForest wrote: post #22

I don't understand people recommending reading the source code to learn. Source codes can be really daunting because there are so many things going on. There can also be "tricks" using advanced language features, which defeats the purpose if you're trying to learn as a first timer. Also, "read the source" is, at least to me, an admission that there is no valid documentation 90% of the time. Reading the source of a to…

It's important to consider that for zig at this stage, "not having valid documentation" is expected. At some point not having valid docs will become considered to be unacceptable.

Forcing people to read the code puts pressure on the code to be clean.

Not writing docs against an unstable API is a strategy to make it freer for the authors to change the API, possibly in sweeping breaking ways (for example allocgate).

Re: Failing to Learn Zig via Advent of Code

#48

Post by ReleaseCandidat »

benttoothpaste wrote: post #41
ReleaseCandidat wrote: post #25

> No one in the history of the world has ever been confused or upset by a + b calling a function. That depends on `a`, `b` and the function - I have seen way too many `+` that weren't commutative and/or associative. Languages which do not allow to use _other_ symbols like `⊕` too almost always lead to confusing behavior of 'usual' operators. And what does `a * b` do for vectors `a` and `b`? Is it the 'usual' 'dot pro…

If zig supports + for floating point addition, then it is already fine with ‘+’ being non commutative. The rest of the argument can also be applied to functions. What does product(a, b) do?

> The rest of the argument can also be apply to functions.

Of course it is, but you can use other functions names than `product`. If the language doesn't let you use any other symbol for the operator but `*`, you're out of luck.

Re: Failing to Learn Zig via Advent of Code

#49

Post by webstrand »

benttoothpaste wrote: post #41
ReleaseCandidat wrote: post #25

> No one in the history of the world has ever been confused or upset by a + b calling a function. That depends on `a`, `b` and the function - I have seen way too many `+` that weren't commutative and/or associative. Languages which do not allow to use _other_ symbols like `⊕` too almost always lead to confusing behavior of 'usual' operators. And what does `a * b` do for vectors `a` and `b`? Is it the 'usual' 'dot pro…

If zig supports + for floating point addition, then it is already fine with ‘+’ being non commutative. The rest of the argument can also be applied to functions. What does product(a, b) do?

Aside from `NaN`, how is floating point addition non-commutative? It's not associative, but `a+b` will have the same value as `b+a`.

Re: Failing to Learn Zig via Advent of Code

#50

Post by adito »

ralphb wrote: post #27
NeutralForest wrote: post #22

I don't understand people recommending reading the source code to learn. Source codes can be really daunting because there are so many things going on. There can also be "tricks" using advanced language features, which defeats the purpose if you're trying to learn as a first timer. Also, "read the source" is, at least to me, an admission that there is no valid documentation 90% of the time. Reading the source of a to…

In general I would agree, but (as multiple people pointed out) the zig standard library source code is very accessible.

I beg to disagree with you. I'm newbie and I still found that zig standard library still daunting to read. When people said it's very accessible, I'm curious what people mean by that? What makes it very accessible?
Post reply on HN