5 ms·

I agree, but again that's for new code. Many times you'd be going in to an existing codebase like he mentioned. Especially in the areas he mentioned like Financ

by 0xCMP 11y ago

I agree, but again that's for new code. Many times you'd be going in to an existing codebase like he mentioned. Especially in the areas he mentioned like Financials, HPC, or Compilers. You might get away with Games because even though the engines are reused the code is mostly written to be thrown away to make it faster.

vvanders 11y ago
Yup, that's why I say 2-3 years. It's going to take some time. I also think there's some interesting work to be done w/ language integration so you can drop Rust into Java/C#/Ruby/etc. I think this is actually the best way to drive adoption since you don't need to greenfield it. Tricky part is going to be making sure you preserve the correct lifetime guarantees but I don't think it's insurmountable.
- jlarocco 11y ago
  That sounds incredibly naive. Three years isn't a long time, especially when C++ has a 30 year head start. People put too much emphasis on low level language features when promoting new languages. The pitfalls that Rust solves are known issues in C++, and there are known solutions to them and best practices for avoiding them. A lot of the problems are "solved" as new iterations of the standard come out. To really give C++ a run for its money Rust will have to compete with the gigantic ecosystem around C++. It has libraries for literally everything. It's backed both directly and indirectly by all of the biggest software companies in the world. It's supported by debuggers, profilers, memory profilers, static analyzers, IDEs, refactoring tools, and editors. There are books, tutorials, training classes, etc.
  - enraged_camel 11y ago
    >>The pitfalls that Rust solves are known issues in C++, and there are known solutions to them Known issues and solutions that are known to experienced C++ developers. The article is specifically talking about newcomers.
  - pcwalton 11y ago
    > The pitfalls that Rust solves are known issues in C++, and there are known solutions to them and best practices for avoiding them. A lot of the problems are "solved" as new iterations of the standard come out. What is the known solution for memory safety problems, in particular use after free? (It's not RAII and smart pointers.)
    - chubot 11y ago
      I'm pretty impressed by ASAN (and MSAN, UBSAN, etc.) It catches uses after free trivially, as long as you have unit tests, which I always do. I wonder at the cost of these 2 strategies, for the huge legacy of C/C++ infrastructure we have: 1) refactoring it to be testable, adding unit tests, adding test coverage automation, adding ASAN/MSAN builds, etc. (LLVM is a game changer IMO in addition to C++ 11; things have changed so much in the last 5 years) 2) rewriting it in Rust I'm not claiming anything specific, but #2 seems strictly more expensive, since you still need unit tests for logic bugs anyway (and yes I have written OCaml and get that you can replace control flow with typed data, etc.) #1 also has a straightforward migration path. More to the point, most open source software has TERRIBLE test hygiene. If they don't even have time to write tests, I wonder how they will have time to rewrite in Rust. I'm all for new software in Rust, but I'm thinking about all of Linux user space, web servers, web browsers, every programming language implementation, etc. Also, fuzzing can be combined with ASAN. https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-b... Yes it would be better to know these things statically and not dynamically, and I'm glad that Rust has innovated in this space.
      - pcwalton 11y ago
        ASAN has not been successful at eliminating (sometimes exploitable) use after free bugs in the wild. For example, look at this year's Pwn2Own. All browsers are heavily unit tested, fuzzed, and run through tools like ASAN, in addition to making heavy use of smart pointers, and they all fell to UAF. There is a reasonable argument to be made that memory safety problems don't happen enough to be worth eliminating in practice (though people are often reluctant to make this argument so explicitly). But I don't think it's possible to successfully argue that they can be eliminated at reasonable cost in C++ with the tools we have today.
- JustSomeNobody 11y ago
  2-3 years? Try 10 or 15 or more. Any serious code stick around for a long time.

by 0xCMP 11y ago

vvanders 11y ago

Yup, that's why I say 2-3 years. It's going to take some time. I also think there's some interesting work to be done w/ language integration so you can drop Rust into Java/C#/Ruby/etc. I think this is actually the best way to drive adoption since you don't need to greenfield it. Tricky part is going to be making sure you preserve the correct lifetime guarantees but I don't think it's insurmountable.

jlarocco 11y ago
That sounds incredibly naive. Three years isn't a long time, especially when C++ has a 30 year head start. People put too much emphasis on low level language features when promoting new languages. The pitfalls that Rust solves are known issues in C++, and there are known solutions to them and best practices for avoiding them. A lot of the problems are "solved" as new iterations of the standard come out. To really give C++ a run for its money Rust will have to compete with the gigantic ecosystem around C++. It has libraries for literally everything. It's backed both directly and indirectly by all of the biggest software companies in the world. It's supported by debuggers, profilers, memory profilers, static analyzers, IDEs, refactoring tools, and editors. There are books, tutorials, training classes, etc.
- enraged_camel 11y ago
  >>The pitfalls that Rust solves are known issues in C++, and there are known solutions to them Known issues and solutions that are known to experienced C++ developers. The article is specifically talking about newcomers.
- pcwalton 11y ago
  > The pitfalls that Rust solves are known issues in C++, and there are known solutions to them and best practices for avoiding them. A lot of the problems are "solved" as new iterations of the standard come out. What is the known solution for memory safety problems, in particular use after free? (It's not RAII and smart pointers.)
  - chubot 11y ago
    I'm pretty impressed by ASAN (and MSAN, UBSAN, etc.) It catches uses after free trivially, as long as you have unit tests, which I always do. I wonder at the cost of these 2 strategies, for the huge legacy of C/C++ infrastructure we have: 1) refactoring it to be testable, adding unit tests, adding test coverage automation, adding ASAN/MSAN builds, etc. (LLVM is a game changer IMO in addition to C++ 11; things have changed so much in the last 5 years) 2) rewriting it in Rust I'm not claiming anything specific, but #2 seems strictly more expensive, since you still need unit tests for logic bugs anyway (and yes I have written OCaml and get that you can replace control flow with typed data, etc.) #1 also has a straightforward migration path. More to the point, most open source software has TERRIBLE test hygiene. If they don't even have time to write tests, I wonder how they will have time to rewrite in Rust. I'm all for new software in Rust, but I'm thinking about all of Linux user space, web servers, web browsers, every programming language implementation, etc. Also, fuzzing can be combined with ASAN. https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-b... Yes it would be better to know these things statically and not dynamically, and I'm glad that Rust has innovated in this space.
    - pcwalton 11y ago
      ASAN has not been successful at eliminating (sometimes exploitable) use after free bugs in the wild. For example, look at this year's Pwn2Own. All browsers are heavily unit tested, fuzzed, and run through tools like ASAN, in addition to making heavy use of smart pointers, and they all fell to UAF. There is a reasonable argument to be made that memory safety problems don't happen enough to be worth eliminating in practice (though people are often reluctant to make this argument so explicitly). But I don't think it's possible to successfully argue that they can be eliminated at reasonable cost in C++ with the tools we have today.
JustSomeNobody 11y ago
2-3 years? Try 10 or 15 or more. Any serious code stick around for a long time.