5 ms·

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 Ru

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.
  - jlarocco 11y ago
    For one, compilers usually ship debug stdlibs that will zero out freed memory and freed pointers, so debug builds will seg fault when deallocated memory is accessed. Improving on that, Valgrind can find issues like use after free pretty easily, and even tell you where something's freed and where it's used again. Coverity does a great job on that, too. Coverity can even tell you when you access a pointer or shared pointer without checking if it's non-null. On top of that, handling "raw" pointers and memory has fallen out of favor, and the preference is to use references as much as possible, which are more difficult to use incorrectly. I won't claim any of those solutions are 100%, but they're sufficiently close that few people will jump to a new language over it. In my experience, "real world" C++ programmers don't spend much time fighting memory safety problems.
JustSomeNobody 11y ago
2-3 years? Try 10 or 15 or more. Any serious code stick around for a long time.

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.
- jlarocco 11y ago
  For one, compilers usually ship debug stdlibs that will zero out freed memory and freed pointers, so debug builds will seg fault when deallocated memory is accessed. Improving on that, Valgrind can find issues like use after free pretty easily, and even tell you where something's freed and where it's used again. Coverity does a great job on that, too. Coverity can even tell you when you access a pointer or shared pointer without checking if it's non-null. On top of that, handling "raw" pointers and memory has fallen out of favor, and the preference is to use references as much as possible, which are more difficult to use incorrectly. I won't claim any of those solutions are 100%, but they're sufficiently close that few people will jump to a new language over it. In my experience, "real world" C++ programmers don't spend much time fighting memory safety problems.

JustSomeNobody 11y ago

2-3 years? Try 10 or 15 or more. Any serious code stick around for a long time.