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

171–180 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#171

Post by nyberg »

jolux wrote: post #152

To me the biggest difference between Rust and Zig in practical terms is that Zig does not offer statically safe resource management like Rust does, and as far as I know they have no intentions of doing so in the future because they think it’s less important than all this stuff about control flow. There are a lot of interesting ideas in the language but my disagreement with them on this issue is so fundamental that I…

It's an open question [1] along with other safety checks both comptime and runtime [2]. The issue here is a balance of keeping language complexity low while providing safety at the same time and not depriving users of control when they know better than the type checker/lifetime analysis.

[1]: https://github.com/ziglang/zig/issues/782

[2]: https://github.com/ziglang/zig/issues/2301

Re: Failing to Learn Zig via Advent of Code

#172

Post by mst »

messe wrote: post #135
nmilo wrote: post #134

Earlier quoted context omitted.

What is a case where floating-point addition is more complicated than a string concatenation? Are you referring to some obscure architecture?

One example would be an architecture on which hardware floating point is not implemented, and has to be emulated in software. This isn't uncommon in embedded, many ARM Cortex-M cores are like this AFAIK.

When I was writing arm26 (i.e. arm2) assembly for the Archimedes everybody passed around a block of ASM that did division since the processor had a whole 16 instructions and integer division wasn't one of them.

Things are less primitive these days but the memory still brings a smile to my face.

Re: Failing to Learn Zig via Advent of Code

#173

Post by nemothekid »

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…

>Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad).

The first one is good because its what most people are used too - there's little that can be objectively said about notation once you reach a big enough audience. I could invent a word editor that produced documents from top to bottom rather then left to right and I could invent a million reasons what it's better, but that hardly matters.

Personally I don't think Polish notation is all that revolutionary for humans, it's just easier for computers; however just like anything else the human brain is quite malleable, and if you spend a year doing equations in polish notation you will come to prefer it.

Re: Failing to Learn Zig via Advent of Code

#174

Post by mst »

forrestthewoods wrote: post #157
llimllib wrote: post #54

Earlier quoted context omitted.

That complaint was weird, here's my day 7 solution in zig built in release mode: $ time zig build-exe ./a.zig -O ReleaseSmall real 0m1.728s user 0m1.544s sys 0m0.292s Which is actually slower than running the entire solution in debug mode: $ time zig run a.zig -- input.txt min 337 342641 min 470 93006301 real 0m1.138s user 0m0.789s sys 0m0.270s Totally possible that it's much slower on the dev's machine, but if he's…

Blog author here. I'm an Intel i7-8700k desktop. A few years old at this point, but quite beefy. Maybe this is a Windows issue? If I run "zig build" and then immediately run "zig build" again it still takes 3 seconds.

A relatively quick way to test that theory might be to pull down a WSL2 image of some sort and run the same thing in there.

Speaking as somebody who mostly codes for *n?x but has some windows users of their libraries, I've run face first into "everything I know about build optimisation is inapplicable on windows" more than once.

('everything' is admittedly slightly hyperbolic but I'm sufficiently bad at windows tooling that it always feels that way)

Re: Failing to Learn Zig via Advent of Code

#176

Post by futharkshill »

cturtle wrote: post #132
Kwpolska wrote: post #125

Earlier quoted context omitted.

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 l…

Those are all valid points. At the moment I believe Zig has decided to leave full unicode support out of std because they don't want language releases dependent on unicode updates.

> they don't want language releases dependent on unicode updates.

I'm sorry, what do you mean by this?

Re: Failing to Learn Zig via Advent of Code

#177

Post by all2 »

AnIdiotOnTheNet wrote: post #167
all2 wrote: post #163

Earlier quoted context omitted.

I like this idea quite a lot. If you can write the tutorial itself in a "literate code" sort of way, the test harness should be able to consume the entire tutorial and run tests against it. Presuming, of course, that there's a way to tangle/weave using standard comments in Zig. Sounds like it could be a fun project. Could also serve as a way to auto-doc (like JavaDocs or similar using documentation generators).

Zig already does this with its current documentation and example code.

I saw that after reading further. Loris (I don't remember his user name here) also said he plans on rewriting it from scratch on Twitch. I may tune in just to see how his mind works. :D

Re: Failing to Learn Zig via Advent of Code

#178

Post by defen »

forrestthewoods wrote: post #157
llimllib wrote: post #54

Earlier quoted context omitted.

That complaint was weird, here's my day 7 solution in zig built in release mode: $ time zig build-exe ./a.zig -O ReleaseSmall real 0m1.728s user 0m1.544s sys 0m0.292s Which is actually slower than running the entire solution in debug mode: $ time zig run a.zig -- input.txt min 337 342641 min 470 93006301 real 0m1.138s user 0m0.789s sys 0m0.270s Totally possible that it's much slower on the dev's machine, but if he's…

Blog author here. I'm an Intel i7-8700k desktop. A few years old at this point, but quite beefy. Maybe this is a Windows issue? If I run "zig build" and then immediately run "zig build" again it still takes 3 seconds.

Sounds like something is messed up with your zig cache. I have a medium-size project (30 files, 10s of thousands of lines of code) that takes 0.07 seconds to `zig build` if nothing has changed. This is on a Mac.

Re: Failing to Learn Zig via Advent of Code

#179

Post by futharkshill »

zokier wrote: post #133
ReleaseCandidat wrote: post #55

Earlier quoted context omitted.

> `a+b` will have the same value as `b+a` No, as IEEE754 doesn't even guarantee that `a + b` == `a + b`. You always need to compare the absolute difference of two values against an ε. So a == b |a - b| But for sensible comparison of floats, the addition is commutative.

> No, as IEEE754 doesn't even guarantee that `a + b` == `a + b` What? I'm pretty sure that is plain incorrect. Can you back that claim up with references?

Of course it is incorrect, the system is of course not stochastic, not even floating points.

Re: Failing to Learn Zig via Advent of Code

#180

Post by pjmlp »

iTokio wrote: post #26
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…

Reading the source code is very helpful if you are an experimented programmer that already grasped the basics of the language. It helps you to see what are the idioms, what does optimized production code look like. Compare C++ and Go std lib and it’s easy to constate the difference in language goals that they have.

Including the workarounds Go has gone through due to lack of generics, e.g. sync.Map.
Post reply on HN