5 ms·

> I don’t buy into the rhetoric that memory safety solves everything I haven’t heard that rhetoric, only that memory safety is a really good thing. If I can pa

> I don’t buy into the rhetoric that memory safety solves everything I haven’t heard that rhetoric, only that memory safety is a really good thing. If I can pay up front with some static analysis and eliminate entire classes of bugs, that’s just such a great thing, even if it doesn’t solve everything. I want to like and use Odin, because the guy behind it seems really cool, and it’s pretty indie, like zig. But the strong guarantees of rust are just so compelling.

Ygg2 4y ago
Memory safety is a bit like seatbelts (pardon the analogy). It's possible to drive a car and never need it and seatbelts can be uncomfortable. But I would never want to get in a car without one and it makes me question the sanity of people with saying stuff like "You most likely won't need it".
- discreteevent 4y ago
  There are plenty of programs written in C that will not kill somebody if there is a memory safety issue. It is not "insane" to write a game in C. Seatbelts are about physical safety which is in a completely different category.
  - Ygg2 4y ago
    > There are plenty of programs written in C that will not kill No, of course not (see analogy) - It will just make me wish for sweet, sweet release of death (see hyperbole). Point is, you can eliminate a class of nasty bugs. And instead you double down on it. So, I'll use a more programming example. C has more foot guns than just memory issues e.g. `if (a=4)`. For all its faults, Java only allowing boolean expression in if statements was a move in right direction. Now imagine after Java some C inheritor (Rust, Go, Carbon, Zig, Nim...) looked at `if (a=4)` and said. Yes. We need that in our lang. Can't you see we regressed in this hypothetical example? We traded correctness for expressivity. Same with memory safety. Rather than using a GC or some borrow checking system, we shrug and say, well what can ya do?
    - UncleEntity 4y ago
      > Rather than using a GC or some borrow checking system, we shrug and say, well what can ya do? Try different paths until someone stumbles on the One True Way™. Plus, `if (a=4)` will emit a compiler warning of ‘statement always evaluates to true’ or somesuch and is useful in some cases like ‘if (!(a=foo())) goto error;’
      - Ygg2 4y ago
        > Try different paths until someone stumbles on the One True Way™. I'm aware there isn't a perfect solution (because of Rice Theorem). But we don't need perfect, we need better than status quo (C). > Plus, `if (a=4)` will emit a compiler warning It's still a step down. What is better than a compiler warning that people can ignore? Prohibiting the syntax altogether. > goto error; This is another example of a famous chain-footgun. Most langs eschew use of goto even if it allows more flows than plain old for/while loops.
  - tayistay 4y ago
    I write art/music apps where nobody dies if it crashes in the field. But my perspective is this: because I'm an indie developer, I will get more hate mail and nasty reviews from people when they lose their work because my app crashed (or even if they don't lose their work!). I'd like to avoid said hate mail, and the nasty reviews hurt my business. I think developers at companies are more insulated from the customer and don't think about this as much.
foerbert 4y ago
I'd probably agree with that characterization. It's not that people are out there specifically claiming memory safety solves everything, but rather that the 'public consciousness' seems to have utterly forgotten that any other kind of safety exists. As a result, you get languages like (and mainly) Rust being held up as the paragons of program correctness and safety in general. Any discussions of program safety end up being entirely about memory safety. It's just an endless hoard of comments/blogs/posts/etc of people conflating memory safety with correctness and not even acknowledging - or possibly even knowing - there are other kinds of safety out there. So the rhetoric being referenced there is largely implicit. Anybody who actually mentions memory safety in specific terms is already ahead of the curve.
Tozen 4y ago
> But the strong guarantees of rust are just so compelling. Rust's safety comes at a cost. I think its not for the greater good to pretend to ignore such, and fall too deeply into hype, that can be partially generated by the companies behind it. With all things, there are positives and negatives. If you are into RAD or programs that you are creating are not mission-critical like that, then a person might want to avoid things like: longer compile times, low readability, difficult syntax, longer development times, etc... There is plenty of room for newer languages like Odin, Go, Vlang, etc... Where the focus has a wider scope for more convenient general-purpose programming.

Ygg2 4y ago

Memory safety is a bit like seatbelts (pardon the analogy). It's possible to drive a car and never need it and seatbelts can be uncomfortable. But I would never want to get in a car without one and it makes me question the sanity of people with saying stuff like "You most likely won't need it".

discreteevent 4y ago
There are plenty of programs written in C that will not kill somebody if there is a memory safety issue. It is not "insane" to write a game in C. Seatbelts are about physical safety which is in a completely different category.
- Ygg2 4y ago
  > There are plenty of programs written in C that will not kill No, of course not (see analogy) - It will just make me wish for sweet, sweet release of death (see hyperbole). Point is, you can eliminate a class of nasty bugs. And instead you double down on it. So, I'll use a more programming example. C has more foot guns than just memory issues e.g. `if (a=4)`. For all its faults, Java only allowing boolean expression in if statements was a move in right direction. Now imagine after Java some C inheritor (Rust, Go, Carbon, Zig, Nim...) looked at `if (a=4)` and said. Yes. We need that in our lang. Can't you see we regressed in this hypothetical example? We traded correctness for expressivity. Same with memory safety. Rather than using a GC or some borrow checking system, we shrug and say, well what can ya do?
  - UncleEntity 4y ago
    > Rather than using a GC or some borrow checking system, we shrug and say, well what can ya do? Try different paths until someone stumbles on the One True Way™. Plus, `if (a=4)` will emit a compiler warning of ‘statement always evaluates to true’ or somesuch and is useful in some cases like ‘if (!(a=foo())) goto error;’
    - Ygg2 4y ago
      > Try different paths until someone stumbles on the One True Way™. I'm aware there isn't a perfect solution (because of Rice Theorem). But we don't need perfect, we need better than status quo (C). > Plus, `if (a=4)` will emit a compiler warning It's still a step down. What is better than a compiler warning that people can ignore? Prohibiting the syntax altogether. > goto error; This is another example of a famous chain-footgun. Most langs eschew use of goto even if it allows more flows than plain old for/while loops.
- tayistay 4y ago
  I write art/music apps where nobody dies if it crashes in the field. But my perspective is this: because I'm an indie developer, I will get more hate mail and nasty reviews from people when they lose their work because my app crashed (or even if they don't lose their work!). I'd like to avoid said hate mail, and the nasty reviews hurt my business. I think developers at companies are more insulated from the customer and don't think about this as much.

foerbert 4y ago

I'd probably agree with that characterization. It's not that people are out there specifically claiming memory safety solves everything, but rather that the 'public consciousness' seems to have utterly forgotten that any other kind of safety exists. As a result, you get languages like (and mainly) Rust being held up as the paragons of program correctness and safety in general. Any discussions of program safety end up being entirely about memory safety. It's just an endless hoard of comments/blogs/posts/etc of people conflating memory safety with correctness and not even acknowledging - or possibly even knowing - there are other kinds of safety out there. So the rhetoric being referenced there is largely implicit. Anybody who actually mentions memory safety in specific terms is already ahead of the curve.

Tozen 4y ago

> But the strong guarantees of rust are just so compelling. Rust's safety comes at a cost. I think its not for the greater good to pretend to ignore such, and fall too deeply into hype, that can be partially generated by the companies behind it. With all things, there are positives and negatives. If you are into RAD or programs that you are creating are not mission-critical like that, then a person might want to avoid things like: longer compile times, low readability, difficult syntax, longer development times, etc... There is plenty of room for newer languages like Odin, Go, Vlang, etc... Where the focus has a wider scope for more convenient general-purpose programming.