111–120 of 193 posts
Earlier quoted context omitted.
"Optimizing for incorrectness" is a funny way to describe the practice of enforcing lint checks as part of a CI pipeline.
You're right, the provocation here is engaging in intentionally choosing a language, and choosing Zig, is optimizing for incorrectness . I didn't mean the flag.
Earlier quoted context omitted.
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…
The point is that Zig's choice around memory safety makes its language design principles significantly outside the consensus around what PL design should be.
Rust is still very much an experiment in terms of systems programming. It has a tiny overall "market share" in terms of use in large production projects compared to C/C++ and it remains to be seen whether the particular set of tradeoffs chosen by the language will lead to long term sustainable success.
Zig takes another approach and is also a worthy experiment.
Earlier quoted context omitted.
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…
I actually have never tried Rust and probably never will, you lied when you implied I was a fan of the language. I'd probably hate it, in fact. 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 sa…
If you think it's your responsibility to use only memory-safe languages, then if you had to do low-level programming, you'd have few option, and those options have their own downsides. That's just the reality of low level programming in 2022 -- it can often only be done in non-memory-safe languages. I actually do quite a bit of low-level programming, and I consider it my professional responsibility to strive to do that in a language that is explicit and simple; there are no languages, to my knowledge, that meet my requirement and are also memory-safe, so I must compromise on something because I live in the real world.
Earlier quoted context omitted.
> 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…
> Zig doesn't have mechanisms that soundly guarantee some kinds of memory safety. 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…
And again we're assuming that the ones we went over in the previous thread are all there is. I found some more: @intToPtr, @bitCast, @alignCast. Some of those @ functions are spatially-memory-safe, and some are not: the differences are not clearly called out.
(I'm going to charitably assume that taking a pointer to an element in a dynamically-allocated array, and then shortening that array and dereferencing that pointer, is a temporal memory safety violation rather than a spatial one.)
> That's right, but Zig is much closer to Rust than to C in that regard. It has clearly marked unsafe features for C interop.
How are they clearly marked, when they're neither relegated to a separate section of the documentation nor behind a switch? As far as I can tell, the person who has gone through the most effort to isolate the spatial memory safe subset of Zig is me, in these HN threads.
> So disagreeing that the design of a language that's struggling to get 1% of the market is the only right way is a fringe view now?
Again, "struggling to get 1% of the market" is a weird way to describe a language that's serving billions of users right now.
Earlier quoted context omitted.
The point is that Zig's choice around memory safety makes its language design principles significantly outside the consensus around what PL design should be.
According to who? It's absolutely not the consensus that every programming language needs to prioritize safety. Rust is still very much an experiment in terms of systems programming. It has a tiny overall "market share" in terms of use in large production projects compared to C/C++ and it remains to be seen whether the particular set of tradeoffs chosen by the language will lead to long term sustainable success. Zig…
Earlier quoted context omitted.
I actually have never tried Rust and probably never will, you lied when you implied I was a fan of the language. I'd probably hate it, in fact. 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 sa…
There is no "jump" to Zig, just a rejection of the claim that all low-level languages "in 2022" must be memory safe -- not just Zig, but also Odin and JAI aren't (I think). If you need to do low level programming, the fact is that in 2022 there is no consensus over whether you should do it in a memory safe language. If you think it's your responsibility to use only memory-safe languages, then if you had to do low-lev…
That isn't true. You want to use a language that is more "explicit and simple". That's your prerogative, even if I disagree with it. But you do have a choice, and you are explicitly choosing to reject memory safety.
Earlier quoted context omitted.
According to who? It's absolutely not the consensus that every programming language needs to prioritize safety. Rust is still very much an experiment in terms of systems programming. It has a tiny overall "market share" in terms of use in large production projects compared to C/C++ and it remains to be seen whether the particular set of tradeoffs chosen by the language will lead to long term sustainable success. Zig…
Rust is serving billions of users right now. It's far past the "experiment" stage and has proven itself.
I'm not diminishing the success of Rust. It's been proven it can be used for serious projects.
It's a bit of a reach to argue it's proven to be the best choice for all system programming use-cases going forward.
Earlier quoted context omitted.
And make your completely new mess. I doubt JS will stop being primary language in browsers in my lifetime.
You have chance to prevent it. It's not going to be perfect but use huge lesson learned from js ecosystem "mess" (I found this triggers some (many) js folks, it's quite ridiculous). Javascript "mess" in browsers could be reduced by dividing into two parts. DOM stuff, and pure language stuff. The first part can stay as is. Probably wrapped into thin API for new lang interop. The second part is a completely new lang th…
People come and go either because of life or work, and complexity piles up. I don't think there are any silver bullets.
There is a reason Worse is Better. It's quicker to ship and spread.
From the perspective that development time is a big constraint in a game jam it's no wonder zig is more popular than rust
Earlier quoted context omitted.
For me Rust is a language that I would absolutely love to work with in a professional context. The type system and borrow checker have your back and help you make changes to the code without fear of accidentally introducing any regressions. For private lone-hacking projects though it feels way too complex and opinionated. Here Zig definitely gets closer to what I need, though sadly it made unused variables an compile…
That's the one thing keeping me from considering Zig for new projects right now. If some enterprising young developer is reading this and wants to make a name for themselves, you should fork the Zig compiler and change those errors to warnings. It would be an extremely popular project. EDIT: I'll even give you a catchy project name. Wig: Zig with Warnings
Fridays are my live streaming day and I've chosen today's topic to be the user experience of unused variable errors. I have an idea to solve this that can satisfy both parties - those who don't want to be bothered by such errors, and those who want the premise upheld that if Zig code compiles, it does not have any unused variables.
In approximately 60 minutes I'll go live on https://www.twitch.tv/andrewrok/