Live data from Hacker News

Why is Zig so cool?

nilostolte.github.io

261–270 of 527 posts

Re: Why is Zig so cool?

#261

Zig is not cool. It's a mediocre new language, missing key features needed for industrial development, like destructors or overall memory safety. But for some reason it's overhyped.

If you think destructors/`Drop` traits or the like are good then Zig was never for you. It has nothing to do with "industrial development", neither does memory safety. The irony is that memory safety as a concept definitely is overhyped.

Re: Why is Zig so cool?

#262

Earlier quoted context omitted.

[flagged]

I use Lua in 2025, it’s brilliant. By the way, so does everyone using neovim.

> By the way, so does everyone using neovim.

See also Roblox (and there used to be a whole bunch of game engines that had Lua scripting but I -think- most of them have switched to "NIH!" scripting engines?)

Re: Why is Zig so cool?

#263
While some of the features the author references are really interesting, personally I don't see how any of that would justify creating a new memory unsafe language in 2016. I thought it was pretty obvious by now [1][2][3] memory safety is best left to tooling / compilers and not to programmers.

[1] https://research.google/pubs/secure-by-design-googles-perspe...

[2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...

[3] https://www.cisa.gov/case-memory-safe-roadmaps

Re: Why is Zig so cool?

#265

While some of the features the author references are really interesting, personally I don't see how any of that would justify creating a new memory unsafe language in 2016. I thought it was pretty obvious by now [1][2][3] memory safety is best left to tooling / compilers and not to programmers. [1] https://research.google/pubs/secure-by-design-googles-perspe... [2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we…

This sound a bit like Tanenbaum's rejection of Torvals' project, because monolithic kernels are obsolete.

Re: Why is Zig so cool?

#266

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…

Anonymous structs and type interference are things even C has, although support for the later one is quite recent and limited.

Re: Why is Zig so cool?

#267

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…

> Zig is not only a new programming language, but it’s a totally new way to write programs I'd say the same thing about Rust. I find it the best way to express when what code should run at any given point in the program and the design is freakin interstellar: It is basically a "query engine" where you write a query of some code against the entire available "code space" including root crate and its dependencies. Once…

As someone not really familiar with Rust, this sounds intriguing, but I don’t full understand. Do you have any links that can or examples that could clarify this for someone who is just starting out with Rust?

Re: Why is Zig so cool?

#268
post #25

For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?

Given that Zig has functions which can return functions, maybe you could capture the top level io and allocator and return a struct with a bunch of functions that now have the top scope io and allocator visible.

Don’t know. That’s how people usually get rid of repeat arguments (or OOP constructor).

Re: Why is Zig so cool?

#269

While some of the features the author references are really interesting, personally I don't see how any of that would justify creating a new memory unsafe language in 2016. I thought it was pretty obvious by now [1][2][3] memory safety is best left to tooling / compilers and not to programmers. [1] https://research.google/pubs/secure-by-design-googles-perspe... [2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we…

This sound a bit like Tanenbaum's rejection of Torvals' project, because monolithic kernels are obsolete.

Tanenbaum was right, the future of the Linux kernel is dire, and it's been a huge setback to operating systems research in practical terms.

Fortunately, vendors are gradually moving away from Linux, having been hamstrung by its failures. Google is planning to move to a capability-based microkernel in the coming years for Android and ChromeOS, and Huawei has already done so with HarmonyOS.

In a hundred years, Linux will be a footnote in computing history.

Re: Why is Zig so cool?

#270
post #232
post #211

Earlier quoted context omitted.

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

Nope, that is a English grammar construct that is a shortcut for "and" and "or", as any good English grammar book will explain. Indeed you see those for Java/Scala and Objective-C/Swift in technical books and job adverts. Any search on the careers sites, or documentation, on companies that have seats at ISO, sell/develop C and C++ compilers, have such C/C++ references in a couple of places. Do you need any example?

In the general case yes, but "C/C++" became an idiom for the stance, that C and C++ are essentially the same, that C++ is a superset of C or that C++ is just the replacing successor of C and it should be treated as superseded. This is quite wrong and thus there is a lot of rightful intervention to that term. Personally I use "C, C++" when I want to talk about both without claiming, that they are the same language.
Post reply on HN