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

Why is Zig so cool?

nilostolte.github.io

Post reply on HN
Print view View original

371–380 of 527 posts

Re: Why is Zig so cool?

#371

Post by jandrewrogers »

fpoling wrote: post #161
qouteall wrote: post #70

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…

There are plans in Zig to allow to include custom information into error stack trace https://github.com/ziglang/zig/issues/14446 . But that is not implemented. In any case, when debugging annotating error with extra context often is not enough. One often needs a detailed trace of what happens before. So what I would like to see in any programming language is ability to do a structured logging with extra context from…

I made a go of this using the stacktrace functionality built into C++23. The overhead and complexity it introduced made it not worth it, unfortunately. There may be a way to do this but it seems non-trivial in implementation.

Re: Why is Zig so cool?

#373

Post by tamnd »

tialaramex wrote: post #369
tamnd wrote: post #333

Earlier quoted context omitted.

I have learned that too. If you write about C, almost no one clicks. It is not new, it is not flashy, and it does not promise easy results. Yet almost everything still runs on it. The quiet parts of computing rarely get attention, even though they keep everything working. I still write about C anyway. It may not trend, but it lasts.

I'm sure I'm not alone - after decades - already knowing far too much about C, so that any article I'm likely to read either I'm like "No, that's wrong and I even understand why you thought that, but it's still wrong" or I just nod along and sigh. I spent a substantial fraction of my professional career writing C, and I remain interested in WG14 (the language committee) and in several projects written in C though I a…

Thanks for sharing your thoughts. I have never deployed any production C code and I would not choose C for professional work either, but learning it, with all its rough edges, has made me a better engineer. It helps me understand how things really work under the hood. No pain, no gain.

Maybe I am biased, but for professional work, I stay with Go. I have built large distributed data systems that handle hundreds of millions of business transactions daily, and Go has been steady and reliable for that scale. Its simplicity, strong concurrency model, and easy deployment make it practical for production systems. I still enjoy exploring Zig and Rust in my spare time, but for shipping real systems, Go continues to get the job done without getting in the way.

Re: Why is Zig so cool?

#374

Post by tamnd »

tialaramex wrote: post #369
tamnd wrote: post #333

Earlier quoted context omitted.

I have learned that too. If you write about C, almost no one clicks. It is not new, it is not flashy, and it does not promise easy results. Yet almost everything still runs on it. The quiet parts of computing rarely get attention, even though they keep everything working. I still write about C anyway. It may not trend, but it lasts.

I'm sure I'm not alone - after decades - already knowing far too much about C, so that any article I'm likely to read either I'm like "No, that's wrong and I even understand why you thought that, but it's still wrong" or I just nod along and sigh. I spent a substantial fraction of my professional career writing C, and I remain interested in WG14 (the language committee) and in several projects written in C though I a…

> I'm sure I'm not alone - after decades - already knowing far too much about C, so that any article I'm likely to read either I'm like "No, that's wrong and I even understand why you thought that, but it's still wrong" or I just nod along and sigh.

If you have some spare time, I would really like to hear more about your experiences. It sounds like you have worked with C for a long time, and that kind of insight is hard to find now.

Most people around me started with JavaScript or TypeScript as their first language, and for many, that is still all they know. I mean no disrespect, it is just how things are today. It would be great to hear how your view of programming has changed over the years and what lessons from C still matter in your work today.

Re: Why is Zig so cool?

#375

Post by pron »

WalterBright wrote: post #150
unscaled wrote: post #93

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.

Partial evaluation has been quite well known at least since 1943 and Kleene's Smn proof. It has since been put to use, in various forms, by quite a few languages (including C++ in 1990, and even C in the early seventies). But the extent and the way in which Zig specifically puts it to use -- which includes, but is not limited to, how it is used to replace other features that can then be avoided (and all without macros) -- is unprecedented.

Pointing out that other languages have used partial evaluation, sometimes even in ways that somewhat overlap with Zig's use, completely misses the point. It's at least as misplaced as saying that there was nothing new or special about iPhone's no-buttons design because touch screens had existed since the sixties.

If you think Zig's comptime is just about running some computations at compile time, you should take a closer look.

Re: Why is Zig so cool?

#376

Post by ksenzee »

rkomorn wrote: post #162
ksenzee wrote: post #159

Earlier quoted context omitted.

You truly don't see how "you didn't get my joke because you're autistic" is not an insult, to people who did you the courtesy of assuming good faith? Not to drag this out, and I don't personally have an autism diagnosis, but seriously this is no way to act in a space where autism is overrepresented.

Did you accidentally double negative?

I did, thanks :)

Re: Why is Zig so cool?

#377

Post by beej71 »

scotty79 wrote: post #329
SonnyTark wrote: post #305

This is a very confusing blog post. I found myself looking for ChatGPT markers because it doesn't make sense to say: omg zig is so much cooler than C here's why, then start listing the absolute basics of the language that are identical in most modern languages without any actual reflection why writing the same thing in a different syntax somehow makes zig superior?

What I got was: - pointers to bitfields - checked bitshifts - small ints like u4 - imperative array initialization blocks - test code blocks - equivalent of debugger; keyword from js - some vague stuff about being able to do at compile time The rest is pretty generic

I had to dig farther on the compile time execution stuff. It's actually pretty cool-looking. Recommend digging into it. I don't know that it's a killer enough feature to draw me away from Rust's guarantees, but it is interesting.

Re: Why is Zig so cool?

#378

Post by tmtvl »

jb1991 wrote: post #211
unscaled wrote: post #93

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…

> C/C++ It has been several decades since putting a slash between these two made sense, lumping them together like this. It would be similar to saying something like Java/Scala or ObjectiveC/Swift. These are completely different languages.

The problem is that it's a bit tricky to type the intersection symbol (∩), because C ∩ C++ makes more sense.

Re: Why is Zig so cool?

#379

Post by jibal »

zozbot234 wrote: post #188
chrisco255 wrote: post #164

Earlier quoted context omitted.

Zig's generics can potentially, but not necessarily, because Zig's generics are explicitly controlled through comptime functions, which give the developer a ton of control of how the generic code is unrolled. They're also frequently less used in general than Rust generics. Of course both Zig and Rust are good languages. But my experience, and I believe your experience will be too if you try to compile programs of sim…

Rust has macros that allow for arbitrary compile-time generated code, just like Zig. Most Rust-compiled programs are a bit bloated because libstd is statically linked and not rebuilt from scratch with a project-specific trimmed feature set, which leads to potentially unwanted code being included for e.g. recoverable panics, backtraces, UTF-8 string handling etc. A set of new RFC's is being worked on that may at some…

> Rust has macros that allow for arbitrary compile-time generated code, just like Zig.

This is not true. Zig, D, and Nim all have full-language interpreters built into the compiler; Rust does not. Its macros (like macros generally) manipulate source tokens, they don't do arbitrary compile-time calculations (they live in separate crates that are compiled and then run on source code, which is very different from Zig/D/Nim comptime which is intermixed with the source code and is interpreted). Zig has no macros (Andrew hates them)--you cannot "generate code" in Zig (you can in D and Nim); that's not what comptime does. Zig's comptime allows functions written in Zig to execute at compile time (the same functions can also be used to run at execution time if they only use execution-time types). The Zig trick is that comptime code can not only operate on normal data like ints and structs, but also types, which are first class comptime objects. Comptime code has access to the TypeInfo of types, both to read the attributes of types and to create types with specified attributes, which is how Zig implements generics.

Re: Why is Zig so cool?

#380

Post by jandrewrogers »

comex wrote: post #201
jandrewrogers wrote: post #117

Earlier quoted context omitted.

I would highlight `std::launder` as an example. It was added in C++17. Famously, most people have no idea what it is used for or why it exists. For low-level systems it was a godsend because there wasn’t an official way to express the intent, though compilers left backdoors open because some things require it. It generates no code, it is a compiler barrier related to constant folding and lifetime analysis that is par…

I don't think that's quite right. For DMA you would normally use an empty asm block, which is what's typically referred to as a "compiler barrier" and does tell the compiler to discard everything it knows about the contents of a some memory. But std::launder doesn't have the same effect. It only affects type-based optimizations, mainly aliasing, plus the assumption that an object's const fields and vtable can't chang…

This doesn't seem quite right. The asm block case is equivalent to adding a volatile qualifier to the pointer. If you add this qualifier then `std::launder` produces the same codegen.

I think the subtle semantic distinction is that `volatile` is a current property of the type whereas `std::launder` only indicates that it was a former property not visible in the current scope. Within the scope of that trivial function in which the pointer is not volatile, the behavior of `std::launder` is what I'd expect. The practical effect is to limit value propagation of types marked `const` in that memory. Or at least this is my understanding.

DMA memory (and a type residing therein) is often only operationally volatile within narrow, controlled windows of time. The rest of the time you really don't want that volatile qualifier to follow those types around the code.

Post reply on HN