Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig Zen Update

codeberg.org

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Zig Zen Update

#51

Post by Panzerschrek »

ozgrakkurt wrote: post #50
Panzerschrek wrote: post #43

Earlier quoted context omitted.

Such things should be solved in more nice way, not by manually checking every allocation. Like via lightweight threads, with each of them having their own memory and a scheduler, which kills threads exceeding their memory limit.

This compilicates things more compared to functions returning Result . You also get locality benefits from bump style allocators. And you don't need SmallVec or similar optimization containers. And you also avoid mental overhead of managing many allocations in your head (or using a language with borrow checking).

> This compilicates things more compared to functions returning Result.

Checking each Result in a large program is more complicated than having a runtime library handling memory limits properly.

> And you also avoid mental overhead of managing many allocations in your head

That's exactly what languages like Zig force you to do, compared to something like C++ or Rust.

> or using a language with borrow checking

borrow checking gives memory safety. It's also important to have.

Re: Zig Zen Update

#52

Post by Panzerschrek »

lionkor wrote: post #46
Panzerschrek wrote: post #40

Earlier quoted context omitted.

> If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, It's most of environments. Basically any program running under a modern OS. So, why do this language exists, if its practical applicability is so small?

On modern OSs you can write Zig and just ignore allocation errors. It doesn't force you to handle them properly. This language exists to supercede or supplement C, not JavaScript or C#. It's practical applicability is similar to that of C, so I struggle to comprehend how it is "so small".

> On modern OSs you can write Zig and just ignore allocation errors.

I can ignore errors, but I still need to free memory manually if I want to avoid memory leaks. Languages like C++ or Rust have destructors, which do the job for me.

> This language exists to supercede or supplement C

There are way better alternatives, like Rust. Even C++ is better.

Re: Zig Zen Update

#53

Post by Panzerschrek »

Zambyte wrote: post #47
Panzerschrek wrote: post #40

Earlier quoted context omitted.

> If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, It's most of environments. Basically any program running under a modern OS. So, why do this language exists, if its practical applicability is so small?

This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail. Let's say you write an application that runs as a Unix daemon in Zig. Later you may decide that your application is really the only thing you're interested in running on the target machine, and for performance and predictability reasons, you'd prefer to boot directly to your…

> This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail.

In my hypothetical example of a language where allocation fails aren't exposed it's possible too. An allocation fail just triggers a full system reboot.

Re: Zig Zen Update

#54

Post by kibwen »

Zambyte wrote: post #48
kibwen wrote: post #45

Earlier quoted context omitted.

Rust doesn't stop you from checking if memory allocation has failed. Its libstd provides many operations that don't bother to surface memory allocation failure (for the reasons given above), but that's why Rust provides a libcore that does no allocation, while continually working to push more things down from libstd into libcore, while providing alternative APIs in libstd to let you handle allocation failure if you k…

Conversely, Rust doesn't force you to explicitly handle if memory allocation failures. The least you can do in Zig is explicitly ignore allocation failures.

You can certainly write data structures in Zig that swallow allocation failures rather than surfacing them. We're talking about library-level concerns, not language-level concerns. Both Rust and Zig give you the power to allocate raw memory and handle the result of that syscall however you want, it's the standard libraries that differ beyond that point.

Re: Zig Zen Update

#55

Post by peesem »

alberth wrote: post #29

OT: any word on how Codeberg has been working out for Zig?

the maintainers seem happy, especially now that CI is actually working how it's supposed to. but a non-rare complaint in the Zig discord is how slow Codeberg can be, and other things like the lack of codesearch hurt as well.

Re: Zig Zen Update

#56

Post by ksec »

melon_tusk wrote: post #10

I don't see how Zig will ever contend with Odin, Jai, C3 and others when they drive away half of the prospective users with activism.

>when they drive away half of the prospective users with activism.

Like what? Plenty of people here follows Zig here and haven't seen any of it. And by any measure it is the least activism per language usage.

Re: Zig Zen Update

#57

Post by iroddis »

Fraterkes wrote: post #8
mcherm wrote: post #6

Nicely done! I always felt that Python's "There should be one-- and preferably only one --obvious way to do it." was a bit of a mess. Obviously (to anyone who was around at the time), that plank was written in response to Perl's motto: "There is more than one way to do it." Zig's original take on this, "Only one obvious way to do things" seems even worse. You see, both languages agree that Perl had it wrong: it is un…

I think people criticize that line in the zen of Python because Python has now become very maximalist. On it's own merits, I think "There should be one obvious way to do it" is much better, less clunky, than "There is an idiomatic way to do it". Also, importantly, the Zen of Python is kinda written as a set of ideas that Python should aspire to ("there should be one obvious way to do it") instead of a sales pitch of…

It all sounds great until someone writes nested list comprehensions. They are the recommended, idiomatic way to things most sane people would use ‘map’, ‘filter’, and ‘reduce’ chains, although chains are another thing python very much dislikes.

Re: Zig Zen Update

#58

Post by geophph »

mcherm wrote: post #6

Nicely done! I always felt that Python's "There should be one-- and preferably only one --obvious way to do it." was a bit of a mess. Obviously (to anyone who was around at the time), that plank was written in response to Perl's motto: "There is more than one way to do it." Zig's original take on this, "Only one obvious way to do things" seems even worse. You see, both languages agree that Perl had it wrong: it is un…

I always read this as a tongue in cheek joke b/c of how the — appears left aligned, then right aligned, then elsewhere in the Zen center aligned, sort of pointing to how yeah there’s multiple ways to do things …

Re: Zig Zen Update

#59

Post by logicchains »

Permik wrote: post #19
logicchains wrote: post #14

Earlier quoted context omitted.

[flagged]

I'm not sure that if this is an obvious question that has been gone through already, but have any of the death threats relating to Rust stuff actually been "verified" or is it just an opinion that has been repeated enough times until it has been accepted as truth? Just the open amount of discontent towards the language and the community, creates the perfect storm for a malicious individual to pose being a Rust develo…

https://steveklabnik.com/writing/a-sad-day-for-rust/

Re: Zig Zen Update

#60

Post by Zambyte »

kibwen wrote: post #54
Zambyte wrote: post #48

Earlier quoted context omitted.

Conversely, Rust doesn't force you to explicitly handle if memory allocation failures. The least you can do in Zig is explicitly ignore allocation failures.

You can certainly write data structures in Zig that swallow allocation failures rather than surfacing them. We're talking about library-level concerns, not language-level concerns. Both Rust and Zig give you the power to allocate raw memory and handle the result of that syscall however you want, it's the standard libraries that differ beyond that point.

Yes, it is a standard library difference. But unless you plan on rewriting the entire Rust ecosystem, you're going to be dealing with invisible failure points in Rust code that you would not be dealing with when writing the equivalent Zig code. The standard library is almost as fundamentally important to a language as it's built-in operators.

And Zig does have language-level features that combine to require you to explicitly handle propagated errors (error sets, requiring all return values be explicitly handled, requiring all switch cases be explicitly handled). Rust has a similar set of features (pattern matching, requiring all match cases be explicitly handled), but does not use them for allocation (Box::new, vec![], etc. does not return a Result value).

Post reply on HN