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

31–40 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#31

Post by edflsafoiewq »

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…

A notation which everyone is already used to is obviously good. A very compelling benefit is needed to outweigh "you already understand this".

Re: Failing to Learn Zig via Advent of Code

#32

Post by ReleaseCandidat »

alexvoda wrote: post #21
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 notation the author complains about looks like a broken polish (prefix) notation with added parens. Your notation looks like a very bizare mix of infix arrangement postfix (RPN) behaviour plus added parens for good measure. RPN has plenty of benefits, once you get used to its initial awkwardness, that I feel your notation fails to capitalise on.

> The notation the author complains about looks like a broken polish (prefix) notation with added parens.

The notation the author complains about is the first version using 'normal' (prefix) functions.

    a + b = (+)(a, b) = add(a, b) = a `add` b (Haskell infix) = a .add. b (Fortran infix)
    a * b = (*)(a, b) = mul(a, b) = a `mul` b = a .mul. b
so

  a*(1.0-t) + b*t
is

  (+)(a*(1.0-t), b*t) = (+)((*)(a, 1.0-t), (*)(b, t)) = add(mul(a, 1.0-t), mul(b, t))

Re: Failing to Learn Zig via Advent of Code

#33

Post by dnautics »

AnIdiotOnTheNet wrote: post #19

As a seasoned Zig programmer, this is good information, though painful to read. A lot of the problems seem to be from a fundamental misunderstanding of Zig's philosophy and very basic things about how the language works. Possibly Zig needs more emphasis on those things in its documentation. I also have to wonder about a fundamental misalignment of thinking when someone says downloading and replacing a single .exe is…

Nah, I think it is fine. The problems are almost all (the author's) problems with zig's philosophy of "when to do things you need for a 1.0". Author mostly wants docs, guides, error messages, and package manager, which are supposed to be "late in the development process" according to my understanding of the unofficial zig roadmap.

Re: Failing to Learn Zig via Advent of Code

#34

Post by styluss »

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 makes less sense when the source code uses idioms that aren't recommended for other code

Re: Failing to Learn Zig via Advent of Code

#36

Post by flohofwoe »

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 entire code of a function to get an idea what type a variable might be).

Re: Failing to Learn Zig via Advent of Code

#37

Post by smoyer »

It's interesting that the author goes through AdventOfCode hell (the code challenges are supposed to be hard, not fighting with your language), critiques Zig's raison d'etre and then predicts a bright future.

To me, this seems like one of those projects that starts its marketing hype too early, gets a negative reputation and then never recovers even if the original promises have been fulfilled.

Re: Failing to Learn Zig via Advent of Code

#38

Post by eterm »

> [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?

Re: Failing to Learn Zig via Advent of Code

#39

Post by messe »

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…

I understood that, but my comment could have been more clear. I more meant that it's not necessarily obvious that the type check should infer that it's a `usize` just because the function returns a `usize`. It could be any type that can be implicitly cast to a `usize` which in a 64-bit Zig system is any of `u[1-64]`.

Re: Failing to Learn Zig via Advent of Code

#40

Post by delphLonepaw »

rootlocus wrote: post #8
bollu wrote: post #5

Earlier quoted context omitted.

Zig documentation isn't crap; the documentation *does not exist* yet. There's an important difference between the two which seems to be ignored. Zig is young. They're spending their time maturing the core ecosystem --- the compiler, the standard library, and so forth. It's perfectly reasonable to expect early adopters to "RTFS/read the fucking source". *When* they start writing documentation, I'd be perfectly happy t…

Zig absolutely has documentation: https://ziglang.org/documentation/master/

That's the language reference, that also links the experimental autogenerated std documentation

Right now, Zig is young and the documentation is kinda ok (Language reference is clear enough, outside a few things that need better visibility, for example, explaining concepts that are only on the examples can be lost easy), the autogenerated std on the other hand used to work meh, until a commit broke it afaik, so rn is in a pityfull state, but there is no use in reworking it until stage 2, so that's that

Post reply on HN