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

171–180 of 183 posts

Re: Zig and the design choices within

#171

Post by lerno »

bsder wrote: post #162
lerno wrote: post #139

Earlier quoted context omitted.

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.

I answered above.

Re: Zig and the design choices within

#172

Post by torginus »

pron wrote: post #168
torginus wrote: post #167

Earlier quoted context omitted.

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…

I feel like one thing that wasn't made clear - it's not necessarily the job of the programming language to prevent certain issues - SQL injection for example is something that should be handled by the framework (by not allowing to write SQL directly, but using commands with parameters). All the other higher priority issues are like that, it's not within the scope of a language to prevent such issues, just as Rust or Zig or whatever will never prevent phishing attacks.

As for temporal vs spatial memory safety issues, I agree that Zig does maybe help in that a bit (if component A sends an event to B, then A,B and the events having a separate allocator would work) - though I'm not sure if it doesn't introduce its own footguns (how do I know which allocator needs to free which object).

I don't know I haven't used Zig at all, so no idea how all this works out in practice. Memory issues are 100% solved by languages like Java with GC and I wouldn't say they have made software that much less buggy.

Re: Zig and the design choices within

#173

Post by pron »

torginus wrote: post #172
pron wrote: post #168

Earlier quoted context omitted.

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

I feel like one thing that wasn't made clear - it's not necessarily the job of the programming language to prevent certain issues - SQL injection for example is something that should be handled by the framework (by not allowing to write SQL directly, but using commands with parameters). All the other higher priority issues are like that, it's not within the scope of a language to prevent such issues, just as Rust or…

> it's not within the scope of a language to prevent such issues

As someone working on adding such a feature to Java, I beg to differ. Python has also recently added a language feature to address injection attacks (https://peps.python.org/pep-0750/).

> Memory issues are 100% solved by languages like Java with GC and I wouldn't say they have made software that much less buggy.

Well, again, the question isn't how many bugs you have, but what the impact of these bugs is. Violations of spatial memory safety are both common and relatively easy to exploit into very dangerous attacks, which is why it's important that Rust and Zig prevent them. But everything is a question of cost and benefit, as in, how much extra effort, or RAM, or CPU it's worth it to avoid certain bugs. The answer depends on the nature of the bug, the nature of the project, and the preferences of developers. Zig and Rust compromise on both correctness and effort, but their compromises are somewhat different. We just don't know if one of these approaches is more likely to be a better sweet spot in more situations (where these languages are used), and if so which.

Re: Zig and the design choices within

#174

Post by baranul »

lerno wrote: post #114
rvrb wrote: post #98

Earlier quoted context omitted.

Zig is famously simple to pick up and write with, so I don't know what you mean by "difficult". Software is dangerous. Memory safety is one of a million ways it can be dangerous. A compiler barfing when it thinks you are doing something unsafe with pointers is one approach to dealing with one of the ways that code can be dangerous to execute. Zig does not ignore that particular danger, it just takes a different appro…

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?

Marketing speak, that looks to be trying to put Zig over languages like Golang, Vlang, etc... which are well known for their simplicity and readability. The false hype arguably creates confusion, that Zig can be "all things to all people", when it's not.

Re: Zig and the design choices within

#175

Post by bsder »

lerno wrote: post #169
bsder wrote: post #163

Earlier quoted context omitted.

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.

Thanks for the data point.

Re: Zig and the design choices within

#176

Post by kennykartman »

pron wrote: post #78
ModernMech wrote: post #62

Earlier quoted context omitted.

> a relatively advanced age. Maybe you and I have different working definitions of "relative", but Rust hit 1.0 only 10 years ago, whereas the age of the most popular languages is 30+ years. In that sense Rust is relatively young . Indeed, Rust is the youngest language in the TIOBE top 20, and it's more popular than other languages which have been around much longer. The only language which comes close is Swift, and…

It's actually hard to find any language that has ever very popular (JS, TS, Python, Java, C++, C#, C, and you can even throw in PHP, Ruby, Go, Kotlin, and even COBOL and Fortran) that has such a low adoption rate at age 10. I'm not saying that means Rust won't buck the historical trend and achieve that, but its adoption clearly does not resemble that of any language that's ever become very popular.

TIL Zig is almost 10 yo. It will turn 10 next February. I really thought it was a younger language.

Re: Zig and the design choices within

#177

Post by pron »

at_compile_time wrote: post #118
pron wrote: post #97

Earlier quoted context omitted.

Rust is much older than Zig, though, and there's nothing stopping Zig (or any future language that doesn't adopt Rust's precise set of guarantees) from having the same, or possibly better. Given Zig's immaturity, I certainly wouldn't use it for any serious production software today. BTW, I'm not saying Rust is bad. All I'm saying is that the attempt at proving it's objectively best by leaning on memory-safety is not…

I hadn't heard of ATS before, and I think that I mistook your using it as an example of "more isn't always better" and thought you were suggesting it as an actual alternative. I'm looking for the next thing I want to learn, and have been leaning towards logic programming and theorem provers, so you inadvertently piqued my interest.

Sure, just keep in mind that various formal verification tools vary greatly in their usability, even theorem provers. I.e. the experience with ATS will be quite different from Lean, which will be quite different from TLA+.

Re: Zig and the design choices within

#178

Post by pron »

kennykartman wrote: post #176
pron wrote: post #78

Earlier quoted context omitted.

It's actually hard to find any language that has ever very popular (JS, TS, Python, Java, C++, C#, C, and you can even throw in PHP, Ruby, Go, Kotlin, and even COBOL and Fortran) that has such a low adoption rate at age 10. I'm not saying that means Rust won't buck the historical trend and achieve that, but its adoption clearly does not resemble that of any language that's ever become very popular.

TIL Zig is almost 10 yo. It will turn 10 next February. I really thought it was a younger language.

Zig began development ten years after Rust. If we were counting from the beginning of the development rather than 1.0 (as I did above), then Rust is about to turn 20.

Re: Zig and the design choices within

#179

Post by pron »

Tadpole9181 wrote: post #153
pron wrote: post #78

Earlier quoted context omitted.

It's actually hard to find any language that has ever very popular (JS, TS, Python, Java, C++, C#, C, and you can even throw in PHP, Ruby, Go, Kotlin, and even COBOL and Fortran) that has such a low adoption rate at age 10. I'm not saying that means Rust won't buck the historical trend and achieve that, but its adoption clearly does not resemble that of any language that's ever become very popular.

Typescript is a tool more than a language, so that's not fair at all. And the rest of those basically had no competition in their domain when they started 30+ years ago. Rust now has to grow next to 30 years of those languages maturing, and convince people to abandon all existing community resources - whereas those languages did not. Having a low adoption rate is normal in this day and age. Go is kind of an anomaly c…

> And the rest of those basically had no competition in their domain when they started 30+ years ago.

That's not true, as anyone who was programming back then (like me) knows. Java had serious competition from VB, Delphi, and a host of other "RAD" languages as they were called back then (and not long before, the language that the magazines were touting as "the future" was Smalltalk). All of them were heavily marketed. C++, of course, had to compete against an established incumbent, C, and another strong contender, Ada (Ada, BTW, was about as popular in 1990, when it was 10 years old, as Rust is today, although bigger, more important software projects were being written in Ada in 1990 than are being written in Rust today). Python and Ruby both were both competing with the very powerful incumbent, Perl. PHP, of course, had Java to compete with, as did C#. Some of these languages had strong backers, but some started out as very small operations (Python, C++, PHP), and some languages with very strong backers did poorly (Delphi, FoxPro).

Again, I have no idea if Rust will ever really take off, but its adoption at this advanced age, despite no lack of marketing, would be extraordinarily low for a language that becomes very popular.

> But it doesn't help that Rust is also in the native space, whose devs are especially stubborn

Perhaps, but Fortran, C, and C++, were all in this space and they all spread rather quickly. Microsoft, a company with a fondness for complicated languages, chose to write significant portions of their flagship OS in C++ when the language was only five years old.

It's true that the market share of low-level languages has been shrinking for several decades now and continues to shrink, but also isn't really a good news for a language that for at least a decade has been trying to get a significant share of that shrinking market, and has been having a hard time at that.

> and is a difficult language with painful syntax.

Yes, but this, too, isn't a point in favour of betting on Rust's future success. Other difficult or complex languages indeed had a harder time getting much adoption in their first decade, but things also didn't pick up for them in their second decade.

The latest bloomer of the bunch is Python, but if Rust ever becomes very popular (even as popular as C++ is today), it would need to break Python's record. That's not impossible, but it would be highly unusual. Low adoption in the first decade has virtually always been a predictor of low adoption down the line, too.

Re: Zig and the design choices within

#180

Post by pron »

asa400 wrote: post #124
pron wrote: post #53

Earlier quoted context omitted.

>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. The funny thing about that claim is that it leads to an obvious question: if working harder to satisfy the compiler is something that requ…

> ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. What are we measuring? Lines of code? Number of programmers employed? Number of new applications started? Rust is in: Linux, Windows, Azure, all over AWS, Amazon's Prime video, Cloudflare's proxy, Firefox, Python's `cryptography` package, Zed editor. This is just th…

> What are we measuring? Lines of code? Number of programmers employed? Number of new applications started?

They're correlated, but number of programmers employed is something that's relatively easy to measure.

> Is this low adoption?

For a language this old? Yes. That people talk so much about specific projects that use Rust only underlines that: Rust is now as old as Java was when JDK 6 came out; older than PHP was when PHP 5 came out or Facebook was launched; older than C++ was when Windows NT came out.

Post reply on HN