101–110 of 193 posts
Earlier quoted context omitted.
That's a rather extreme position.
It's not an extreme position. Most languages in wide use, and virtually all new languages, are memory safe. Zig is an extreme outlier in this regard.
Earlier quoted context omitted.
> Zig has a pretty good memory safety story No, Zig is simply not memory safe. That's a property of a programming language that has a definition. Zig does not meet that definition. > I find it funny that fans of a language of a not-so-young-age that is struggling to find relevance and capture even 1% of the market are treating it as such an inevitability that it's irresponsible to talk about anything else. Leaving as…
> No, Zig is simply not memory safe. I didn't claim that it is. I said it has a good memory safety story, i.e. mechanisms that soundly guarantee some kinds of memory safety, plus a design that helps write correct programs. Correctness in general, and memory safety in particular, are very central concerns in Zig's design, it's just that its story isn't one of sound guarantees across the board but, rather, some balance…
Zig doesn't have mechanisms that soundly guarantee some kinds of memory safety. It's not spacially memory safe: extern unions, sentinel-terminated pointers, and multi-element pointers break it. At best, we think there's probably some subset of Zig that you could define that is spacially memory safe. (This isn't a particularly interesting property because it's trivially true for any language, by the way: C without pointers and without arrays is a subset of C that's memory safe, for instance, and also uninteresting.)
> No, Zig is a low-level language, and the vast majority of low-level programs in 2022 are written in languages whose memory-safety story is worse than Zig's.
Zig claims to be a general-purpose language, not just a low-level one. From [1]: "Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software."
> I mean, it sure is better to have more guarantees if they come for free, but there's no such option in front of us just yet.
It's better to have more guarantees if the benefit of the guarantees outweighs the cost, not if there is no cost. For example, for many apps, the benefit of memory safety outweighs the cost of a garbage collector.
> You can't insist there's consensus when clearly there are people who disagree with you. That's the definition of a lack of consensus.
Consensus doesn't mean that nobody disagrees. It means that the opposite position is a fringe view.
Earlier quoted context omitted.
It's not an extreme position. Most languages in wide use, and virtually all new languages, are memory safe. Zig is an extreme outlier in this regard.
That's extremely hyperbolic. Zig is a systems programming language with an explicit goal of operating at a low level of abstraction. Virtually all languages in its class are less memory safe than Zig.
Earlier quoted context omitted.
Good sign for the language, bad sign for HN. I totally get it's nicer than C, I love it too, but it's completely irresponsible to push a language without a memory safety story, in 2022, this hard. From that relatively obvious conclusion it devolves into tedious nerdsnipes. Yes there are edge cases.
Zig has a pretty good memory safety story -- and more generally, a correctness story -- it's just a different story from Rust's. I find it funny that fans of a language of a not-so-young-age that is struggling to find relevance and capture even 1% of the market are treating it as such an inevitability that it's irresponsible to talk about anything else. It's also detached from reality, as much of the software we all…
The idea it's either "Rust or Zig" allows the poorly considered logical jump to Zig. I wouldn't use Rust because it's annoying too, but I also wouldn't choose Zig because I consider part of my professional responsibility to be using...literally any language that has memory safety.
Earlier quoted context omitted.
It's not an extreme position. Most languages in wide use, and virtually all new languages, are memory safe. Zig is an extreme outlier in this regard.
That's extremely hyperbolic. Zig is a systems programming language with an explicit goal of operating at a low level of abstraction. Virtually all languages in its class are less memory safe than Zig.
Earlier quoted context omitted.
That's extremely hyperbolic. Zig is a systems programming language with an explicit goal of operating at a low level of abstraction. Virtually all languages in its class are less memory safe than Zig.
Except Rust? We can't ignore the fact that Rust has shown that memory safety is not incompatible with low-level semantics. (Of course, Ada, Cyclone, CCured, etc. showed this much earlier than Rust.)
It is very much not the consensus that memory safety is a requirement for any modern language. Asserting that it should be a requirement is an extreme position.
Earlier quoted context omitted.
That's extremely hyperbolic. Zig is a systems programming language with an explicit goal of operating at a low level of abstraction. Virtually all languages in its class are less memory safe than Zig.
"Virtually" is where your argument falls apart, and I want to be clear I'm not just dunking and moving on, I do understand the position that _not_ using a memory safe language is irresponsible is fairly new.
Assuming that my argument has "fallen apart", or that you have "dunked" seems quite absurd given that you've taken an extreme position which many serious practitioners and academics would disagree with.
Earlier quoted context omitted.
There's actually already a patch for this posted on the github issue. It's only about a 5 line change.
The patch works, but it's not efficient to have every user patch their own compiler on every release (and forgo the system package manager for upgrades). I was also envisioning adding a warning system, changing the checks to warnings instead of removing them completely, and adding a `-Werror` flag (or maybe `-Wno-error`). It would be a bit more than 5 lines, but still relatively low effort compared to how impactful t…
Earlier quoted context omitted.
"Virtually" is where your argument falls apart, and I want to be clear I'm not just dunking and moving on, I do understand the position that _not_ using a memory safe language is irresponsible is fairly new.
That position is not only new, it's also not the consensus. Zig explicitly chooses to make memory safety a non-goal of the language, with the argument that Rust-style memory safety is a costly tradeoff which is not always justified. Assuming that my argument has "fallen apart", or that you have "dunked" seems quite absurd given that you've taken an extreme position which many serious practitioners and academics would…
Earlier quoted context omitted.
> No, Zig is simply not memory safe. I didn't claim that it is. I said it has a good memory safety story, i.e. mechanisms that soundly guarantee some kinds of memory safety, plus a design that helps write correct programs. Correctness in general, and memory safety in particular, are very central concerns in Zig's design, it's just that its story isn't one of sound guarantees across the board but, rather, some balance…
> I didn't claim that it is. I said it has a good memory safety story, i.e. mechanisms that soundly guarantee some kinds of memory safety, as well as a design that makes it relatively easy to help write correct programs. Zig doesn't have mechanisms that soundly guarantee some kinds of memory safety. It's not spacially memory safe: extern unions, sentinel-terminated pointers, and multi-element pointers break it. At be…
It does.
> It's not spacially memory safe: extern unions, sentinel-terminated pointers, and multi-element pointers break it.
We've been through that. Those are syntactically delineated unsafe features for C/hardware interop. Rust has them, too.
> This isn't a particularly interesting property because it's trivially true for any language
That's right, but Zig is much closer to Rust than to C in that regard. It has clearly marked unsafe features for C or hardware interop, which aren't used in other situations and could be mechanically excluded -- just as in Rust.
> Zig claims to be a general-purpose language, not just a low-level one.
Surely you agree it's also a low-level language?
> It's better to have more guarantees if the benefit of the guarantees outweighs the cost, not if there is no cost.
Yep, and we don't know if we're there in low level languages. So far it seems that some people find the cost of Rust acceptable and others do not. In other words, there's no consensus on what the acceptable cost is.
> It means that the opposite position is a fringe view.
So disagreeing that the only right design is that of a language that's struggling to get 1% of the market is a fringe view? That's like a Haskeller declaring that it is a fringe view to disagree that non-strict pure functional programming is the only right way to write programs. I think that Odin and JAI, two other low level languages in development, also don't go down the full memory-safety soundness path. Seems to me to be quite far from a fringe view.
If people aren't buying what Rust is selling -- regardless of how strongly some feel about the justice of its approach -- I think that those of us who care about correctness must explore alternatives, and Zig is certainly a fascinating alternative. It might well be the case that neither Rust nor Zig succeed in the market, but even in that case, both can certainly serve as inspiration for the languages that follow.