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

511–520 of 527 posts

Re: Why is Zig so cool?

#511

Post by smj-edison »

pjmlp wrote: post #506
smj-edison wrote: post #479

Earlier quoted context omitted.

That's fair. I was born twenty years after Modula-2 was released, so I definitely have gaps in my language knowledge :D

Plenty of material over here, https://www.modula2.org/index.php As for the other ones I listed, https://en.wikipedia.org/wiki/Mesa_(programming_language) (some PDFs linked from there) https://bitsavers.org/pdf/borland/turbo_pascal https://www.freepascal.org https://docwiki.embarcadero.com/RADStudio/Sydney/en/Delphi_D... and https://learn.adacore.com/index.html http://www.ada-auth.org/arm.html

Thanks!

Re: Why is Zig so cool?

#512

Post by nvlled »

kibwen wrote: post #493
nvlled wrote: post #462

Earlier quoted context omitted.

It's not the same, defer does not conditionally interrupt the flow of execution, it will always run at the end of a block. If I see a defer, I am absolutely certain that whatever is deferred will run. The same is not true for exceptions. If I am not mistaken defer just moves the code at the end of the block, no jumping is involved.

> It's not the same, defer does not conditionally interrupt the flow of execution, it will always run at the end of a block. But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block. > If I see a defer The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need…

> But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block

Why bring up destructors, I was talking about exceptions. Destructors and exceptions are orthogonal concepts, one can be implemented independently of the other. I'm specifically referring to try-catch blocks like those in java.

Compare this:

  try { foo(); }
  catch { bar(); }
to this:

  defer bar();
  foo();
In the first one, bar() may or may not run depending if there's an exception. In the second one, bar is guaranteed to run. Thus, it means defer does not conditionally interrupt the flow of execution.

> The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function.

What? You don't need to read the entire function, you only to scan or check for defers scoped in a block, or in some cases, just the top of a function or block. Wanting to just read the end of a function is unreliable anyway with the existence of early returns (which defer fixes by the way).

You could have made a more compelling (but not necessarily a valid) case by citing zig's try-catch, which makes me think that you are just arguing in abstract without actually having tried writing code that uses defer, or any zig code for that matter.

Re: Why is Zig so cool?

#513

Post by WalterBright »

pron wrote: post #486
WalterBright wrote: post #455

Earlier quoted context omitted.

The partial evaluation you mentioned.

I'm still not sure what exactly you're asking, but the implementation of print linked above ( https://ziglang.org/documentation/0.15.2/#Case-Study-print-i... ) typically requires some kind of syntactic macros in other lanugages as does something like "innerParse" here ( https://ziglang.org/documentation/0.11.0/std/src/std/json/st... ), this ( https://ziglang.org/documentation/0.15.2/#Generic-Data-Struc... ) would typ…

print is a fairly complicated case, as it has to deal with all kinds of different types.

I mean a simple example. Just to illustrate the concept. Like the examples I provided here:

https://news.ycombinator.com/item?id=45859669

Re: Why is Zig so cool?

#514

Post by kibwen »

nvlled wrote: post #512
kibwen wrote: post #493

Earlier quoted context omitted.

> It's not the same, defer does not conditionally interrupt the flow of execution, it will always run at the end of a block. But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block. > If I see a defer The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need…

> But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block Why bring up destructors, I was talking about exceptions. Destructors and exceptions are orthogonal concepts, one can be implemented independently of the other. I'm specifically referring to try-catch blocks like those in java. Compare this: try { foo(); } catch { bar(); } to this: defer bar(); foo(); In t…

I cite destructors specifically because Zig denounces destructors as "hidden control flow" while presenting defer as a non-hidden alternative to destructors, which I find to be an incoherent philosophy.

Re: Why is Zig so cool?

#515

Post by pron »

WalterBright wrote: post #513
pron wrote: post #486

Earlier quoted context omitted.

I'm still not sure what exactly you're asking, but the implementation of print linked above ( https://ziglang.org/documentation/0.15.2/#Case-Study-print-i... ) typically requires some kind of syntactic macros in other lanugages as does something like "innerParse" here ( https://ziglang.org/documentation/0.11.0/std/src/std/json/st... ), this ( https://ziglang.org/documentation/0.15.2/#Generic-Data-Struc... ) would typ…

print is a fairly complicated case, as it has to deal with all kinds of different types. I mean a simple example. Just to illustrate the concept. Like the examples I provided here: https://news.ycombinator.com/item?id=45859669

If you scroll a bit up on the page from the print example, you'll see more introductory stuff: https://ziglang.org/documentation/0.15.2/#Introducing-the-Co...

Re: Why is Zig so cool?

#516

Post by laladrik »

jibal wrote: post #116
sreekotay wrote: post #17

Earlier quoted context omitted.

This is the real answer (amongst other goodness) - this one is well executed and differentiated Every language at scale needs a preprocessor (look at the “use server” and “use gpu” silliness happening in TS) - why is it not the the same as the language you use?

Languages such as D and Nim (both greatly underappreciated) offer full-language compile-time interpretation.

Yeah, that's a pity that D didn't gain the popularity. It brought some features which were borrowed to mainstream languages. However, the features didn't help D to become popular. I have a hunch that templates from D were the inspiration for the comptime in Zig. Also, Reading D is almost easy as reading Zig. I remember I couldn't get my head around async/await from Python 3.5. I knew it was based on generators. However, the stack switch was absolutely mysterious to me. I understood it only from the implementation of fibers from the D's standard library.

Re: Why is Zig so cool?

#517

Post by raiph »

johnisgood wrote: post #344
lizmat wrote: post #275

Earlier quoted context omitted.

Please, stop deadnaming the Raku Programming Language :-)

I thought it was useful information for people who did not know this. Of course Wikipedia would have sufficed, too: "Raku, formerly known as Perl 6 [...]".

I hear you were coming from the angle of being useful. In a sense that's what matters most, and I love that you have that spirit.

If Wikipedia has deadnamed Raku with grace then that might be a model to follow, but in general it's far from helpful unless it's done carefully. There's a reason why the community embarked on the somewhat painful multi decade process of renaming it. To try clarify my understanding I'll summarize it here.

Because of the original name for Raku, people assumed for a long time (long after it became problematically misleading) that it shared semantics, or syntax, or compiler tech, or libraries, or something technical like that, with some other programming language(s).

This was partly because Raku did indeed take some inspiration philosophically and/or technically from some existing languages (traces of a half dozen or so are evident), and partly because Raku and its compiler tech features the ability to use Python code and compilers, and C code and compilers, and Perl code and compilers, and so on, as if they were native Raku code/compilers.

But Raku was never C, or Python, or Perl, and the old name is unfortunately a form of deadnaming -- which is to say, something that is seldom helpful, especially if some commentary like this comment is not included.

At least, that's how I experience it.

That said, regardless of my view, I love your impulse of being helpful, which is why I've written this -- and I hope it does help any readers.

Re: Why is Zig so cool?

#518

Post by justinhj »

pjmlp wrote: post #392
wffurr wrote: post #387

Earlier quoted context omitted.

Sure, but Zig is bringing those to users and making headlines on HN. I think that’s generally a good thing. Bringing the best of prior languages together in a new package

Except in 2025 we know better regarding safer systems programming languages, use after free is no longer something that we should tolerate.

It's way to early to declare Rust and borrow checking as a panacea for systems level languages. Zig has a solid story for memory safety but makes a different set of trade offs than Rust. IMHO there is room for a few different approaches to systems programming.

Re: Why is Zig so cool?

#519

Post by bnolsen »

pjmlp wrote: post #328
1718627440 wrote: post #321

Earlier quoted context omitted.

I mostly write C, but yes even a simple call to e.g. malloc has different semantics in C++ (you need to cast).

Proper C++ should use new , delete , custom allocators, and standard collection types. Even better, all heap allocations should be done via ownership types. Calling into malloc () is writing C in C++, and should only be used for backwards compatibility with existing C code. Additionally there is no requirement on the C++ standard that new and delete call into malloc() / free() , that is usually done as a matter of co…

Custom allocators in c++ was never enjoyable nor easy. It introduces more template slop everywhere. That's one thing I really liked about eastl, it did allocators much better. But it wasn't maintained.

Re: Why is Zig so cool?

#520

Post by bnolsen »

tourist2d wrote: post #111
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…

As a c++ developer who's heard of Zig but never dived into it, I was reading this article scratching my head wondering what is it actually so unique about it. Why the blog has a section on how it install it on the path is also very puzzling.

Zig is simple, clever and clean. certainly not perfect but it addresses much of what I disliked about c++. I wanted to like D and rust but they seem just as complex as c++. Yes, better in some ways but still full of complexity.
Post reply on HN