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

71–80 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#71

Post by heavenlyblue »

adito wrote: post #50
ralphb wrote: post #27

Earlier quoted context omitted.

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?

> I'm newbie and I still found that zig standard library still daunting to read

If you're a newbie, why are you learning an experimental language?

Re: Failing to Learn Zig via Advent of Code

#72

Post by edflsafoiewq »

thom wrote: post #57
user-the-name wrote: post #43

Earlier quoted context omitted.

I can not read that at all .

On the premise that someone might write LISP for a living, I'm saying it can help clarify a multistep mathematical expression. It's incredibly tedious to relitigate people's feelings about brackets over and over again.

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 displays this structure (though less well than the infix notation IMO)

  (+ (* a (- 1 t))
     (* b t))

Re: Failing to Learn Zig via Advent of Code

#73

Post by ralphb »

adito wrote: post #50
ralphb wrote: post #27

Earlier quoted context omitted.

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?

I am also a zig newbie. Since zig is a relatively simple language, I've found it easy enough to read and understand what is going on in the zig standard library, even if I don't understand the particular details of some language syntax. Of course experience and background is going to play in here.

The zig standard library does the following to help me:

- Logical, straightforward code, no magic incantations

- Well named variables and functions

- Comments

- Folder structure is easy to navigate

- Easy to find on github - not hidden away

Obviously your mileage may vary.

Re: Failing to Learn Zig via Advent of Code

#74

Post by Zababa »

dnautics wrote: post #64
the_duke wrote: post #59

Earlier quoted context omitted.

I also tried out Zig a while ago and was frustrated by the lack of good learning materials. Zig is 6 years old. Rust had much better documentation at this stage of development. To be fair though: Rust also had corporate backing and a larger fan base contributing to the book and std docs.

Seriously, comparing by timeline like that is an unfair comparison. You should probably kick a few dollars into the zig foundation as penance for having made it publically. ;)

> comparing by time spent is an unfair comparison

Yes, and language competition is unfair. As a user, I don't care that Zig is more "cost/time effective" than Rust or Java, I care about the end result. The end result, right now, is a worse documentation than lots of other languages. That doesn't mean that the people behind Zig are bad or anything like that. That just means that when choosing between X and Zig, Zig's documentation (and lack of such documentation) will influence my choice.

I'm not sure why you would not compare by timeline, as this is probably the best predictor of where a language will be in the next years, which is important data as well.

Re: Failing to Learn Zig via Advent of Code

#75

Post by tialaramex »

ayende wrote: post #46
flohofwoe wrote: post #36

Earlier quoted context omitted.

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

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 defined to return u64
You had to explicitly change the return type of the method to cause yourself a surprise, Rust won't chase this rabbit through a warren, every individual function has to declare the types of its parameters and returns, so if you'd changed the function body not its declared return type, it could not have caused any change in type inference in other functions.

Re: Failing to Learn Zig via Advent of Code

#76

Post by dnautics »

Zababa wrote: post #74
dnautics wrote: post #64

Earlier quoted context omitted.

Seriously, comparing by timeline like that is an unfair comparison. You should probably kick a few dollars into the zig foundation as penance for having made it publically. ;)

> comparing by time spent is an unfair comparison Yes, and language competition is unfair. As a user, I don't care that Zig is more "cost/time effective" than Rust or Java, I care about the end result. The end result, right now, is a worse documentation than lots of other languages. That doesn't mean that the people behind Zig are bad or anything like that. That just means that when choosing between X and Zig, Zig's…

If you're going to compare that way (and I contend you shouldn't) at least normalize by programmer hours, or take into account growth.

Re: Failing to Learn Zig via Advent of Code

#77

Post by ralphb »

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…

Rust was started in 2006. [1]

Zig was started in 2015. [2]

[1] https://en.wikipedia.org/wiki/Rust_(programming_language) [2] https://en.wikipedia.org/wiki/Zig_(programming_language)

Re: Failing to Learn Zig via Advent of Code

#78

Post by delphLonepaw »

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…

I don't think a lot, I have no problems with UTF-8 strings (unless you speak in the source code, haven't tried), faster than c and rust when it can, ofc, I saw a rust program, made my own with zig, and it's fast , and I didn't even optimize that much.

Compiling is faster than rust and C a lot of the times

We have packages, and a good few, thing is, this is no rust big, we don't have mozilla nor to backup and work into it.

I don't think is overpromise, Vlang is overpromise, zig atm, is slowly getting there, no promises on when

Re: Failing to Learn Zig via Advent of Code

#79

Post by latch »

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…

> ArrayList explicitly manages a contiguous region of memory, so I don't see the problem with exposing it as a slice as part of the interface.

It used to be that you'd get an allocator by taking a pointer to the allocator field (&gpa.allocator), in 0.9.0 that was changed to a function call (gpa.allocator()) and thus broke _a lot_ of things.

Exposing all these fields seems like it'll cause challenges when trying balance backwards compatibility vs breaking changes.

Re: Failing to Learn Zig via Advent of Code

#80

Post by kristoff_it »

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 implements the full unicode spec.

https://github.com/jecolon/ziglyph

You might not like how it's done, but its factually incorrect to state that Zig can't handle unicode.

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

From my reddit reply to this same topic:

This podcast interview might not be the best showcase of the practical implications of Zig's take on safety and performance. If you want something with more meat, I highly recommend Andrew's recent talk from Handmade Seattle, where he shows the work being done on the Zig self-hosted compiler.

https://media.handmade-seattle.com/practical-data-oriented-d...

Lots of bit fiddling that can't be fully proven safe statically, but then you get a compiler capable of compiling Zig code stupidly fast, and that's even without factoring in incremental compilation with in-place binary patching, with which we're aiming for sub-millisecond rebuilds of arbitrarily large projects.

> The ecosystem for zig is insignificant now and a stable release would help the language.

I hope you don't mind if we don't take this advice, given the overall tone of your post.

Post reply on HN