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

Zig and the design choices within

blueberrywren.dev

Post reply on HN
Print view View original

161–170 of 183 posts

Re: Zig and the design choices within

#161

Post by pron »

ModernMech wrote: post #156
pron wrote: post #154

Earlier quoted context omitted.

> These two languages were created and pushed by two of the largest corporations on the planet. I don't think Rust lacks in hype and marketing. It doesn't buy ads in print magazines, but no language does anymore (that's exactly how VB, Delphi, FoxPro, Visual C++, and Java were marketed). And don't forget that while being well-known is necessary for success, it's far from sufficient. There's also the matter that large…

I have received 3 transmissions from you so far, and you have yet to define "success" or "popularity", nor have you specified the threshold between "popular" and "very popular", despite having agreed with me that these things are not important for languages. Moreover, you haven't brought any figures to bear in supporting your claims. I think if we are going to continue this discussion, you have to substantiate your p…

A specific definition of "popular" doesn't matter. What we can say is that Rust's market share at age 10 is lower than that of Fortran, COBOL, C, C++, VB, Python, JS, Java, C#, PHP, Ruby, TS, Kotlin, and Go at that age, but it's bigger than that of ML, Haskell, Erlang, and Clojure at that age. I don't know if I can compare its market share to that of Ada at that age. I'm nearly certain that much larger (and definitely more important) programs were written in Ada circa 1990 than are being written in Rust today, but it's hard for me to compare the number of programs.

Re: Zig and the design choices within

#162

Post by bsder »

lerno wrote: post #139
ModernMech wrote: post #128

Earlier quoted context omitted.

> Jai isn't open source so it is completely and totally irrelevant. Worse, there's not even a compiler available. I don't even think there's even a spec.

This is just a convenient excuse. If Zig is to be fast to compile, it doesn’t help to make excuses for it. Saying something it ”fast enough” because one is comparing with even slower languages is likely what made both Rust and Swift so slow to compile - they all just compared with C++, and it wasn’t until much later - when larger projects appeared - that the problem was taken more seriously. But at that time core arc…

> This is just a convenient excuse.

Jai not relevant until open sourced. Period. End of discussion. Do not mention again.

C3 and Odin numbers and discussion certainly welcome.

Re: Zig and the design choices within

#163

Post by bsder »

lerno wrote: post #138
bsder wrote: post #121

Earlier quoted context omitted.

Jai isn't open source so it is completely and totally irrelevant. Zig builds C faster than most C compilers. You're going to have to do better than just mention it. However, if those are the only things that are even possibly faster than Zig, then the Zig compiler qualifies as fast, not slow--which was my original point.

”Zig builds C faster than most C compilers” is a nonsense statement, which I don’t know how to answer. The fact is simply that despite Zig uses LLVM as a backend in the same way Odin and C3 does, it compiles much slower. Exactly why that is, is something I can only guess at, but the fact is that Zig cached is still much slower to compile than Odin or C3. (There are a few possible candidates as to why this is so that…

It sure would be nice to have some concrete numbers from those projects to compare to for example ...

Note the discussion about "Incremental Build (libghostty-vt)" https://mitchellh.com/writing/zig-builds-getting-faster

https://biggo.com/news/202506090712_Zig_x86_Backend_Performa...

Re: Zig and the design choices within

#164

Post by igouy »

pron wrote: post #154
ModernMech wrote: post #145

Earlier quoted context omitted.

> I agree it doesn't need to be very popular to survive. But... I think that's the end of it then, yeah? We've established it's popular enough (you set a lower bound at Haskell, which has been around for 35 years, has an active and vibrant community, and is still used in industry), we agree it doesn't need to be more popular, so then this threshold of "very popular" you invented (which I guess is the top 10) is arbit…

> These two languages were created and pushed by two of the largest corporations on the planet. I don't think Rust lacks in hype and marketing. It doesn't buy ads in print magazines, but no language does anymore (that's exactly how VB, Delphi, FoxPro, Visual C++, and Java were marketed). And don't forget that while being well-known is necessary for success, it's far from sufficient. There's also the matter that large…

Let's remember: Dancin' Duke Java Applets distributed with Netscape's web browser. "Sun is giving away Java and HotJava free, in a fast-track attempt to make it a standard before Micro-soft begins shipping a similar product"

https://archive.gyford.com/1997/wired-uk/1.08/features/java....

Re: Zig and the design choices within

#166

Post by Defletter »

bsder wrote: post #108
anp wrote: post #6

I find a lot of these points persuasive (and I’m a big Rust fan so I haven’t spent much time with Zig myself because of the memory safety point), but I’m a little skeptical about the bug report analysis. I could buy the argument that Zig is more likely to lead to crashy code, but the numbers presented don’t account for the possibility that the relative proportions of bug “flavors” might shift as a project matures. I’…

> Don’t get me wrong, as a Rust zealot I have my biases and still expect a memory safe implementation to be less crashy That is a bias. You want all your "memory safety" to be guaranteed at compile time . Zig is willing to move some of that "memory safety" to run time . Those choices involve tradeoffs. Runtime checks make Zig programs more "crashy", but the language is much smaller, the compiler is vastly faster, "de…

> My personal take is that if I need more abstraction than Zig, I need something with managed memory--not Rust or C++

You may potentially like D. Its tooling leaves much to be desired but the language itself is pretty interesting.

Re: Zig and the design choices within

#167

Post by torginus »

pron wrote: post #157
torginus wrote: post #151

Earlier quoted context omitted.

You're responding to the emotional appeal part of my post, not the argument itself - I'm sorry for including it, as it had sidetracked the useful conversation. Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr. It's essentially C's malloc/free with the added safety of defer (or possibly arenas), but making sure that the program doesn't leak memory (or have use-after-free bugs) falls on…

> Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr. Zig's memory-safety is spatial , which is the more dangerous kind. Your examples are all temporal, and I don't know if I would call them "safety" as the language doesn't enforce or even encourage their use. For example, I work on one of the world's most foundational C++ projects (the HotSpot virtual machine), where neither shared_ptr…

I don't understand the distinction between spatial and temporal memory safety - from what I gather, spatial memory safety is just preventing out of bounds access of arrays, dereferencing uninitialized or otherwise invalid pointers. But use after free absolutely results in the same kinds of errors (accessing unused memory, or memory used by someone else).

I also don't understand how one can sidestep the issue of ownership of memory - let's say you have a situation where a given piece of memory has changing or ambiguous ownership - like an event sent between two components, that has allocated some dynamic memory.

I'm not saying this just because, I've encountered this exact issue before - many C libraries have event systems where the ownership is not obvious coming from the code - like the sender owns the event, and if you store a reference to it, then you have a dangling pointer if the sender decides to clean it up.

That's why it's important to make it either obvious who owns what, or have some automatic system like GC or unique_ptr or the borrow checker.

This is a very real issue and the only way you can fix it is to follow strong informal conventions the language has no way of enforcing or even communicating to the user.

You mention Zig has a temporal memory management solution of a different kind - may I ask you what it is, because I haven't really seen it.

Re: Zig and the design choices within

#168

Post by pron »

torginus wrote: post #167
pron wrote: post #157

Earlier quoted context omitted.

> Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr. Zig's memory-safety is spatial , which is the more dangerous kind. Your examples are all temporal, and I don't know if I would call them "safety" as the language doesn't enforce or even encourage their use. For example, I work on one of the world's most foundational C++ projects (the HotSpot virtual machine), where neither shared_ptr…

I don't understand the distinction between spatial and temporal memory safety - from what I gather, spatial memory safety is just preventing out of bounds access of arrays, dereferencing uninitialized or otherwise invalid pointers. But use after free absolutely results in the same kinds of errors (accessing unused memory, or memory used by someone else). I also don't understand how one can sidestep the issue of owner…

> But use after free absolutely results in the same kinds of errors (accessing unused memory, or memory used by someone else).

That two bugs result in the same or similar outcome doesn't mean they're as common or as equally exploitable, which is why, in practice, it is distinctly a more dangerous weakness in the lists maintained by MITRE.

> I also don't understand how one can sidestep the issue of ownership of memory

It's not about side-stepping. There are many kinds of bugs in software, and while we'd like to avoid all of them, some problems are, in practice, more problematic. After all, Rust similarly "sidesteps" - as in doesn't prevent - all non-memory-safety-related weaknesses, some of which are more dangerous than dynamic memory safety. If Zig isn't good enough because it doesn't prevent temporal memory safety violations, then by the exact same logic, Rust isn't good enough because it doesn't prevent, say, injection vulnerabilities, that are more dangerous than temporal memory safety vulnerabilities.

> I'm not saying this just because, I've encountered this exact issue before

Sure, it's a real and serious issue. But injection is a more serious issue, which Rust doesn't prevent, and spatial memory violations are also a more serious issue, which Zig prevents just as Rust does.

> That's why it's important to make it either obvious who owns what, or have some automatic system like GC or unique_ptr or the borrow checker.

It is, but it's even more important to prevent code injection attacks, yet Rust doesn't do that. It all comes down to how much it's worth it to pay to prevent certain bugs.

Rust was built because its designers believed that memory safety wasn't worth paying the higher memory footprint or the lower predictability of more popular memory-safe languages, or else there would have been no need for Rust in the first place. Similarly, it's just as reasonable to believe that the price you pay for temporal memory safety in Rust is not worth it.

> You mention Zig has a temporal memory management solution of a different kind - may I ask you what it is, because I haven't really seen it.

It's not a safe solution by any means (as the language doesn't enforce temporal memory safety, just as C++ doesn't), but memory allocation and deallocation in Zig is not the same as in C or C++. In particular, Zig functions that allocate are explicitly marked by having an Allocator parameter (https://zig.guide/standard-library/allocators/). Unlike in C, in Zig you know which functions allocate and using which allocator. That's how Zig is such a great fit for arenas.

Because Zig is built around custom allocators, you can also choose allocators that offer use-after-free, double-free, and memory-leak protection, and do so selectively (unlike in C): https://sinclairtarget.com/blog/2025/09/getting-my-allocator...

Re: Zig and the design choices within

#169

Post by lerno »

bsder wrote: post #163
lerno wrote: post #138

Earlier quoted context omitted.

”Zig builds C faster than most C compilers” is a nonsense statement, which I don’t know how to answer. The fact is simply that despite Zig uses LLVM as a backend in the same way Odin and C3 does, it compiles much slower. Exactly why that is, is something I can only guess at, but the fact is that Zig cached is still much slower to compile than Odin or C3. (There are a few possible candidates as to why this is so that…

It sure would be nice to have some concrete numbers from those projects to compare to for example ... Note the discussion about "Incremental Build (libghostty-vt)" https://mitchellh.com/writing/zig-builds-getting-faster https://biggo.com/news/202506090712_Zig_x86_Backend_Performa...

Embergen is 400kloc Odin, it compiles in about 2s. No incremental compilation or caching to speed it up.

And this is with LLVM as backend.

Re: Zig and the design choices within

#170

Post by lerno »

rvrb wrote: post #160
lerno wrote: post #114

Earlier quoted context omitted.

I have never heard anyone calling Zig "famously simple" before. In fact, people tend to say it has quite the learning curve. Of course, caveats apply: it is certainly simple compared to some languages, but certainly not compared to others. "Famously simple" seems to indicate it is one of the simplest languages to learn, which seems wrong unless there are some serious qualifications to that statement?

C, C++, Rust, Zig. Rust and C++ have an infamous learning curve. If you know anything about using any systems language other than Zig, Zig is incredibly simple to pick up, like C. Unlike C, it pushes you toward making less mistakes. If you don't know anything about using a systems language, Zig makes it easier for the people who do to review your code and make sure you didn't mess it up. It does this with very intent…

If you are comparing Zig to Rust and C++, which are very well known to be difficult to learn, then that is not really saying anything about the ease of learning it. Compare it to Swift, D or Odin. Is it "incredibly simple" compared to those languages as well?

Similarly, one can claim that pretty much anything compiles "incredibly fast" if one compares with Rust, C++ and Swift.

But comparing to worst in class doesn't actually say anything.

One note about this:

> If you have not written a real application in Zig and evaluated it for vulnerabilities, but are claiming that creating Zig was irresponsible, and using it is too; you are cargo culting.

I don't know what this has to do with my comments at all, but I want to point out that you are using "cargo culting" wrong. This describes imitating practices of something successful, thinking that by this imitation, success will follow as well.

> No one reasonable has claimed that memory safe languages should not exist,

Again, I have not talked anything about whether memory safe languages should or should not exist. You are confusing me with someone else.

Post reply on HN