Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/
I don't agree at all about "not much safer" and Zig differs from C in so many ways -- including but not limited to safety -- but regardless, memory safety comes at a price, language safety is not an end (that would be program correctness) but just one of many means to that end, there is no consensus at all over what is the most effective way to reach that end, and there are other things people care about as well. So…
Zig, the Small Language
351–360 of 429 posts
Re: Zig, the Small Language
#352Re: Zig, the Small Language
#353Earlier quoted context omitted.
"In the beginning the [operator overloading] was created. This has made a lot of people very angry and been widely regarded as a bad move." But in all seriousness that's pretty much antithetical to zig's goals regarding explicitness.
D initially wasn't going to do operator overloading, mainly because C++ iostreams was a disaster (in my not-so-humble opinion) as well as the awfulness of overloading operators to create a DSL. But I wound up being convinced that on balance it was a good thing. But I was able to inculcate a culture that operator overloading should be restricted to the creation of user arithmetic types. Not allowing the overloading of…
Re: Zig, the Small Language
#354Earlier quoted context omitted.
I don't agree at all about "not much safer" and Zig differs from C in so many ways -- including but not limited to safety -- but regardless, memory safety comes at a price, language safety is not an end (that would be program correctness) but just one of many means to that end, there is no consensus at all over what is the most effective way to reach that end, and there are other things people care about as well. So…
Quoted post unavailable.
Re: Zig, the Small Language
#355Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/
> systems programming language that is not safe? It sounds like you're saying rust because I don't know what other languages claim both. Rust is an awful language. That's why. If you're using a systems programming language then chances are unsafeness isn't the problem you're most concerned with
Re: Zig, the Small Language
#356Earlier quoted context omitted.
Out of the 10 top ones in that list about Rust (there's one about C code in GCC), 1. 6 are because of unsafe code. 2. 3 are because of ouf-of-memory (OOM) errors. 3. 1 is due to unsafe code in `tokio`, but I think it's fair to consider unsoundness in tokio's safe abstractions (over unsafe code) as unsoundness in "safe Rust" because the crate is so foundational, even if its third party. Regardless, I don't think any o…
The original claim was: > The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures I'm not the OP but I think the point here is that the borrow checker is only applicable for the "easy" code (which does make up an awful lot of code), but even "basic data structures" very often require abandoning the borrow checker. In such a case, it's perf…
There are many such libraries in Rust.
Re: Zig, the Small Language
#357Earlier quoted context omitted.
> They prefer slices idiomatically, but that's not "full spatial memory safety" [*] is a syntactically delineated unsafe feature. Rust has the same thing. It's like saying Rust prefers safety, but doesn't enforce it because it has unsafe features; same goes for Haskell. > I don't see much room for a new language that isn't memory-safe in 2022. That statement [1] is about about as silly as "I don't see much room for a…
> Rust has the same thing. In Rust all of those features are delineated by unsafe. For one, you can disable unsafe with a compiler switch; Zig has no such equivalent feature. Moreover, we shouldn't assume that Zig pointers are the only feature that breaks spatial memory safety. It was simply the first one I found after like 2 minutes of looking through the docs. After like 5 more minutes I found another: extern union…
They're also delineated in Zig, just not with a single keyword. Extern unions, unknown-length arrays, and sentinel-terminated arrays are features, with clear syntax, used for C interop only.
> It's obvious that full spatial memory safety just isn't a design goal of Zig.
It's as much of a goal in Zig as it is in Rust; both allow circumventing it with clearly marked unsafe features.
> Which is the same goal that, for example, the C++ STL has. It's a great goal, but it shouldn't be confused with Rust's goal.
You're confusing means and end. No one's ultimate goal is having this feature or another. Both Zig and Rust have, as one primary goal, helping write correct software. They just try to achieve it in different ways. Why is that good? Because we have no idea what is the most effective way of achieving that goal, so we try different approaches.
> It's my opinion in the same sense that it's my opinion that wearing seatbelts results in fewer deaths on the road.
I don't think so, because seatbelts have few accident-related downsides, while a complex language has many.
> Anyone arguing otherwise has a massive burden of proof.
I'm not arguing against seatbelts. Anyone who claims that X leads to more correct programs than Y -- not by looking at this or that property, but as a whole -- has a massive burden of proof. I am not claiming Zig is more effective at writing correct programs than Rust. After years exploring issues in software correctness -- including with different formal methods -- my claim, which is closer to consensus than controversy, is that we simply don't know. We don't know which of Zig's or Rust's approaches leads to more software, and therefore we cannot say which of those approaches is preferable, even if correctness is the main thing we care about.
> And the arguments I've seen by people arguing that you don't need temporal memory safety are weak. The idea that a simple language that doesn't have ironclad safety guarantees reduces errors over a more complex language with those guarantees sounds nice in theory, but it hasn't actually turned out that way in practice.
We simply don't know either way. We might know that a language with ironclad guarantees leads to more correct software than C, but given that Zig is as different from C as Rust is -- and as different as they are to each other -- there's nothing that allows us to extrapolate.
Your argument amounts to, "my way is the best way", and your evidence is irrelevant extrapolations. One could then ask, if Rust's design is so great, how come, at its not-so-young age -- which is quickly nearing the age at which all languages (with the possible exception of Python) have reached or approached their all-time peak popularity -- so few people use it? Could it be that there's no "room" for it? (I'm not saying that's the case at all -- I think Rust, like Zig, is a very interesting language.) Its low popularity certainly makes claims along the lines of, "the design of this language is obviously the only design for which there's room in 2022," ring quite hollow. There's no room for anything other than an approach whose success is so uncertain? Really? Given that Rust has proven quite the opposite of an overnight success, I think some humility about its design choices is appropriate.
Re: Zig, the Small Language
#358Earlier quoted context omitted.
I don't agree at all about "not much safer" and Zig differs from C in so many ways -- including but not limited to safety -- but regardless, memory safety comes at a price, language safety is not an end (that would be program correctness) but just one of many means to that end, there is no consensus at all over what is the most effective way to reach that end, and there are other things people care about as well. So…
Quoted post unavailable.
Re: Zig, the Small Language
#359Earlier quoted context omitted.
Completely unsurprisingly. "Add useless garbage to work around the stupid decisions we impose on you" is not very appreciated.
It is not useless though. There is a big difference between an unused variable and explicitly defining an unused variable. Kelly is designing Zig to do nothing surprising or change things underneath you. Even C does things that are surprising. If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. I think we do all a…
Using `_ = var` to prevent the error is just as bad as handling Java exceptions with empty catch blocks.