7 ms·

"A fully unsafe language in 2022 is dumb." I think this is a subtweet at Zig, and while I am not a zig developer, I will point something out that everyone forg

by 3a2d29 4y ago

"A fully unsafe language in 2022 is dumb." I think this is a subtweet at Zig, and while I am not a zig developer, I will point something out that everyone forgets (to defend C++ and Zig and the like): Some apps don't need memory safety. For example a single player game or application that runs just on your own machine, memory safety would just be another type of bug. If dealing with Rust's ownership rules is annoying and you don't want a GC, then you can certainly use an unsafe language. Not all apps are websites and browsers. I would also add (I could be wrong here) but I think things written in web assembly can also be unsafe, as the memory is in a sandbox. I think I heard this once, but I could be wrong.

strictfp 4y ago
> Some apps don't need memory safety. Maybe not, but it's still a big pain in the butt to avoid bugs in that area. I imagine that static analysis for memory safety would be something that most developers would use in existing unsafe languages if they could.
- pjmlp 4y ago
  Lint was created for C in 1979… to this day most devs ignore static analysis tooling for C and C++.
  - KerrAvon 4y ago
    Static analysis can be excellent, but it doesn't solve the whole problem.
    - pjmlp 4y ago
      Indeed, still using it is better than nothing.
    - patrick451 4y ago
      For a lot of applications, that doesn't matter. It solves enough of the problem.
api 4y ago
> Some apps don't need memory safety. Even apps that run locally and don’t talk to the net can be vulnerable. How many break ins happen via bugs in PDF viewers, office packages, and media players? Look it up. PDF and spreadsheet vulnerabilities are very common. Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs. The latter are not ruled out in Go or Rust but they are profoundly less likely to occur, making code that actually takes advantage of modern hardware much easier to write. After learning Rust and after having used C++ very heavily for years I can say that Rust is far more productive.
- azakai 4y ago
  > PDF and spreadsheet vulnerabilities are very common. True. The issue is that they operate on complex input that can arrive from anywhere. So if you download a malicious PDF file it can exploit you. But GP's other example is valid: A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program. There is room for languages like Zig. There is also the potential for it to be used in improper places, but so far the majority of applications I've heard of seem reasonable to me. > Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs. Also true. But there are the other usual tradeoffs, such as that a language focused on simplicity and correctness, like Zig, might reduce other sources of bugs. Some developers might be more productive with Rust, others with Go, others with Zig. I don't think there's a single answer here. As an example of another related tradeoff, fast compile times often help debugging, which is an advantage of Go and Zig.
  - KerrAvon 4y ago
    > A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program. Nothing is that isolated anymore. Can you find a modern single-player game on Steam that doesn't talk to the network for analytics or DLC or sending crash reports to the developer? I'm sure they exist, but they're likely exceptionally rare. For Zig to be helpful in the modern world, it will need memory safety guarantees and it will need them on by default. It's totally OK if those are easier to switch off than in Rust so that you can do the low-level things performantly and easily. But you have to start from a default position of safety.
littlestymaar 4y ago
> Some apps don't need memory safety. Even setting security considerations aside, as soon as you have users, using a non-memory-safe language means having users reporting very unhelpful “bun crashes at startup with "segmentation fault"”and good luck to figure out what's going on. > I think this is a subtweet at Zig Why do you think it's especially aimed at Zig? Zig is only one among others, like Carbon, or Cppfront discussed here.
- 3a2d29 4y ago
  I would agree that seg faults are not fun to debug, but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules AND you can't use a GC, I do think it could be worth the trade-off. > Why do you think it's especially aimed at Zig? I honestly don't use zig so I really don't have a horse in the race, but when I read: "nothing but Rust or Go has any merit as a replacement unless it also bring the same safety. A fully unsafe language in 2022 is dumb" That seems to be targeted at replacing C++, which both Carbon and CppFront are not doing per se. Zig is the next big "low level replacement language" (that isn't Rust or Go) that HN seems to chat about so I took a guess. Again, I don't think that's too relevant to my point (although I am curious if OP wants to weigh in on what they meant).
  - littlestymaar 4y ago
    > but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules If you genuinely believe that Rusts rules slow developers down by “several ordrers of magnitude” (which litterally means: “makes you 100 times slower or more”) then you've probably listened/read way to much anti-rust discourse for your own good… Rust has a learning curve and in the beginning you're obviously going to be slowed down by the learning process, but for 99% of the tasks[1] once you've gone past the initial learning period, the rules aren't slowing you down since you've internalized them, and compiler errors end up being mostly about things that would have caused a memory bug in other low-level languages. [1]: that is, everything but custom graph data structures, which are really hard to get right without a GC anyway.
pjmlp 4y ago
Only because liability is still not a thing in software as in other regulated domains. > Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. -- C.A.R Hoare on his Turing award speech in 1981.
- 3a2d29 4y ago
  Against the law cause if you do this on a bridge, people die. If a play Civ V and it crashes, I just a bit mad. I will acknowledge though good engineering practices are important, maybe my perspective of "tolerance" of these bugs when they are isolated is missing the point.
  - pjmlp 4y ago
    If I play Civ V and it crashes, I want my money back, just like I won't stand a broken appliance. Thankfully App stores are already making this point clear to the industry.
    - 3a2d29 4y ago
      Doesn’t this counter your first point? A broken appliance isn’t against the law. Second, I think data shows most people don’t return games after 1 crash. In fact, I think getting to market fast is a bigger factor for profit.
      - pjmlp 4y ago
        Not refunding a customer for selling a broken product is against the consumer law in plenty of jurisdictions. People still don't do it because they have been taught that software is special, they have to put up with broken products, that is just how things are with computers.
charcircuit 4y ago
>memory safety would just be another type of bug A bug that can be costly to reproduce and fix and has the affect of terrible UX and losing unsaved progress. If I had to choose a category of bugs to tolerate memory safety bugs would be near the bottom of the list.
- jstimpfle 4y ago
  It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them? I know that in the domains that I'm interested in, I would be way miserable programming in something like e.g. Java, because I've figured out certain patterns that I know will work in a memory-unsafe language with very little friction, but that cannot be simply be translated to Java because of e.g. reference semantics. The same probably holds for other approaches to safety, like Rust. I'm not interested anymore in tight opinionated approaches to problem solving. I _love_ void-pointers and memcpy'ing stuff because these let me do abstraction with very low friction. Getting the job done very quickly, with very very low rate of bugs, and those get quickly fixed. (I'm not making a statement about multi-million line projects in corporate environments. This is about the situations that I run into, personally).
  - charcircuit 4y ago
    >how do you explain so many programmers still willingly choosing them? Lack of education + Legacy software / programmers / education material.
    - api 4y ago
      It’s also a dumb macho thing. “Real programmers…” Yeah and I bet real home builders don’t use nail guns, prefab sections, or tape measures. They just eyeball it all and use wooden pegs and hammers.
  - kouteiheika 4y ago
    > It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them? Honestly? And this might be a hot take - exactly the same way as I'd explain people rejecting structured programming way back in the day. It was the new thing on the block and people were not used to it, and preferred to just sprinkle GOTOs in their program just like they always used to do rather than learning a new paradigm. As someone who used to professionally program in C++ on an expert level in the past and now has completely switched to Rust I can tell you that (at least subjectively for me) Rust is way more productive than C++ ever was. Once you internalize how the language works the limitations of Rust just disappear. You learn how to instinctively write code that's idiomatic, and it just stops slowing you down. But it also gives you a ton of new features that end up speeding you up compared to C++, e.g. sum types, pattern matching, cargo, great standard library, destructive moves, proper modules, #[derive], good error messages, etc. Memory safety can also be significant productivity boost because you can (or at least I do) just churn out code without thinking about it too much and just rely on the compiler to make sure that it's memory safe. Can this code trigger use-after-free? Is this iterator valid? What's the lifetime of this pointer? Instead of thinking about all of these you can use those brain cells for something else.
astrange 4y ago
A single player game still accesses the network. Consoles that trust their game code regularly get jailbroken through eg overflows in a game's save file formats. Plus it's only single player until they decide to add multiplayer…

by 3a2d29 4y ago

strictfp 4y ago

> Some apps don't need memory safety. Maybe not, but it's still a big pain in the butt to avoid bugs in that area. I imagine that static analysis for memory safety would be something that most developers would use in existing unsafe languages if they could.

pjmlp 4y ago
Lint was created for C in 1979… to this day most devs ignore static analysis tooling for C and C++.
- KerrAvon 4y ago
  Static analysis can be excellent, but it doesn't solve the whole problem.
  - pjmlp 4y ago
    Indeed, still using it is better than nothing.
  - patrick451 4y ago
    For a lot of applications, that doesn't matter. It solves enough of the problem.

api 4y ago

> Some apps don't need memory safety. Even apps that run locally and don’t talk to the net can be vulnerable. How many break ins happen via bugs in PDF viewers, office packages, and media players? Look it up. PDF and spreadsheet vulnerabilities are very common. Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs. The latter are not ruled out in Go or Rust but they are profoundly less likely to occur, making code that actually takes advantage of modern hardware much easier to write. After learning Rust and after having used C++ very heavily for years I can say that Rust is far more productive.

azakai 4y ago
> PDF and spreadsheet vulnerabilities are very common. True. The issue is that they operate on complex input that can arrive from anywhere. So if you download a malicious PDF file it can exploit you. But GP's other example is valid: A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program. There is room for languages like Zig. There is also the potential for it to be used in improper places, but so far the majority of applications I've heard of seem reasonable to me. > Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs. Also true. But there are the other usual tradeoffs, such as that a language focused on simplicity and correctness, like Zig, might reduce other sources of bugs. Some developers might be more productive with Rust, others with Go, others with Zig. I don't think there's a single answer here. As an example of another related tradeoff, fast compile times often help debugging, which is an advantage of Go and Zig.
- KerrAvon 4y ago
  > A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program. Nothing is that isolated anymore. Can you find a modern single-player game on Steam that doesn't talk to the network for analytics or DLC or sending crash reports to the developer? I'm sure they exist, but they're likely exceptionally rare. For Zig to be helpful in the modern world, it will need memory safety guarantees and it will need them on by default. It's totally OK if those are easier to switch off than in Rust so that you can do the low-level things performantly and easily. But you have to start from a default position of safety.

littlestymaar 4y ago

> Some apps don't need memory safety. Even setting security considerations aside, as soon as you have users, using a non-memory-safe language means having users reporting very unhelpful “bun crashes at startup with "segmentation fault"”and good luck to figure out what's going on. > I think this is a subtweet at Zig Why do you think it's especially aimed at Zig? Zig is only one among others, like Carbon, or Cppfront discussed here.

3a2d29 4y ago
I would agree that seg faults are not fun to debug, but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules AND you can't use a GC, I do think it could be worth the trade-off. > Why do you think it's especially aimed at Zig? I honestly don't use zig so I really don't have a horse in the race, but when I read: "nothing but Rust or Go has any merit as a replacement unless it also bring the same safety. A fully unsafe language in 2022 is dumb" That seems to be targeted at replacing C++, which both Carbon and CppFront are not doing per se. Zig is the next big "low level replacement language" (that isn't Rust or Go) that HN seems to chat about so I took a guess. Again, I don't think that's too relevant to my point (although I am curious if OP wants to weigh in on what they meant).
- littlestymaar 4y ago
  > but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules If you genuinely believe that Rusts rules slow developers down by “several ordrers of magnitude” (which litterally means: “makes you 100 times slower or more”) then you've probably listened/read way to much anti-rust discourse for your own good… Rust has a learning curve and in the beginning you're obviously going to be slowed down by the learning process, but for 99% of the tasks[1] once you've gone past the initial learning period, the rules aren't slowing you down since you've internalized them, and compiler errors end up being mostly about things that would have caused a memory bug in other low-level languages. [1]: that is, everything but custom graph data structures, which are really hard to get right without a GC anyway.

pjmlp 4y ago

Only because liability is still not a thing in software as in other regulated domains. > Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. -- C.A.R Hoare on his Turing award speech in 1981.

3a2d29 4y ago
Against the law cause if you do this on a bridge, people die. If a play Civ V and it crashes, I just a bit mad. I will acknowledge though good engineering practices are important, maybe my perspective of "tolerance" of these bugs when they are isolated is missing the point.
- pjmlp 4y ago
  If I play Civ V and it crashes, I want my money back, just like I won't stand a broken appliance. Thankfully App stores are already making this point clear to the industry.
  - 3a2d29 4y ago
    Doesn’t this counter your first point? A broken appliance isn’t against the law. Second, I think data shows most people don’t return games after 1 crash. In fact, I think getting to market fast is a bigger factor for profit.
    - pjmlp 4y ago
      Not refunding a customer for selling a broken product is against the consumer law in plenty of jurisdictions. People still don't do it because they have been taught that software is special, they have to put up with broken products, that is just how things are with computers.

charcircuit 4y ago

>memory safety would just be another type of bug A bug that can be costly to reproduce and fix and has the affect of terrible UX and losing unsaved progress. If I had to choose a category of bugs to tolerate memory safety bugs would be near the bottom of the list.

jstimpfle 4y ago
It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them? I know that in the domains that I'm interested in, I would be way miserable programming in something like e.g. Java, because I've figured out certain patterns that I know will work in a memory-unsafe language with very little friction, but that cannot be simply be translated to Java because of e.g. reference semantics. The same probably holds for other approaches to safety, like Rust. I'm not interested anymore in tight opinionated approaches to problem solving. I _love_ void-pointers and memcpy'ing stuff because these let me do abstraction with very low friction. Getting the job done very quickly, with very very low rate of bugs, and those get quickly fixed. (I'm not making a statement about multi-million line projects in corporate environments. This is about the situations that I run into, personally).
- charcircuit 4y ago
  >how do you explain so many programmers still willingly choosing them? Lack of education + Legacy software / programmers / education material.
  - api 4y ago
    It’s also a dumb macho thing. “Real programmers…” Yeah and I bet real home builders don’t use nail guns, prefab sections, or tape measures. They just eyeball it all and use wooden pegs and hammers.
- kouteiheika 4y ago
  > It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them? Honestly? And this might be a hot take - exactly the same way as I'd explain people rejecting structured programming way back in the day. It was the new thing on the block and people were not used to it, and preferred to just sprinkle GOTOs in their program just like they always used to do rather than learning a new paradigm. As someone who used to professionally program in C++ on an expert level in the past and now has completely switched to Rust I can tell you that (at least subjectively for me) Rust is way more productive than C++ ever was. Once you internalize how the language works the limitations of Rust just disappear. You learn how to instinctively write code that's idiomatic, and it just stops slowing you down. But it also gives you a ton of new features that end up speeding you up compared to C++, e.g. sum types, pattern matching, cargo, great standard library, destructive moves, proper modules, #[derive], good error messages, etc. Memory safety can also be significant productivity boost because you can (or at least I do) just churn out code without thinking about it too much and just rely on the compiler to make sure that it's memory safe. Can this code trigger use-after-free? Is this iterator valid? What's the lifetime of this pointer? Instead of thinking about all of these you can use those brain cells for something else.

astrange 4y ago

A single player game still accesses the network. Consoles that trust their game code regularly get jailbroken through eg overflows in a game's save file formats. Plus it's only single player until they decide to add multiplayer…