Failing to Learn Zig via Advent of Code • Hacker News Board

Re: Failing to Learn Zig via Advent of Code

#91

Post by naasking » Mon, Jan 17, 2022, 2:52 PM UTC

the_duke wrote: post #85

skywal_l wrote: post #6

Yes, error messages in zig needs improving but that's not surprising. Rust error messages where pretty terrible back in the day. I found zig language reference pretty good[0]. It is simple, lot of example. I would find 80% on there and had to google the rest. And as another commenter said, looking at zig source code is actually not a bad idea. The std lib is pretty clear and with comments. My biggest beef with zig is…

A potentially huge roadblock to better error messages is lack of generics and interfaces/traits/classes. The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors. It'll be interesting to see how this plays out as the ecosystem grows.

> The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors.

Why do you think that's the case?

Re: Failing to Learn Zig via Advent of Code

#92

Post by jmull » Mon, Jan 17, 2022, 2:54 PM UTC

I also did AOC 2021 to learn zig. But I found zig interesting and useful.

As someone with only 18 days more experience than OP it’s a little silly for me to say, but I think OP is getting put off the the normal learning curve of a new language and standard library. The struggle to learn different patterns faded away after not too many more days. Zig is pretty simple, and while the standard library is barely documented, it is pretty well organized and straightforward to understand.

I’m pretty interested to see where zig goes, and I’m hopeful about it.

(As mentioned, zig is a work-in-progress. The final form might be significantly different that what is there now,)

Re: Failing to Learn Zig via Advent of Code

#93

Post by edflsafoiewq » Mon, Jan 17, 2022, 2:55 PM UTC

thom wrote: post #83

edflsafoiewq wrote: post #72

Earlier quoted context omitted.

I think it actually obscures the important facts about the expression by breaking up the structure which is displayed by the usual infix notation 1. It is a linear combination of a and b: there are two symmetric terms, a scaled copy of a and a scaled copy of b 2. The factors are functions of t alone which goes between 0 and 1 as t does This isn't litigating about brackets, the traditional prefix notation also display…

I was really only interested in the similarity between the threaded form and the proposal with all the commas (since they mentioned LISP) but I wish I'd had an aneurysm and died before sending the comment tbh.

Yeah, sorry, didn't mean to pile on. I guess my thoughts re the OP are that the common notation for addition and multiplication is not just "what you're used to", but is connected to objective mathematical properties (associativity, commutativity, distributivity).

Re: Failing to Learn Zig via Advent of Code

#94

Post by oconnor663 » Mon, Jan 17, 2022, 3:02 PM UTC

stephc_int13 wrote: post #60

I disagree from this part: "I also think it's partially wrong. No one in the history of the world has ever been confused or upset by a + b calling a function." It depends. If this is simple math on vectors I think it can be OK but it should probably be a built-in feature of the language as this is common, solved and we all implement it the same way (for short vectors at least) But the + operator has been abused in th…

> Such an innocent looking operator, the simplest of all operations, leading to a function call, a memory allocation and thus a very real potential memory leak

I hadn't considered the memory leak angle of this, and now that you mention it it's clearly a driving concern here. When freeing is explicit, it's a problem to heap-allocate temporaries. (And I guess the addition operator would also require a third operand to supply the allocator?)

I'm still a big fan of destructors, and how they make this problem mostly vanish. But I understand that it's hard to make them efficient without move semantics, and maybe also a global allocator so every object doesn't need to store an allocator pointer? What other interactions am I missing?

Re: Failing to Learn Zig via Advent of Code

#95

Post by dnautics » Mon, Jan 17, 2022, 3:02 PM UTC

webstrand wrote: post #49

benttoothpaste wrote: post #41

Earlier quoted context omitted.

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

i believe there are strange corner cases around x87, but that may have changed since IEE754 got revised last year

Re: Failing to Learn Zig via Advent of Code

#96

Post by ayende » Mon, Jan 17, 2022, 3:03 PM UTC

tialaramex wrote: post #75

ayende wrote: post #46

Earlier quoted context omitted.

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…

The trouble is, when you say it's OK to infer "from the current code" that includes your function call, which is the thing where you're surprised it happens. There's no coherent reason why it'd be OK for Rust to conclude that x is a u64 from let x = some_u64.add(6); // the u64 type implement Add returning a u64 and yet not OK for Rust to conclude that x is a u64 from let x = someFunction(); // someFunction was define…

That isn't the problem. This is the issue:

   let x = str.parse()?;

   someFunc(x);

The function called here is dependent on what `someFunc` will accept. That means that I can change what values will be accepted here by changing a completely different piece of code.

Re: Failing to Learn Zig via Advent of Code

#97

Post by thom » Mon, Jan 17, 2022, 3:07 PM UTC

edflsafoiewq wrote: post #93

thom wrote: post #83

Earlier quoted context omitted.

I was really only interested in the similarity between the threaded form and the proposal with all the commas (since they mentioned LISP) but I wish I'd had an aneurysm and died before sending the comment tbh.

Yeah, sorry, didn't mean to pile on. I guess my thoughts re the OP are that the common notation for addition and multiplication is not just "what you're used to", but is connected to objective mathematical properties (associativity, commutativity, distributivity).

No need to apologise, sorry for the unwarranted grumpy replies. Clearly it's tough to design for a wide audience, some of whom want to reason about programs as a series of steps, and some of whom deal with compositions of abstractions which may have deeper meanings outside the computer.

Re: Failing to Learn Zig via Advent of Code

#98

Post by dnautics » Mon, Jan 17, 2022, 3:08 PM UTC

kristoff_it wrote: post #67

Hi, I'm Loris from the ZSF. I think this is a fair post overall given what it is: a log of what it was like for one specific person to use Zig for AoC for the first time. I'll spend some words on some of the things mentioned and then add some more useful advice for forrestthewoods at the end. From my perspective the complaints mostly were about now knowing things which had varying degrees of discoverability. The firs…

> The second point (how to print an integer) is about something way less easily discoverable than in the previous example. You need to learn about how to print, then about `fmt` and from there the only authoritative place that contains information about format specifiers is the doc comment of `std.fmt.format`.

I don't know if ZSF can guide this or if we can incept it into Andy's head, but if there were any coordinated plan to "solidify certain parts of the stdlib sooner than other parts" the std.fmt.format would be high on my list. And document it. Hell. document it, even if it changes around all the time. I'm often forgetting how that beautiful bastard works and having to jump to the comment in the stdlib is kind of annoying.

Re: Failing to Learn Zig via Advent of Code

#99

Post by jhack » Mon, Jan 17, 2022, 3:11 PM UTC

I don't know how a language that sets itself up to be a better C turns into this monster of horrible syntax and patterns that's nothing like C at all.

Re: Failing to Learn Zig via Advent of Code

#100

Post by githubholobeat » Mon, Jan 17, 2022, 3:15 PM UTC

I completed 10 days of Advent Of Code 2021 in Zig and loved the learning experience. Then I rewrote a snake game I made originally in Elm into Zig and compiled it to WASM. So now it runs in a browser. There is Zig standard library documentation on Zig website, but if you want to see the missing parts, go to GitHub and browse stdlib source files. Each source file contains test cases that are sufficient for understanding how it works.