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

221–230 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#221

Post by anonymoushn »

forrestthewoods wrote: post #156
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…

> I would have thought that the usage of parseInt, was fairly obvious from the type-signature: Blog author here. In hindsight yes it's obvious. I think my problem was a lack of understanding of comptime types. They're a little different from C++ / Rust since they're passed as args. Looking back I think I found the Zig docs less "sticky" than other languages. The concepts are familiar but just new enough I don't under…

> It has comptime types and it also has a TypeInfo built-in with some degree of reflection? Is that runtime reflection maybe?

I do wish this was explained more prominently! The way this seems to work is that Zig has a lazy runtime for Zig code at compile time that does some interning (such that identical types obtained separately are equal, identical strings obtained separately are equal, etc.), and some types such as type can only exist in this runtime, not in the actual uh "run time" runtime. TypeInfo is for iterating over struct, union, or enum definitions at compile time to generate code. You'd use it if you wanted to write a generic json parser and serializer or if you wanted to write a type that's like an arraylist but internally uses a struct-of-arrays layout. Both of these are in the standard library and make informative reading.

TypeInfo itself is a union that can exist at runtime, but I don't think you can get into a situation where you have something at runtime and you don't know what type it is already. So actually using the TypeInfo at runtime may not be very useful.

> Zig appears to not report compiler errors for functions that get optimized out.

This is apparently caused by the laziness. The docs suggest using std.testing.refAllDecls(@This()) to have the compiler check unreachable code. I mean the actual usable docs at https://ziglang.org/documentation/master/#Nested-Container-T... rather than the automatically generated stdlib docs.

Re: Failing to Learn Zig via Advent of Code

#222

Post by dundarious »

yjftsjthsd-h wrote: post #181
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…

> Zig is basically C with a fancy type system, so you should not expect things like special String types, If I can't have nice strings, what should I be expecting from a fancy type system?

Zig's "fancy" (I don't think they're that fancy) type features that IMO make it a great C alternative are:

- non-null pointers, and distinct types for single-item pointers and multi-item pointers (multi-item pointers are rarely used except indirectly via slices, so unchecked pointer arithmetic errors are largely banished)

- builtin tagged unions (AKA algebraic data types) with very pleasant to use switch logic -- it can't be overstated how nice the "handle all the cases" logic is in Zig in general (catch, orelse, if-else/switch expressions)

- a decent proposition for errors (the error union, and try keyword), but I haven't decided if I really like it yet

There's lots of non-type stuff there too. I was writing personal projects in C without libc, but found there to be a lot of annoying work involved -- happy to do it, but it's not earned/fruitful annoyance, more like a long list of incidental historical annoyances. Zig seems to cater to the same level of the stack, but with all that boring stuff taken care of.

Re: Failing to Learn Zig via Advent of Code

#223

Post by ryukoposting »

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…

I feel like Nim is a much closer comparison than Rust. All three could be described as "grassroots projects on a holy mission to replace C and/or C++," but Nim and Zig are more similar in terms of operating budget/team size/adoption rate.

I may be a bit biased, but many of the problems mentioned in the post are the sorts of things I haven't dealt with in Nim for probably 2 years. Nim's error messages are still hit-or-miss and {.gcsafe.} still haunts me in my dreams, but the stdlib and language documents are great, and most of the annoying gotchas have been fixed.

Re: Failing to Learn Zig via Advent of Code

#224

Post by jolux »

nyberg wrote: post #171
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

> not depriving users of control when they know better than the type checker/lifetime analysis.

You're never deprived of control though, that's what unsafe is for, and it provides roughly the same level of safety as C or Zig would.

Re: Failing to Learn Zig via Advent of Code

#225

Post by ryukoposting »

anonymoushn wrote: post #210
jolux wrote: post #204

Earlier quoted context omitted.

> memory-safety can be achieved in other ways I mean, as far as achieving it at compile time, I would say it remains to be seen whether Zig's approach is one of these ways. There are certainly other known approaches, like the way ATS models pointers as proof objects, but these are also fairly abstract. > Zig is C, it's not meant to abstract away memory management. This is just hiding the ball though. Why don't we wan…

> There is no runtime cost to providing the abstraction that Rust does. This is technically true, but if I want to write a program that does not call malloc in its steady state, I can't use the stdlib or any library that uses the stdlib.

Herein lies the second biggest barrier to Rust's viability in embedded systems. (The first being that no microcontroller OEM ships libraries for Rust)

Re: Failing to Learn Zig via Advent of Code

#226

Post by tialaramex »

pjmlp wrote: post #203
tialaramex wrote: post #197

Earlier quoted context omitted.

Influence. A completely amazing amount of Java was written (is being written) and there's a huge workforce in that language. I think that it's possible if say Gosling hated + concatenating and had provided Java with a different String concatenate (it clearly wants a concatenate operator, but it needn't be named +) we'd see that popularised and while some languages with overloading might overload + it wouldn't be ubiq…

What? Influence, what a nonsense. Even BASIC uses it, and it was everywhere during the 15 years that preceded Java. Let alone all the other languages since Jovial that can't be bothered to dig out just to prove my point.

Huh. I'm pretty sure that at least some BASIC dialects I used did not have concatenation, but you seem to be correct that in general they did. This intrigued me enough to go dig through nested "from old machine" directories until I found some BASIC (I'm going to guess that I have not written any BASIC since about 1992) and you're correct that BASIC from the era which didn't live on cassette tape and thus I still own does have concatenating + operators in it.

I stand corrected.

Re: Failing to Learn Zig via Advent of Code

#227

Post by jolux »

ryukoposting wrote: post #225
anonymoushn wrote: post #210

Earlier quoted context omitted.

> There is no runtime cost to providing the abstraction that Rust does. This is technically true, but if I want to write a program that does not call malloc in its steady state, I can't use the stdlib or any library that uses the stdlib.

Herein lies the second biggest barrier to Rust's viability in embedded systems. (The first being that no microcontroller OEM ships libraries for Rust)

But this is not a fundamental limitation, there's nothing about the language that requires you to use heap allocation. That it contains affordances for safe heap allocation is a good thing, but you're not required to use them. There's always no_std and unsafe.

Re: Failing to Learn Zig via Advent of Code

#228

Post by Comevius »

jolux wrote: post #204
Comevius wrote: post #183

Earlier quoted context omitted.

There is nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Zig is C, it's not meant to abstract away memory management. You can do whatever in Zig, write a specialized allocator that's verified to be correct, even for a microcontroller with 2 KiB memory. Zig is a machine-oriented language, which means no hidden control flow, no hidden allocation. You can write…

> memory-safety can be achieved in other ways I mean, as far as achieving it at compile time, I would say it remains to be seen whether Zig's approach is one of these ways. There are certainly other known approaches, like the way ATS models pointers as proof objects, but these are also fairly abstract. > Zig is C, it's not meant to abstract away memory management. This is just hiding the ball though. Why don't we wan…

Here is an example with a keyboard firmware why you might not always want all that complexity.

https://kevinlynagh.com/rust-zig/

https://zig.news/aransentin/analysis-of-the-overhead-of-a-mi...

The point of languages like C and Zig is that they are only a bit higher level than assembly for portability, but otherwise they don't hinder you to do whatever. It's up to you to solve problems like memory safety. You might not even have a memory safety problem because you don't have memory in the first place, or your use case makes memory safety trivial.

Re: Failing to Learn Zig via Advent of Code

#229

Post by meheleventyone »

cbdumas wrote: post #207
meheleventyone wrote: post #189

Earlier quoted context omitted.

It’s a bit of a non-issue really. Once you’ve worked with the non-overloaded version for a while you quickly get used to it. The overloaded version is also superficially simple but loses information. For example, multiply versus multiplyScalar versus applyQuaternion on a vector which might all be represented by overloads of the multiply operator.

Why include the infix operators at all then? If it's just as clear without them maybe even machine native types don't need them.

They’re only operating on scalar values. In some languages differing types and unsafe coercion rules mean it’d probably be clearer if they weren’t used.

And I don’t believe I said they were just as clear, just that it’s no big deal to get used to and gave an example where overloading muddies the waters.

Re: Failing to Learn Zig via Advent of Code

#230

Post by pasabagi »

dagmx wrote: post #146
klyrs wrote: post #127

Earlier quoted context omitted.

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.

I've only ever really seen it in Zig communities that Rust is closer to C++ In Rust communities, it's often pitched as alternates to both, but closer to C. I suppose it's all relative, but the comparison of rust to c++ seems external

I don't really understand how Rust could be compared to C. Rust is perhaps more austere than C++, but that's like saying the neptune is smaller than jupiter. It's still a big language with a generous standard library. You almost never do everything yourself, by hand, which is the hallmark of the C experience. Just compare the list of methods rust has for a &str, compared to the fact C doesn't have a string type, to see the gulf of cultural difference.

Obviously, C and Rust are both low-level languages (in terms of control and overhead), but there are quite a few of those.

Post reply on HN