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

211–220 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#211

Post by eximius »

k__ wrote: post #158
dagmx wrote: post #146

Earlier quoted context omitted.

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

Yes, I also had the impression Rust is a C replacement.

From a programming language design space, it's much more like C++.

However it can occupy some niches that C can but C++ does poorly because of zero cost abstractions, I think.

(Very handwavy)

Re: Failing to Learn Zig via Advent of Code

#212

Post by anonymoushn »

forrestthewoods wrote: post #206
defen wrote: post #178

Earlier quoted context omitted.

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.

How do I clean the zig cache? There does not appear to be a "zig clean".

rm -rf zig-cache over here

Re: Failing to Learn Zig via Advent of Code

#213

Post by c-cube »

Kwpolska wrote: post #125
kristoff_it wrote: post #80

Earlier quoted context omitted.

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

That's not "simple". Rust also does neither of those two tasks with just the stdlib!

- latin1 is dead and should be in no stdlib in 2022 - uppercasing requires the current Unicode tables, so, a largish moving target that you probably don't want to embed in small programs.

Re: Failing to Learn Zig via Advent of Code

#214

Post by jshier »

futharkshill wrote: post #176
cturtle wrote: post #132

Earlier quoted context omitted.

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?

The "rules" of unicode change over time with updates to the unicode standard(s). One big one is the grapheme breaking algorithm, which has been updated over time to support things like the family emoji and other compositions.

Re: Failing to Learn Zig via Advent of Code

#215

Post by laserbeam »

anonymoushn wrote: post #150
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 never thought about this until now, but I guess it's actually super weird that ArrayList doesn't expose a getter-by-index and an iterator and instead expects you to use .items.

The thing is... Every function in the std works with slices, not woth array lists. You pass slices to mem.tokenize(), you pass alices to mem.cmp(), you pass a slice to sort().

I think that's why ArrayList exposes it for you, so you can just use it as a regular slice everywhere. I, honestly, find that simple and liberating. I'm glad there's no other kind of accessor thing.

Continuous memory is just fast, and if you have some first class support for working with it, it makes no sense to duplicate the api. But again, if you want a hashmap you don't get the slice, for the slice doesn't make sense there...

Re: Failing to Learn Zig via Advent of Code

#216

Post by c-cube »

futharkshill wrote: post #179
zokier wrote: post #133

Earlier quoted context omitted.

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

What if a is nan? You don't have that nan == nan...

Re: Failing to Learn Zig via Advent of Code

#217

Post by laserbeam »

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…

As far as I know, typeinfo is used at compile time. In general, doing runtime type shenanigans involves implementing things like vtables, and some other weirdness. This breaks "no hidden control flow".

If you do that at comprime instead, the thing that runs at runtime is just memory offsets. You can for example generate code that parses json into 30 types you know at compile time, or you can use things like hashmaps and arraylists and whatnot to do it at runtime.

You get a lot of mileage by just doing the dynamic code away from runtime, and that's one of the benefits of comptime. And it's a slow thing to realize, also not necessarily something everyone cares about.

Re: Failing to Learn Zig via Advent of Code

#218

Post by forrestthewoods »

anonymoushn wrote: post #212
forrestthewoods wrote: post #206

Earlier quoted context omitted.

How do I clean the zig cache? There does not appear to be a "zig clean".

rm -rf zig-cache over here

Ah didn't realize it was just a folder in the project directory, oops!

Nuked zig-cache and zig-out, rebuild, no change in build times.

Re: Failing to Learn Zig via Advent of Code

#220

Post by nix23 »

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.

>>Feature Highlights Small, simple language

>>There is no hidden control flow, no hidden memory allocations, no preprocessor, and no macros.

https://ziglang.org/learn/overview/

It try's (achieves?) to be a C without the flaws and historic ballast.

Post reply on HN