9 ms·

I know rewrite it in Rust has essentially become a meme at this point, but really there aren't a lot of great reasons to write new software in languages that ar

by _mlbt 3y ago

I know rewrite it in Rust has essentially become a meme at this point, but really there aren't a lot of great reasons to write new software in languages that aren't memory safe. The only compelling reasons I can think of off the top of my head are interop with existing software and that C and C++ developers would require a bit of training to move to safer languages. There may also be a few problem domains that demand the maximum performance and lowest resource utilization possible, but your typical software would have more than acceptable performance in a memory safe language.

throwawaymaths 3y ago
what does this even mean. I guess in the future you will not be allowed to use any rust that uses unsafe()?
- digging 3y ago
  Are you asking what does (the comment you're replying to) mean, or what does (TFA) mean? > not be allowed to use any rust that uses unsafe() Not allowed by whom? What's made you assume your computer will be policed for non-memory-safe code?
- _mlbt 3y ago
  No one is saying that you can't use unsafe languages or features when you need to. This press release is announcing the release of a report from the White House Office of the National Cyber Director (ONCD) and it is simply a recommendation, not law or regulatory guidance.
  - generalizations 3y ago
    TBH it'd be pretty hilarious if they actually tried to restrict the use of unsafe languages.
    - wolverine876 3y ago
      Other fields are restricted from using unsafe materials and materials, and are required to demonstrate safety. I think IT still has it's head in the space of an immature industry of hackers. IMHO, at least for many things, such as IT systems controlling fundamental public functions (e.g., DNS), services (e.g., electrical grid), dangerous machines, etc., our engineering should be held the same standards as bridges, airplanes, etc. Look at the endless problems and costs caused by our crappy quality: National security harms and risk, privacy violations, endless fraud, systems that are almost impossible to adequately secure.
      - 01HNNWZ0MV43FF 3y ago
        Maybe C++ will be like asbestos: "Don't build with it. Wear PPE while removing it. And if it's not doing anything, for god's sake, don't touch it!"
      - generalizations 3y ago
        > immature industry of hackers This hacker news, after all. Hackers built this stuff, and they laugh at the bureaucrats who try to make rules to control it. > our engineering should be held the same standards as bridges, airplanes, etc In principle, I'd agree. BUT that's only going to happen when the practitioners have the ability to say "no" to bad designs and short deadlines. Which requires some kind of professional engineering certification, and requirements that only certified software engineers be allowed to do certain things, and certified software engineers that actually have the guts to say no. Lacking that, we'd just have to regulate the designs themselves - and, as soon as government regs get their hands on any software design, I guarantee you innovation of those designs will freeze. (Same reason why innovation of private aircraft has frozen - the cessna, the most popular private aircraft, is an eighty year old design because innovation is virtually impossible, because regulations, because safety.) > Look at the endless problems and costs caused by our crappy quality: National security harms and risk, privacy violations, endless fraud, systems that are almost impossible to adequately secure. Yes, but look at the incredible pace of innovation which the lack of regulation has allowed: web browsers, operating systems, word processors, scripting languages, world-wide communication and freedom from oppression. You can't stop the signal.
- sunshowers 3y ago
  I feel like people on an esteemed forum like Hacker News should be able to move past this kind of beginner-level argument. The point of memory safe languages is not to not have unsafe code. It is to centralize unsafe code in a few places that can be thoroughly audited, tested, and verified, and then provide safe abstractions on top of that.
  - throwawaymaths 3y ago
    The point is not about hacker news. The point is: should we choose to regulate this, what level of sophistication do you think regulators will operate at? Inb4 this is only a recommendation: regulation often starts as recommendation trial balloons
wakawaka28 3y ago
How about the sheer cost of the rewrites? Probably hundreds of billions of dollars worth of rewriting and retesting, if not more. Plus the costs of retraining. Memory safety is very weak in Rust, IMO. Memory errors are only one kind of error, and users of other languages have invented many brilliant ways to avoid and fix issues. It would be better to focus on detecting and preventing errors than rewriting IMO.
- _mlbt 3y ago
  That's why I said new software. I understand that it is unrealistic to rewrite existing software in many cases.
  - wakawaka28 3y ago
    It's also unrealistic to expect existing software to go away. So "memory unsafe" languages aren't going anywhere. People who don't want to learn how to manage memory correctly have had good alternatives to C and C++ for decades, each with their own drawbacks. And C and C++ remain viable with active developer communities despite all the attacks over a span of decades crying about memory management being difficult.
    - _mlbt 3y ago
      The crux of the problem is not that memory management is difficult, it’s that with unsafe languages it is dangerously error prone. In the 70s and 80s most machines were considerably more resource constrained and either on closed networks or not networked at all. In today’s world where everything is connected to 24/7 high speed internet these are risks that just aren’t worth taking for most new software projects.
      - wakawaka28 3y ago
        You say it isn't difficult but it is "error-prone", which is a contradiction. Either it is hard to get right or it isn't. I think it might be but not to the extent you do. Whatever issues we have with memory management, solutions exist and have existed for decades. People who continue to use so-called "unsafe" languages tend to know what they're doing. There are lots of solutions out there besides rewriting in another language that isn't that much less error-prone, such as Rust.
carlmr 3y ago
>The only compelling reasons I can think of off the top of my head are interop with existing software and that C and C++ developers would require a bit of training to move to safer languages. Decent C and C++ developers shouldn't take that long to grasp the borrow-checker. Those that don't can't be trusted coding C or C++ in the first place. Because they don't have a good enough mental model of memory management to deal with it manually. Interop with C is fairly straightforward. Python also with PyO3. C++ has some support. > There may also be a few problem domains that demand the maximum performance and lowest resource utilization possible You can approach that with Rust as well. Often you can even do performance improvements better and safer then in C++, because the borrow checker helps you stay safe. Especially CoW is a godsend when processing data.
- JoshTriplett 3y ago
  > Decent C and C++ developers shouldn't take that long to grasp the borrow-checker. Those that don't can't be trusted coding C or C++ in the first place. Because they don't have a good enough mental model of memory management to deal with it manually. In fairness to C and C++ developers: while often the problem is not understanding memory management, sometimes the problem is understanding it and having a model that doesn't mesh with borrow checking, or having a problem that needs some additional work to map into something easy to write in safe code. For instance, it takes some additional knowledge in Rust to know that if you want to build a graph, you 1) should almost always use an established graph library and not write your own, and 2) if you do need to write your own graph, you either need to use Rc, have an array of nodes and use indices, or use unsafe and raw pointers and provide a nice safe well-tested wrapper. (I'm one of the developers of Rust, and I think it's important to characterize languages fairly.)
  - carlmr 3y ago
    I don't disagree with either of your points, but when I learned Rust, those points about borrow-checker vs graphs in the cycle were entirely clear after looking at the first few tutorial lessons on the borrow-checker. Maybe day 2 of learning Rust for me. And coming from C++, Rc is not such a foreign concept compared to smart pointers. Coming from C it might be a bit more of a foreign concept I'll admit.
Cloudef 3y ago
There are few reasons: > Productivity > Readability > Performance > Static binaries > Not needing PhD in rust, especially async rust Rust works fine as high level language but it's absolutely awful for anything else and suffers from C++ feature creep. It would be a much better language if rust wasn't afraid of making `unsafe` an useful tool rather than thing that "everyone expect the core devs should absolutely avoid". Ergonomics would increase tenfolds if you could use it to essentially control the borrow checker better as well instead having to do mega abstractions (which aren't often zero-cost even) or hoops for every single thing. https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

by _mlbt 3y ago

throwawaymaths 3y ago

what does this even mean. I guess in the future you will not be allowed to use any rust that uses unsafe()?

digging 3y ago
Are you asking what does (the comment you're replying to) mean, or what does (TFA) mean? > not be allowed to use any rust that uses unsafe() Not allowed by whom? What's made you assume your computer will be policed for non-memory-safe code?
_mlbt 3y ago
No one is saying that you can't use unsafe languages or features when you need to. This press release is announcing the release of a report from the White House Office of the National Cyber Director (ONCD) and it is simply a recommendation, not law or regulatory guidance.
- generalizations 3y ago
  TBH it'd be pretty hilarious if they actually tried to restrict the use of unsafe languages.
  - wolverine876 3y ago
    Other fields are restricted from using unsafe materials and materials, and are required to demonstrate safety. I think IT still has it's head in the space of an immature industry of hackers. IMHO, at least for many things, such as IT systems controlling fundamental public functions (e.g., DNS), services (e.g., electrical grid), dangerous machines, etc., our engineering should be held the same standards as bridges, airplanes, etc. Look at the endless problems and costs caused by our crappy quality: National security harms and risk, privacy violations, endless fraud, systems that are almost impossible to adequately secure.
    - 01HNNWZ0MV43FF 3y ago
      Maybe C++ will be like asbestos: "Don't build with it. Wear PPE while removing it. And if it's not doing anything, for god's sake, don't touch it!"
    - generalizations 3y ago
      > immature industry of hackers This hacker news, after all. Hackers built this stuff, and they laugh at the bureaucrats who try to make rules to control it. > our engineering should be held the same standards as bridges, airplanes, etc In principle, I'd agree. BUT that's only going to happen when the practitioners have the ability to say "no" to bad designs and short deadlines. Which requires some kind of professional engineering certification, and requirements that only certified software engineers be allowed to do certain things, and certified software engineers that actually have the guts to say no. Lacking that, we'd just have to regulate the designs themselves - and, as soon as government regs get their hands on any software design, I guarantee you innovation of those designs will freeze. (Same reason why innovation of private aircraft has frozen - the cessna, the most popular private aircraft, is an eighty year old design because innovation is virtually impossible, because regulations, because safety.) > Look at the endless problems and costs caused by our crappy quality: National security harms and risk, privacy violations, endless fraud, systems that are almost impossible to adequately secure. Yes, but look at the incredible pace of innovation which the lack of regulation has allowed: web browsers, operating systems, word processors, scripting languages, world-wide communication and freedom from oppression. You can't stop the signal.
sunshowers 3y ago
I feel like people on an esteemed forum like Hacker News should be able to move past this kind of beginner-level argument. The point of memory safe languages is not to not have unsafe code. It is to centralize unsafe code in a few places that can be thoroughly audited, tested, and verified, and then provide safe abstractions on top of that.
- throwawaymaths 3y ago
  The point is not about hacker news. The point is: should we choose to regulate this, what level of sophistication do you think regulators will operate at? Inb4 this is only a recommendation: regulation often starts as recommendation trial balloons

wakawaka28 3y ago

How about the sheer cost of the rewrites? Probably hundreds of billions of dollars worth of rewriting and retesting, if not more. Plus the costs of retraining. Memory safety is very weak in Rust, IMO. Memory errors are only one kind of error, and users of other languages have invented many brilliant ways to avoid and fix issues. It would be better to focus on detecting and preventing errors than rewriting IMO.

_mlbt 3y ago
That's why I said new software. I understand that it is unrealistic to rewrite existing software in many cases.
- wakawaka28 3y ago
  It's also unrealistic to expect existing software to go away. So "memory unsafe" languages aren't going anywhere. People who don't want to learn how to manage memory correctly have had good alternatives to C and C++ for decades, each with their own drawbacks. And C and C++ remain viable with active developer communities despite all the attacks over a span of decades crying about memory management being difficult.
  - _mlbt 3y ago
    The crux of the problem is not that memory management is difficult, it’s that with unsafe languages it is dangerously error prone. In the 70s and 80s most machines were considerably more resource constrained and either on closed networks or not networked at all. In today’s world where everything is connected to 24/7 high speed internet these are risks that just aren’t worth taking for most new software projects.
    - wakawaka28 3y ago
      You say it isn't difficult but it is "error-prone", which is a contradiction. Either it is hard to get right or it isn't. I think it might be but not to the extent you do. Whatever issues we have with memory management, solutions exist and have existed for decades. People who continue to use so-called "unsafe" languages tend to know what they're doing. There are lots of solutions out there besides rewriting in another language that isn't that much less error-prone, such as Rust.

carlmr 3y ago

>The only compelling reasons I can think of off the top of my head are interop with existing software and that C and C++ developers would require a bit of training to move to safer languages. Decent C and C++ developers shouldn't take that long to grasp the borrow-checker. Those that don't can't be trusted coding C or C++ in the first place. Because they don't have a good enough mental model of memory management to deal with it manually. Interop with C is fairly straightforward. Python also with PyO3. C++ has some support. > There may also be a few problem domains that demand the maximum performance and lowest resource utilization possible You can approach that with Rust as well. Often you can even do performance improvements better and safer then in C++, because the borrow checker helps you stay safe. Especially CoW is a godsend when processing data.

JoshTriplett 3y ago
> Decent C and C++ developers shouldn't take that long to grasp the borrow-checker. Those that don't can't be trusted coding C or C++ in the first place. Because they don't have a good enough mental model of memory management to deal with it manually. In fairness to C and C++ developers: while often the problem is not understanding memory management, sometimes the problem is understanding it and having a model that doesn't mesh with borrow checking, or having a problem that needs some additional work to map into something easy to write in safe code. For instance, it takes some additional knowledge in Rust to know that if you want to build a graph, you 1) should almost always use an established graph library and not write your own, and 2) if you do need to write your own graph, you either need to use Rc, have an array of nodes and use indices, or use unsafe and raw pointers and provide a nice safe well-tested wrapper. (I'm one of the developers of Rust, and I think it's important to characterize languages fairly.)
- carlmr 3y ago
  I don't disagree with either of your points, but when I learned Rust, those points about borrow-checker vs graphs in the cycle were entirely clear after looking at the first few tutorial lessons on the borrow-checker. Maybe day 2 of learning Rust for me. And coming from C++, Rc is not such a foreign concept compared to smart pointers. Coming from C it might be a bit more of a foreign concept I'll admit.

Cloudef 3y ago

There are few reasons: > Productivity > Readability > Performance > Static binaries > Not needing PhD in rust, especially async rust Rust works fine as high level language but it's absolutely awful for anything else and suffers from C++ feature creep. It would be a much better language if rust wasn't afraid of making `unsafe` an useful tool rather than thing that "everyone expect the core devs should absolutely avoid". Ergonomics would increase tenfolds if you could use it to essentially control the borrow checker better as well instead having to do mega abstractions (which aren't often zero-cost even) or hoops for every single thing. https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ https://zackoverflow.dev/writing/unsafe-rust-vs-zig/