4 ms·

You shouldn't use it over rust... that's a nonsensical question. That's like asking when you should use a hammer instead of a screwdriver. I use zig because it

You shouldn't use it over rust... that's a nonsensical question. That's like asking when you should use a hammer instead of a screwdriver. I use zig because it's enjoyable to use. I hate writing rust, it feels like the language is actively fighting me. I started writing zig, and started loving the process of simplify writing code again. Zig is nice because, to steal their quote. I'm able to spend my time debugging my code, and not debugging my understanding of the language. I've stepped on a use after free but because it's so easy to write and use tests, I found it and fixed it in tests. Bugs are undesirable, but I can write just as many bugs in rust. So I'm always so confused about why rust users are so panicked about use after free, or other memory bugs. Like somehow the only bugs rust has a handle on is the worst class of bug? Such an odd idea I can't figure out...

satvikpendem 3y ago
Because I can either catch those bugs myself or let the computer catch them for me. I'm lazy and a fan of letting the computers do the work at compile-time so I don't have to run into them at runtime, at 3 AM in production. It's not the amount of bugs, I can also write out of bounds panic bugs, it's the type of bugs. And truth be told, if we get liquid types or dependent types in Rust, even those runtime out of bounds checks would be caught at compile-time too.
- grayhatter 3y ago
  This argument doesn't make sense to me either, but maybe I'm just stupid. For something to die at 3am in production, that means either someone pushed code way too late, or something changed in the stack unpredictability. Your compiler wouldn't have been able to predict either of those cases. But bugs are bugs, if I'm called at 3am to fix a bug, I don't want to spend hours trying to fight my compiler, and then fall back asleep while I'm waiting for it to compile. I want to quickly identify the issue, and then to be able to write the smallest possible patch until morning. In my limited experience, rust is conducive to neither of those options. And you said "if we get liquid types" I assume that means you meant it to say if rust gets? Unless you meant to identify as part of the rust language?
  - satvikpendem 3y ago
    My point is that the more bugs that are caught at compile-time rather than runtime, the better, as it's a much lower likelihood that something randomly breaks in the middle of the night. It has nothing to do with when someone pushed their code out or the stack changing. Someone could have pushed a runtime bug that was not caught (but that could have been caught at compile-time, depending on the type of bug, of course) that then breaks production later on when a specific thing gets triggered. You wouldn't be fighting the compiler at 3 am as well as the code because you likely wouldn't be fixing things at 3 am in the first place, and if it's not something that's caught at compile time, well then you'd be dealing with the language either way. Compile-time checks help you write better code, generally speaking.
    - wredue 3y ago
      The idea that “compile time checks help you write better code is unanimous and absolute” is simply false. Rust itself demonstrates that compile time checks sometimes result in worse code, as many people have found especially when they need to do things rust doesn’t like for performance reasons. For sure, some checks are unambiguously good. But there is also definitely a moving target of a line towards whether or not more checks has diminishing returns if not negative returns on your code. That moving line will depend on a lot of things. You also need to be careful because “more checks” doesn’t mean “less work” as you’ve asserted. It means more work in a lot of safe pointer scenarios in rust, and more work actually does often translate to more logic bugs and more complexity when anything changes. As far as I can tell, more checks doesn’t same any time, it often just changes where your time is spent.
      - tored 3y ago
        Not a Rust developer, in what way is Rust forcing you to write less performant code? Any good example?
        grayhatter 3y ago
        I doubt you'll have anyone take you up on this offer. Goal posts for "good example" get moved every time anyone tries. Anything using Arc is a good place to start though.
throwaway17_17 3y ago
They typical argument given for the focus on memory related bugs is that: ‘{company,Github,bug/cve -tracker} says (following code review | testing)* that 70% of reported bugs/exploits are due to memory management failures.’ I write it thusly, because I don’t actual know or remember all the various permutations I’ve seen. But a few that I can recall being mentioned would be Microsoft and Google, regarding Windows and Chrome (or it could have been the entire Google production code base). But other than these types of statements I can’t recall any support for focusing on memory vs other error kinds. This line of argument has led to developers who class memory ‘unsafe’ languages as objective moral bads (and the development of such to be inherently morally bad) [I was literally told this on HN, in the furor over the announcement of Hare Lang]. I think it’s reactions like this that lead to your usage of the word panicked, but I always try to assume the majority of developers are just using a language they enjoy and getting on with the business of making stuff. Just as a parting note: I’m not attempting to disagree with the statements by these companies, or with the general premise that memory safety errors result in problems for users of software. I’m slightly ambivalent to the whole thing. — edit for spelling
- tored 3y ago
  About 20 percent of all bugs in the Linux kernel are use-after-free. With that said, I think proper tooling can solve much of the problems with unsafe memory languages. Question is then, why doesn't it happen? Are developers uninformed, arrogant or just lazy? Is forcing it into the language the only way to solve this?
- wredue 3y ago
  I think your wording is off, because 70% of reports bugs are not memory related. I vaguely recall that 70% of *certain classes* of reported security flaws were buffer misuses (which zig handles quite nicely in releasesafe and using slices, which is recommended) Edit: Found it: 70% of security bugs were counted as safe buffer related. Note that by sticking to slices and releaseSafe, zig provides most of the same guarantees as rust in this arena. It’s unclear whether a buffer issue automatically classified a bug as a security flaw as well, as in many cases it’s simply not. For example, a memory security flaw was reported in Stockfish that was simply not a flaw. We are also discussing the Microsoft OS, which is a whole different beast than applications. Overall, meh.

satvikpendem 3y ago

Because I can either catch those bugs myself or let the computer catch them for me. I'm lazy and a fan of letting the computers do the work at compile-time so I don't have to run into them at runtime, at 3 AM in production. It's not the amount of bugs, I can also write out of bounds panic bugs, it's the type of bugs. And truth be told, if we get liquid types or dependent types in Rust, even those runtime out of bounds checks would be caught at compile-time too.

grayhatter 3y ago
This argument doesn't make sense to me either, but maybe I'm just stupid. For something to die at 3am in production, that means either someone pushed code way too late, or something changed in the stack unpredictability. Your compiler wouldn't have been able to predict either of those cases. But bugs are bugs, if I'm called at 3am to fix a bug, I don't want to spend hours trying to fight my compiler, and then fall back asleep while I'm waiting for it to compile. I want to quickly identify the issue, and then to be able to write the smallest possible patch until morning. In my limited experience, rust is conducive to neither of those options. And you said "if we get liquid types" I assume that means you meant it to say if rust gets? Unless you meant to identify as part of the rust language?
- satvikpendem 3y ago
  My point is that the more bugs that are caught at compile-time rather than runtime, the better, as it's a much lower likelihood that something randomly breaks in the middle of the night. It has nothing to do with when someone pushed their code out or the stack changing. Someone could have pushed a runtime bug that was not caught (but that could have been caught at compile-time, depending on the type of bug, of course) that then breaks production later on when a specific thing gets triggered. You wouldn't be fighting the compiler at 3 am as well as the code because you likely wouldn't be fixing things at 3 am in the first place, and if it's not something that's caught at compile time, well then you'd be dealing with the language either way. Compile-time checks help you write better code, generally speaking.
  - wredue 3y ago
    The idea that “compile time checks help you write better code is unanimous and absolute” is simply false. Rust itself demonstrates that compile time checks sometimes result in worse code, as many people have found especially when they need to do things rust doesn’t like for performance reasons. For sure, some checks are unambiguously good. But there is also definitely a moving target of a line towards whether or not more checks has diminishing returns if not negative returns on your code. That moving line will depend on a lot of things. You also need to be careful because “more checks” doesn’t mean “less work” as you’ve asserted. It means more work in a lot of safe pointer scenarios in rust, and more work actually does often translate to more logic bugs and more complexity when anything changes. As far as I can tell, more checks doesn’t same any time, it often just changes where your time is spent.
    - tored 3y ago
      Not a Rust developer, in what way is Rust forcing you to write less performant code? Any good example?
      - grayhatter 3y ago
        I doubt you'll have anyone take you up on this offer. Goal posts for "good example" get moved every time anyone tries. Anything using Arc is a good place to start though.

throwaway17_17 3y ago

They typical argument given for the focus on memory related bugs is that: ‘{company,Github,bug/cve -tracker} says (following code review | testing)* that 70% of reported bugs/exploits are due to memory management failures.’ I write it thusly, because I don’t actual know or remember all the various permutations I’ve seen. But a few that I can recall being mentioned would be Microsoft and Google, regarding Windows and Chrome (or it could have been the entire Google production code base). But other than these types of statements I can’t recall any support for focusing on memory vs other error kinds. This line of argument has led to developers who class memory ‘unsafe’ languages as objective moral bads (and the development of such to be inherently morally bad) [I was literally told this on HN, in the furor over the announcement of Hare Lang]. I think it’s reactions like this that lead to your usage of the word panicked, but I always try to assume the majority of developers are just using a language they enjoy and getting on with the business of making stuff. Just as a parting note: I’m not attempting to disagree with the statements by these companies, or with the general premise that memory safety errors result in problems for users of software. I’m slightly ambivalent to the whole thing. — edit for spelling

tored 3y ago
About 20 percent of all bugs in the Linux kernel are use-after-free. With that said, I think proper tooling can solve much of the problems with unsafe memory languages. Question is then, why doesn't it happen? Are developers uninformed, arrogant or just lazy? Is forcing it into the language the only way to solve this?
wredue 3y ago
I think your wording is off, because 70% of reports bugs are not memory related. I vaguely recall that 70% of *certain classes* of reported security flaws were buffer misuses (which zig handles quite nicely in releasesafe and using slices, which is recommended) Edit: Found it: 70% of security bugs were counted as safe buffer related. Note that by sticking to slices and releaseSafe, zig provides most of the same guarantees as rust in this arena. It’s unclear whether a buffer issue automatically classified a bug as a security flaw as well, as in many cases it’s simply not. For example, a memory security flaw was reported in Stockfish that was simply not a flaw. We are also discussing the Microsoft OS, which is a whole different beast than applications. Overall, meh.