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

Re: Failing to Learn Zig via Advent of Code

#121

Post by shwestrick » Mon, Jan 17, 2022, 4:19 PM UTC

ogogmad wrote: post #103

Would there by any interest in an imperative language with a basic Standard ML type system? Personally, while I find the imperative paradigm more intuitive than the functional paradigm, I believe functional type systems are simpler and more "right" than imperative ones are (which have been taken over by OOP). There are multi-paradigm languages, but these have large numbers of features, and complicated type systems, a…

OCaml is pretty close already to what you're describing. The OCaml ecosystem fully embraces imperative programming. And if the syntax of OCaml is problematic, then perhaps ReasonML (https://reasonml.github.io/) is what you're looking for: a curly-braces syntax for OCaml.

Re: Failing to Learn Zig via Advent of Code

#122

Post by ode » Mon, Jan 17, 2022, 4:21 PM UTC

delphLonepaw wrote: post #42

andi999 wrote: post #17

Earlier quoted context omitted.

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

Ziglings are indeed excellent. Try them if you haven't.

Re: Failing to Learn Zig via Advent of Code

#123

Post by pyrale » Mon, Jan 17, 2022, 4:23 PM UTC

The opinion that reimplementing AoC in two languages was not a good idea resonates a lot with my experience.

Every year, I see people quitting their AoC run with frustration, because they don't measure their effort and try to complete each puzzle daily. The usual scenario is that, at some point, they block on a problem and spend longer than they should, or they can't solve the problem because they have some other thing to do. The next day, they try to solve that puzzle and another one, and as work piles up, they start doing it joylessly to catch up. After a while, it doesn't work anymore, because people are stressed, because they code poorly just to finish rather than taking pleasure in their craft. The strict calendar can become deadlines that remind of work woes.

For a person not used to sport code, AoC can take an hour to solve, sometimes more. Over the whole advent, people can easily work for 30 to 40 hours more than they are used to. In terms of work hygiene, this is not good. Not everyone has a week's worth of work to use just before the end of year.

I would advise people doing AoC to time their effort, and not hesitate to stop a puzzle and write it down for later in the year.

Re: Failing to Learn Zig via Advent of Code

#124

Post by juped » Mon, Jan 17, 2022, 4:25 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…

At the very least, it's wrong that no one has ever been upset by this; many people have been very vocally upset by this.

Re: Failing to Learn Zig via Advent of Code

#125

Post by Kwpolska » Mon, Jan 17, 2022, 4:25 PM UTC

kristoff_it wrote: post #80

megumax wrote: post #70

My big problem with Zig is that Andrew Kelley is promising a lot of features, but doesn't really deliver much. Zig still can't proper handle UTF-8 strings [1] in 2022, which is kind of unfortunate, because it's a `requirement`. In a `recent` interview[2], he claims that Zig is faster than C and Rust, but he refers to extremely short benchmarking that has almost no value in the real world. At least Rust, as blamed and…

> My big problem with Zig is that Andrew Kelley is promising a lot of features, but doesn't really deliver much. Have you, like, seen the release notes for 0.9.0? https://ziglang.org/download/0.9.0/release-notes.html > Zig still can't proper handle UTF-8 strings [1] in 2022 There's plenty of discussion on the subject in basically every HN thread about Zig: the stdlib has some utf8 and wtf validation code, ziglyph imp…

Why does something as basic as uppercasing a string or decoding latin1 require a third-party library? I would expect that to be part of stdlib in any language. Also, why does that third-party library come with its own string implementation? What if my dependency X uses zigstr but dependency Y prefers zig-string https://github.com/JakubSzark/zig-string>? Basically all languages designed in the past 30 years have at least basic and correct-for-BMP Unicode support built-in/as part of stdlib. Why doesn’t Zig?

Re: Failing to Learn Zig via Advent of Code

#126

Post by otabdeveloper4 » Mon, Jan 17, 2022, 4:26 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, all of that hidden from the eyes...

It's not a given that floating-point addition is a simpler operation than string concatenation.

If you're serious about what you write, then all operators should be banned.

Re: Failing to Learn Zig via Advent of Code

#127

Post by klyrs » Mon, Jan 17, 2022, 4:27 PM UTC

k__ wrote: post #114

socialdemocrat wrote: post #109

Zig is a very low level language. I think the fancy type system can trip up people into thinking they are working with a high-level language. Zig is basically C with a fancy type system, so you should not expect things like special String types, overloading of index based access etc. I think the author was thinking that Zig was very close to Rust or C++, when in reality it is much closer to C. I had to keep reminding…

Interesting. I had the impression Zig proponents were praising it because it wasn't as low-level as Rust.

Quite the opposite. The very broad-brush overview is that zig aims to replace C and rust aims to replace C++... but among other issues with that analogy, that can't happen unless zig and rust have a dead-simple integration story.

Re: Failing to Learn Zig via Advent of Code

#128

Post by kello » Mon, Jan 17, 2022, 4:33 PM UTC

pyrale wrote: post #123

The opinion that reimplementing AoC in two languages was not a good idea resonates a lot with my experience. Every year, I see people quitting their AoC run with frustration, because they don't measure their effort and try to complete each puzzle daily. The usual scenario is that, at some point, they block on a problem and spend longer than they should, or they can't solve the problem because they have some other thi…

I definitely fall into this category. I stopped on Day 8 Part 2 this year getting frustrated and falling behind. Good practice for sure and I feel more prepared for next year, still, just wanted to post that I identify myself in what you mention here!

Re: Failing to Learn Zig via Advent of Code

#129

Post by [deleted] » Mon, Jan 17, 2022, 4:39 PM UTC

socialdemocrat wrote: post #109

Zig is a very low level language. I think the fancy type system can trip up people into thinking they are working with a high-level language. Zig is basically C with a fancy type system, so you should not expect things like special String types, overloading of index based access etc. I think the author was thinking that Zig was very close to Rust or C++, when in reality it is much closer to C. I had to keep reminding…

[deleted]

Re: Failing to Learn Zig via Advent of Code

#130

Post by pjmlp » Mon, Jan 17, 2022, 4:45 PM UTC

tialaramex wrote: post #86

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…

I also would prefer not to have + as concatenate, and Linus feels strongly enough about it (and has enough influence) that Rust for the Linux kernel does not have Add and AddAssign overloaded on string types, among many concessions. However I think in general purpose programming we lost that battle when Java special-cased the operator. There's no overloading in Java, you can't have + do the Right Thing™ in Java for y…

Why Java given the history of programming languages between 1950 and 1996?