Live data from Hacker News

Why is Zig so cool?

nilostolte.github.io

221–230 of 527 posts

Re: Why is Zig so cool?

#221

I'm afraid this article kinda fails at at its job. It starts out with a very bold claim ("Zig is not only a new programming language, but it’s a totally new way to write programs"), but ends up listing a bunch of features that are not unique to Zig or even introduced by Zig: type inference (Invented in the late 60s, first practically implemented in the 80s), anonymous structs (C#, Go, Typescript, many ML-style langua…

D has had compile time function execution since 2007 or so. https://dlang.org/spec/function.html#interpretation It doesn't need a keyword to trigger it. Any expression that is a const-expression in the grammar triggers it.

[flagged]

Re: Why is Zig so cool?

#222

Earlier quoted context omitted.

Rust's solution to this is quite good, that's 0..9 and if you want to include 9 it's 0..=9, it looks a bit funny but knowing one with an = sign in it exists removes any doubt

Adding additional syntax to a language for this case seems bonkers to me. People can just write 0..10.

[deleted]

Re: Why is Zig so cool?

#224
Why are people so obsessed with Zig when Odin has been stable, though not yet with official spec, for such a long time and used in real production for years? Is it just syntax preference or does Zig provide something amazing that I am missing? Not that I use any of them, I am not interested in manual memory management and i stick to Go. But I'm curious.

Re: Why is Zig so cool?

#226

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "somethin…

Agreed, this is probably my biggest ongoing issue with Zig. I really enjoy it overall but this is a really big sticking point.

I find it really amusing that we have a language that has built its brand around "only one obvious way to do things", "reducing the amount one must remember", and passing allocators around so that callers can control the most suitable memory allocation strategy.

And yet in this language we supposedly can't have error payloads because not every error reporting strategy is suitable for every environment due to memory constraints, so we must rely on every library implementing its own, yet slightly unique version of the diagnostic pattern that should really be codified as some sort of a language construct where the caller decides which allocator to use for error payloads (if any).

Instead we must hope that library authors are experienced and curious enough to have gone out of their way to learn this pattern because it isn't mentioned in any official documentation and doesn't have any supporting language constructs and isn't standardized in any way.

There must be an argument against this (rather obvious) observation but I'm not aware of it?

Re: Why is Zig so cool?

#227

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "somethin…

I can see pros and cons. Preventing data being attached to an error forces more clear and precise errors. Whereas lazy devs could just attach all possible data in a giant generic error if they don’t want to think about it.

I don't follow, because there's a possibility that someone somewhere might create a bad overly-generic error set if they were allowed to stuff details in the payload when those should be reflected in the error "type", it's a good idea to make the vast majority of error reporting bad and overly-generic by eliminating error payloads entirely?

Re: Why is Zig so cool?

#228

I love systems programming language and have worked on the Ada language for a long time. I find Zig to be incredibly underwhelming. Absolutely nothing about it is new or novel, the closest being comptime which is not actually new. Also highly subjective but the syntax hurts my eyes. So I’m kind of interested by an answer to the question this articles fails to answer. Why do you guys find Zig so cool ?

As someone who still thinks one should write C (so as a completely uncool person), what I like about Zig is that it is no-nonsense language that just makes everything work as it is supposed to be without unnecessary complications, D is similar, except that it fell into the trap of adding to many features.

So, no, I do not really see anything fundamentally new either. But to me this is the appealing part. Syntax is ok (at least compared to Rust or C++).

Having said this, I am still skeptical about comptime for various reasons.

Re: Why is Zig so cool?

#229

I'm afraid this article kinda fails at at its job. It starts out with a very bold claim ("Zig is not only a new programming language, but it’s a totally new way to write programs"), but ends up listing a bunch of features that are not unique to Zig or even introduced by Zig: type inference (Invented in the late 60s, first practically implemented in the 80s), anonymous structs (C#, Go, Typescript, many ML-style langua…

Yeah, as I keep repeating, it is a Modula-2 in C clothes, minus comptime, which as others have mentioned D has had for quite some time.
Post reply on HN