6 ms·

Mostly spot on. That said I can seriously see Rust giving C++ a run for it's money in about 2-3 years. All these things you have to learn the hard way(ownershi

Mostly spot on. That said I can seriously see Rust giving C++ a run for it's money in about 2-3 years. All these things you have to learn the hard way(ownership, move semantics, dangling pointers) are dealt with up-front in Rust. They really aren't bolted on as an afterthought but a core part of the language(std::move I'm looking at you!).

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.
forbidden404 11y ago
I've been looking Rust with good eyes and I want to be using it in my future projects in College. But how easy would it be for developers to "give up" OOP for a more safe and up-front language like Rust? I mean this as a serious question, cause I see C++ being used instead of C thanks to its multi-paradigm capability and I don't know how Rust could fight that for now.
- vvanders 11y ago
  You're not really giving up OOP with Rust, traits give you interface abstraction which is most of what you're getting with C++. As I write more C++ I find myself using less classes and more structs + functions that let me decouple my code and data. If anything I would say Rust is a tad more multi-paradigm due to its really strong functional roots(Sum types!) and nicer treatment of lambdas(no alloc like in std::function).
  - lmitchell 11y ago
    Maybe a bit off-topic, but I just want to clarify - lambdas only include dynamic allocation if you convert them to an std::function, right? I was under the impression that 'auto f = []{...}' did no heap allocation, but converting to an std::function could, depending on the size of the closure.
    - vvanders 11y ago
      Yup your on the mark, it leads to some interesting scenarios where you can't easily refactor code without either introducing template hell or taking the hit for std::function.
    - deleted 11y ago
      [deleted]
- TillE 11y ago
  Rust is currently lacking plenty of "quality of life" features which even C++ has (eg, default parameters). Not to mention a good IDE. I do think it's the first serious contender to eventually replace C++, but it's really not there yet. It's definitely worth trying and learning. I would've ditched C++98 in a heartbeat to move to Rust, but C++ is a pretty exciting and productive place to be ever since C++11.
santaclaus 11y ago
I would love to use Rust more, and have enjoyed working with it on some toy projects, but the last time I looked there wasn't a super solid general purpose math library. Is there anything out there for Rust that is of similar scope to C++'s Eigen or Python's NumPy+SciPy? What about SSE/AVX intrinsics from Rust?
- NotRustAgain 11y ago
  I really wanted to use Rust for numerical/scientific computing tasks, but it's kind of miserable for it. I didn't get hung up on the ownership things that all of the Rust zealots talk about (although I think explicit lifetimes are needlessly complicated). I got hung up trying to implement simple things like complex numbers and matrices in a way that was generic and usable. I'm sure some Rust fanboy will argue that Rust has operator overloading through traits, so I'll challenge anyone to make a workable implementation such that zA and 2.0B works in the following generics: let z = Complex<f64>::new(1.0, 2.0); let A = Matrix<f64>::ident(10, 10); let B : Matrix<Complex<f64>> = z*A; let C : Matrix<Complex<f64>> = 2.0*B; If Rust can't do scalar multiplication or real to complex conversions, it's really not usable for what Eigen or Numpy can do. Try defining the Mul trait generically for those multiplication operators, and you'll see what I mean. (yes, I know there are some syntax errors in the type declarations above - It's my opinion Rust got that wrong too...) Supposedly this kind of thing will eventually be possible with the recent "specialization" changes, but I haven't seen anything that allows operators to work as above... ps: Last I looked, there was fledgling support for SIMD on the horizon... LLVM supports that, so it could happen.
  - pcwalton 11y ago
    This is essentially a complaint that Rust went with strongly-typed generics like every statically-typed, non-C++, non-D language instead of untyped templates like C++ and D. I think that the difficulty of reasoning about template expansion type errors, the complexity of SFINAE, and the consequences for name resolution like ADL make templates not worth the added expressive power for Rust, especially when the features needed to support your use case can be added in the strongly-typed setting eventually.

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.

forbidden404 11y ago

I've been looking Rust with good eyes and I want to be using it in my future projects in College. But how easy would it be for developers to "give up" OOP for a more safe and up-front language like Rust? I mean this as a serious question, cause I see C++ being used instead of C thanks to its multi-paradigm capability and I don't know how Rust could fight that for now.

vvanders 11y ago
You're not really giving up OOP with Rust, traits give you interface abstraction which is most of what you're getting with C++. As I write more C++ I find myself using less classes and more structs + functions that let me decouple my code and data. If anything I would say Rust is a tad more multi-paradigm due to its really strong functional roots(Sum types!) and nicer treatment of lambdas(no alloc like in std::function).
- lmitchell 11y ago
  Maybe a bit off-topic, but I just want to clarify - lambdas only include dynamic allocation if you convert them to an std::function, right? I was under the impression that 'auto f = []{...}' did no heap allocation, but converting to an std::function could, depending on the size of the closure.
  - vvanders 11y ago
    Yup your on the mark, it leads to some interesting scenarios where you can't easily refactor code without either introducing template hell or taking the hit for std::function.
  - deleted 11y ago
    [deleted]
TillE 11y ago
Rust is currently lacking plenty of "quality of life" features which even C++ has (eg, default parameters). Not to mention a good IDE. I do think it's the first serious contender to eventually replace C++, but it's really not there yet. It's definitely worth trying and learning. I would've ditched C++98 in a heartbeat to move to Rust, but C++ is a pretty exciting and productive place to be ever since C++11.

santaclaus 11y ago

I would love to use Rust more, and have enjoyed working with it on some toy projects, but the last time I looked there wasn't a super solid general purpose math library. Is there anything out there for Rust that is of similar scope to C++'s Eigen or Python's NumPy+SciPy? What about SSE/AVX intrinsics from Rust?

NotRustAgain 11y ago
I really wanted to use Rust for numerical/scientific computing tasks, but it's kind of miserable for it. I didn't get hung up on the ownership things that all of the Rust zealots talk about (although I think explicit lifetimes are needlessly complicated). I got hung up trying to implement simple things like complex numbers and matrices in a way that was generic and usable. I'm sure some Rust fanboy will argue that Rust has operator overloading through traits, so I'll challenge anyone to make a workable implementation such that zA and 2.0B works in the following generics: let z = Complex<f64>::new(1.0, 2.0); let A = Matrix<f64>::ident(10, 10); let B : Matrix<Complex<f64>> = z*A; let C : Matrix<Complex<f64>> = 2.0*B; If Rust can't do scalar multiplication or real to complex conversions, it's really not usable for what Eigen or Numpy can do. Try defining the Mul trait generically for those multiplication operators, and you'll see what I mean. (yes, I know there are some syntax errors in the type declarations above - It's my opinion Rust got that wrong too...) Supposedly this kind of thing will eventually be possible with the recent "specialization" changes, but I haven't seen anything that allows operators to work as above... ps: Last I looked, there was fledgling support for SIMD on the horizon... LLVM supports that, so it could happen.
- pcwalton 11y ago
  This is essentially a complaint that Rust went with strongly-typed generics like every statically-typed, non-C++, non-D language instead of untyped templates like C++ and D. I think that the difficulty of reasoning about template expansion type errors, the complexity of SFINAE, and the consequences for name resolution like ADL make templates not worth the added expressive power for Rust, especially when the features needed to support your use case can be added in the strongly-typed setting eventually.