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

91–100 of 183 posts

Re: Zig and the design choices within

#91

Post by mwcampbell »

api wrote: post #71
pizza234 wrote: post #41

Earlier quoted context omitted.

> Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's hype cycle It is correct that the hype is past its peak, however, the TIOBE trend (if one wants to use that) is actually steadily increasing. > There is still some development in linux "Some development" is a miscarachterization - the official addition to the Linux kernel itself is a…

Rust has been adopted by Microsoft, Amazon, etc. It's past the hype phase and well into the "languages people use for work and complain about" phase. I still like it -- for systems programming, that is. It's a much better C++ basically.

> I still like it -- for systems programming, that is.

Just curious, what language(s) do you prefer for things that you don't classify as "systems programming"?

Re: Zig and the design choices within

#92

Post by at_compile_time »

pron wrote: post #53
ivanjermakov wrote: post #15

> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot. > I am personally a proponent of a good macro system. Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawba…

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

Rust's real superpower is its tooling. Cargo handles package management, building, testing, documentation, and publishing. The compiler's errors explain what went wrong and where it happened. Installing the toolchain with rustup is quick and painless, even on Windows. I can't know that it's best in class, but it's certainly the best I've used.

I can see another language having a more expressive type system, I've come up against the limitations of Rust's type system more than once, but the tradeoff isn't worth it if I have to go 20 years back in time in terms of tooling.

Re: Zig and the design choices within

#93

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.

I'm curious, do you have figures for this? I was not around when C or C++ were 10, but I was when python was and as a long time python user I would say that the pycommunity was much smaller at 10 then the rust community at 10. So my gut feeling is that your statement is false at least wrt python, but I'm happy to change my mind if you have sound data.

Edit: just to add some more anecdotal evidence from my memory of languages I used: java community was pretty bigger than rust at 10. Go's was much smaller than rust at 10. I'd be happy to check my beliefs against actual data :)

Re: Zig and the design choices within

#94

Post by pron »

zozbot234 wrote: post #89
pron wrote: post #86

Earlier quoted context omitted.

> I think where we disagree is that you believe Zig is as safe as Rust Quite the opposite. Rust is definitely safer in the simple sense that it guarantees more memory safety. But that's very different from saying that Zig is closer to C than to Rust (Zig's memory safety is much closer to Rust's than to C's), and it also doesn't mean that it's easier to write more correct/secure software in Rust (because there are jus…

> Zig's memory safety is much closer to Rust's than to C's This is arguable. Zig's issues with memory safety are not limited to such things as use-after-free ("temporal" memory safety in a rather obvious sense). Without something very much like Rust's borrow checker and affine types, you can't feasibly prevent a program from inadvertently e.g. stashing a pointer somewhwere to an inner feld of a tagged union, and reus…

> This is arguable

That's not arguable. Because if we say that memory safety is important because it prevents some common and dangerous vulnerabilities, then Zig clearly prevents the most dangerous of those, while C doesn't.

> you can't prevent a program from inadvertently...

Now you're naming more problems that aren't as high on the list as the ones Zig does prevent (and C doesn't). It's true that type confusion is also rather high on the list, but Zig clearly reduces type confusion much more than C does.

Nobody denies that Rust prevents more issues than Zig via sound guarantees - albeit at what I think is a significant cost, and we can argue, subjectively, over whether those issues are worth that cost or not - but Zig's guarantees are still closer to Rust's than to C's if eliminating very common/dangerous vulnerabilities is what we're judging by.

Re: Zig and the design choices within

#95

Post by zozbot234 »

pron wrote: post #94
zozbot234 wrote: post #89

Earlier quoted context omitted.

> Zig's memory safety is much closer to Rust's than to C's This is arguable. Zig's issues with memory safety are not limited to such things as use-after-free ("temporal" memory safety in a rather obvious sense). Without something very much like Rust's borrow checker and affine types, you can't feasibly prevent a program from inadvertently e.g. stashing a pointer somewhwere to an inner feld of a tagged union, and reus…

> This is arguable That's not arguable. Because if we say that memory safety is important because it prevents some common and dangerous vulnerabilities, then Zig clearly prevents the most dangerous of those, while C doesn't. > you can't prevent a program from inadvertently... Now you're naming more problems that aren't as high on the list as the ones Zig does prevent (and C doesn't). It's true that type confusion is…

The underlying issue is that Zig turns out to have no feasible safe subset, just like C - unless you go as far as to declare things like using tagged unions in combination with pointers "unsafe" which is both insanely restrictive and hard to check programmatically. People might complain about having to fight the borrow checker, but they'd complain a whole lot more if the standard approach to safety-subsetting a language was just bounds-checked array access plus "you can write FORTRAN in any language!"

Re: Zig and the design choices within

#96

Post by pron »

zozbot234 wrote: post #95
pron wrote: post #94

Earlier quoted context omitted.

> This is arguable That's not arguable. Because if we say that memory safety is important because it prevents some common and dangerous vulnerabilities, then Zig clearly prevents the most dangerous of those, while C doesn't. > you can't prevent a program from inadvertently... Now you're naming more problems that aren't as high on the list as the ones Zig does prevent (and C doesn't). It's true that type confusion is…

The underlying issue is that Zig turns out to have no feasible safe subset, just like C - unless you go as far as to declare things like using tagged unions in combination with pointers "unsafe" which is both insanely restrictive and hard to check programmatically. People might complain about having to fight the borrow checker, but they'd complain a whole lot more if the standard approach to safety-subsetting a langu…

> The underlying issue is that Zig turns out to have no feasible safe subset

It does have a safe subset with respect to spatial memory safety, which is the more important kind of memory safety if what we judge by is dangerous vulnerabilities.

> People might complain about having to fight the borrow checker, but they would complain a lot more if the standard approach to safety-subsetting a language was just bounds-checked array access plus "you can write FORTRAN in any language!"

I don't know how you can say that this is an objectively-supported claim given Rust's poor adoption at its age.

Re: Zig and the design choices within

#97

Post by pron »

at_compile_time wrote: post #92
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…

Rust's real superpower is its tooling. Cargo handles package management, building, testing, documentation, and publishing. The compiler's errors explain what went wrong and where it happened. Installing the toolchain with rustup is quick and painless, even on Windows. I can't know that it's best in class, but it's certainly the best I've used. I can see another language having a more expressive type system, I've come…

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 really as objective as the people who make that claim seem to think it is.

Re: Zig and the design choices within

#98

Post by rvrb »

James_K wrote: post #49
rvrb wrote: post #29

Earlier quoted context omitted.

Zig is a tool that helps professionals prevent those mistakes. "Memory safe languages" are tools that prevent professionals from making those mistakes. It's a subtle but important difference. Zig attempts to leave some humanity to the developer. When someone says they are incapable of earning or deserving that, I feel sad.

Creating a language which is difficult to use and dangerous is not “lending humanity to the developer”. Humans make mistakes, and a language that doesn't account for this is ignoring the humanity of its users.

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 approach to dealing with it than some other modern languages. An approach that, I believe, leaves the developer with a little more humanity by allowing them the benefit of the doubt that they know what they are doing.

Everyone that has not built a systems language, or has not built a real application with both Zig and a memory safe language, that is reacting emotionally to what I've said should put a lot of consideration into whether they are cargo culting or using critical thought. Consider that we still do not yet know what is best, and shutting down attempts to explore different ideas with things like "creating [and using] this language is ignoring the humanity of the end user" is, well.. dumb.

Re: Zig and the design choices within

#99

Post by kennykartman »

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

I had the same thought. But one thing was actually very useful to compare "bug densities": deno vs bun. They have comparable codebase sizes as well as comparable ages (7y vs 4y). I'd like to see the same stats for tigerbeetle, which is very carefully designed: if segfaults were relatively high on that as too, well...

Re: Zig and the design choices within

#100

Post by pron »

kennykartman wrote: post #93
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.

I'm curious, do you have figures for this? I was not around when C or C++ were 10, but I was when python was and as a long time python user I would say that the pycommunity was much smaller at 10 then the rust community at 10. So my gut feeling is that your statement is false at least wrt python, but I'm happy to change my mind if you have sound data. Edit: just to add some more anecdotal evidence from my memory of l…

I wasn't programming yet when C was 10 years old, but I was when C++ was 10 years old (1995), and its adoption was an order of magnitude higher than Rust's is today.

I agree that of all popular languages, Python is the latest bloomer, but while it became popular for applications and data processing rather late, it was used a lot for scripting well before then.

> Go's was much smaller than rust at 10

Go turned 10 (if we want to count from 1.0) only 3 years ago, and Go's adoption in 2022 was much bigger than Rust's today.

Post reply on HN