11 ms·

It depends on what they mean by popularity. If they mean % of developers using Rust vs C++ they are wrong. But I teach students both C++ and Rust, and by far Ru

It depends on what they mean by popularity. If they mean % of developers using Rust vs C++ they are wrong. But I teach students both C++ and Rust, and by far Rust is preferred. It’s never even a contest. C++ is long in the tooth, and if you want to talk desperation, C++ is really struggling with its identity now that Rust is on the scene. Before there were some pretty good arguments to use it, but in light of Rust, the best argument for C++ is just that it has a larger ecosystem (which says more about how old C++ is than how good it is as a language). That argument becomes less convincing with each passing day. IMO in 2022 there’s not a good reason to start a new project in C++ unless that’s all you know, or you have some constraint tied to C++.

jnash 5y ago
99.999% of C++ developers either don't care about Rust or has never heard of it. There are 5 million+ C++ developers out there. And the number is going up.
bayindirh 5y ago
> IMO in 2022 there’s not a good reason to start a new project in C++ unless that’s all you know, or you have some constraint tied to C++. I personally don't agree. I can start with performance and continue with a better compiler ecosystem, and add suitability for low resource applications. I'm just not scratching the surface here. Rust is not bad, but it's not a replacement of C++. They aspire to be different things.
- deleted 5y ago
  [deleted]
- School-Cotton 5y ago
  When is C++ higher-performance than Rust?
  - bayindirh 5y ago
    High performance and scientific computing, or more generally when you transfer a lot of data structures via pointers to a lot of threads. In that scenarios, a half second performance difference in main loop can translate to hours in long runs. The code I'm developing is running with ~1.7M iterations/core/second. Every one of these iterations contain another set of 1000 iterations or so (the number is variable, so I don't remember the exact mean, but the total is a lot). Also, this number is on an 8 year old system. More benchmarks are here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - ModernMech 5y ago
      The link you provided shows C++ and Rust both performing best in various benchmarks. Seems like a wash to me, and to the extent one beats the other it's marginal. Which is to be expected because as long as the language is compiled and the compiler is good enough, you should be able to get as much performance out of it as your CPU can handle.
      - bayindirh 5y ago
        The numbers might look small, and indeed for most cases it can be considered a wash, but in some cases, these small differences return as hours. For example, I'm using a lot of vector, matrix and array accesses in my code. A lot of these are copied around for computation. Moving that amount of data will trigger a lot of checks in Rust, and will create a slowdown inevitably.
        ModernMech 5y ago
        Do you have a link to your code that you've benchmarked in C++ and Rust? I'm also doing a lot of vector/matrix/array access in my code, so I'm curious as to what you'd be doing that would cause slow downs to the point that C++ can beat Rust by hours. That would be very enlightening to see.
        5y ago
  - jcelerier 5y ago
    Rust's Vec indexing is bound-checked by default. Just something like this is abysmal for performance (but pretty good for consultants who get called to fix stuff afterwards, so, like, keep them coming!): - Rust: https://rust.godbolt.org/z/GK8WY599o https://rust.godbolt.org/z/GK8WY599o - CPP: https://gcc.godbolt.org/z/qvxzKfv8q https://gcc.godbolt.org/z/qvxzKfv8q
    - School-Cotton 5y ago
      Both languages let you access vector elements with or without bounds checking. Stroustrup even recommends you use .at by default in c++.
    - titzer 5y ago
      > Rust's Vec indexing is bound-checked by default. Just something like this is abysmal for performance Unless you can provide numbers to back this claim up, I'll continue to rely on my measurements that bounds checking (in Virgil) costs anywhere from 0.5% to 3% of performance. It's sometimes more or less in other languages, but it is by far not the reason any programming language has bad performance. I have no reason to suspect that it costs more in Rust, other than misleading microbenchmarks.
      - jcelerier 5y ago
        Here's a quick and dirty example: https://gcc.godbolt.org/z/3WK7eYM4z https://gcc.godbolt.org/z/3WK7eYM4z I observe (-Ofast -march=native -std=c++20 ; CPU is intel 6900k with performance governor on Arch... blasting at 4GHz) : - clang 13: 8.93 ms per iteration - gcc 11: 9.46 ms per iteration so roughly around 9ms. Replacing return mat[r * matrix_size + c]; by return mat.at(r * matrix_size + c); I observe - clang 13: 20.95 ms per iteration - gcc 11: 18.11 ms per iteration so literally more than twice as slow. I also tried with libc++ instead of libstdc++ for clang and the results did not meaningfully change (around 9ms without bound-checking and 21 ms with).
        titzer 5y ago
        From the godbolt link, it looked like most of the vector operations were not getting inlined. You'll need -O2 or higher to have representative results. I could counter by just writing a Virgil program and turning off bounds check with a compiler flag. We could stare at the machine code together; it's literally an additional load, compare, and branch. The Virgil compiler loves eliminating bounds checks when it can. I know your original comment was in the context of the STL, but it really muddies the waters to see huge piles of code get inlined or not depending on compiler flags. Machine code is what matters. Regardless, this is still microbenchmarking. Maybe matrix multiply is an important kernel, but we need to benchmark whole programs. If I turn off bounds checks in a big program like the Virgil compiler, I cannot measure more than about 1.5% performance difference.
  - nivenkos 5y ago
    There's no placement new IIRC so you always build on the stack and copy it to the heap. https://users.rust-lang.org/t/how-to-create-large-objects-directly-in-heap/26405 https://users.rust-lang.org/t/how-to-create-large-objects-di...
    - andrewaylett 5y ago
      I think that's a question of an "insufficiently smart compiler" rather than necessarily something the programmer should be concerned about?
      - Koshkin 5y ago
        The programmer should certainly be concerned about the compiler being insufficiently smart.
      - steveklabnik 5y ago
        No, it is a language semantics issue. You can get the compiler to optimize it away today, if you're careful. But that's a bad user experience. You should be able to specifically request this semantic, and be sure it works.
    - School-Cotton 5y ago
      Fair point.
    - tialaramex 5y ago
      You can do "placement new" (Rust has no new operator, but in this context) unsafely with MaybeUninit -- https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.h... Make a MaybeUninit<Doodad> on the heap, initialise it, and then unsafely assume_init() remembering to write your safety justification ("I initialised this, so it's fine") and get a Doodad, on the heap. The reason it isn't mentioned in that 2019 u.r-l.o post is that MaybeUninit wasn't stabilized until mid-2019.
  - jandrewrogers 5y ago
    I would frame the question more in terms of economy than performance. In theory, I could write a database engine in Rust that is as performant as C++, but it would not make sense to. Making Rust perform the same as C++ in database engines requires marking large portions of the code base as "unsafe", while requiring substantially more lines of code due to being less expressive. Note that this doesn't imply that the code is actually unsafe, just that the Rust compiler cannot reason about the safety of correct and idiomatic code in database engines. And this is why state-of-the-art database engines are still written in C++. There is not much point in using Rust if doing so requires disabling the safety features and writing a lot more code to achieve the same result.
    - pkolaczk 5y ago
      Definitely not my experience with file io and database-related software in rust. Actually two of my publically available programs - fclones and latte - seem to be the most efficient in their respective classes, beating a wide variety of C and C++ programs, yet they contain almost no unsafe code (< 0.1%). The state of the art database engines are written in C++ (and Java) because at the time they were developed Rust didn't exist.
      - jandrewrogers 5y ago
        All high-performance database engines do full kernel bypass -- Linux has standard APIs for this. Databases designed this way are much higher performance, which is people do it. It may not be obvious what this has to do with Rust. The downside of kernel bypass is that the kernel is no longer transparently hiding the relationship between storage, memory, and related low-level hardware mechanics. A consequence of this is that the mutability and lifetime of most objects cannot be evaluated at compile-time, which Rust relies on for its safety model. The hardware can hold mutable references to memory that are not represented in software and which don't understand your object model. How do you manage lifetimes when references to objects are not visible in the code? When an object does not have a fixed address? And so on. This is not trivial even in C++ but the language does allow you to write transparent abstractions that hide this behind something that behaves like a reference without complaining. There are proven models that guarantee safety under these constraints, widely used in database engines. Instead of ownership semantics, they are based on dynamic scheduling semantics. The execution scheduler can dynamically detect unsafe (or other) situations and rewrite the execution schedule to guarantee safety and forward progress without violating other invariants. This is why, as a simple example, some databases never seem to produce deadlocks -- deadlock situations still occur but they are dynamically detected before they occur and are resolved transparently by editing the lock and execution graph. Some major classes of database architecture optimization don't work in garbage collected languages. For this reason, you never see state-of-the-art database engines written in e.g. Java.
  - infamouscow 5y ago
    Rust's lack of fast thread-local storage makes it a non-starter for me. It's really disappointing, especially when the language has incorporated so many other excellent performance improvements like Google's SwissTable and pattern-defeating quicksort. https://github.com/rust-lang/rust/issues/29594 https://github.com/rust-lang/rust/issues/29594 https://matklad.github.io/2020/10/03/fast-thread-locals-in-rust.html https://matklad.github.io/2020/10/03/fast-thread-locals-in-r...
    - roblabla 5y ago
      FWIW, Rust does have fast thread locals, but only in nightly. https://github.com/rust-lang/rust/issues/29594 https://github.com/rust-lang/rust/issues/29594
      - infamouscow 5y ago
        How many companies are running Rust nightly in production?
        roblabla 5y ago
        According to the 2020 Rust Survey[0], a decent amount. The majority is on stable rust, but a bit less than a third of rust users are on nightly. The company I work at uses a pinned nightly rust in order to access some soon-to-be-stabilized features that simplify our life a bit. We update our pinned nightly in lockstep with stable rust releases. In practice, we've almost never had problems with using nightly rust - those are still very well tested, and problems are caught early and fast. The Rust test suite is quite thorough! However, we do try to avoid using features that don't have a clear trajectory towards stabilization, so for us to consider thread_locals, we'd need to have some very solid proof that it would fix some critical performance problems. I suspect every org will have their own policy, and while the majority will use stable rust, it's not like nightly rust is completely unthinkable. [0]: https://blog.rust-lang.org/2020/12/16/rust-survey-2020.html https://blog.rust-lang.org/2020/12/16/rust-survey-2020.html
        5y ago
zozbot234 5y ago
C++ is really struggling with whether or not to break their ABI. But their "identity" is clear enough - much like C, they want to support their existing code, while still opening up support for newer features if possible. Rust could actually benefit from cribbing a few things that are now getting defined in C++, such as their support for heterogenous executors.
- zabzonk 5y ago
  C++ doesn't have a standardised ABI. I'm not aware of any languages that do, but I would be interested in any more information on this.
  - legalcorrection 5y ago
    COM and Windows Runtime (WinRT) provide standardized ABIs across multiple languages. With the WinRT language projections, it's just like writing 'normal' code.
    - pjmlp 5y ago
      And with C++/WinRT you even get back the experience of how it was like to do ATL development.
      - legalcorrection 5y ago
        So I gather that, much more than previous COM projections and templating libraries, C++/WinRT is much nicer to work with. And you can target the WinRT ABI with Rust, .NET (C#, F#, etc.), Python, and JS too.
        pjmlp 5y ago
        I completely disagree, C++/CX was the best that Microsoft ever had closer to C++ Builder and they killed with their office politics. On top of that, the C++/WinRT folks are adamant to push their east const preference into every Microsoft customer. If you enjoy editing IDL files without tooling support and merging generated files by hand, please do.
dan-robertson 5y ago
If you have a very deep understanding of C++ then you are potentially yourself a good reason to start a project in C++ and this statement is true of any language. Knowing the language very well can mean more time focusing on the actual goals and less time messing around with incidental language things. C++ is not sufficiently bad that mastery of it doesn’t trump other concerns for personal projects. Even in companies you are often likely to find more C++ expertise than Rust expertise.
jcelerier 5y ago
Can you point to a Rust alternative to https://doc.qt.io/qt-5/qtreeview.html https://doc.qt.io/qt-5/qtreeview.html ?
- scoutt 5y ago
  Exactly. I think you managed to summarize all my concerns in a single sentence. https://www.areweguiyet.com/ https://www.areweguiyet.com/
- steveklabnik 5y ago
  https://slint-ui.com/ https://slint-ui.com/ is an in-progress one from some ex-Trolltech folks.
  - jcelerier 5y ago
    As much as I have an extreme confidence in the technical ability of the involved folk, even TQTC did not manage to replicate it in an useful enough way so far in QML, and QML has been around for something like 11 years now.
    - steveklabnik 5y ago
      Yeah, I'm certainly not claiming it's equivalent today, I haven't even tried a demo. Just a thing to watch if you're interested in this space.
ilovecaching 5y ago
I don't think you understand just how much of your system and the libraries out there are C/C++. Popularity isn't a measure of entrenchment. C/C++ will likely exist forever because the industry isn't going to rewrite every single piece of the system into Rust. And it isn't like you can just go to one community and ask them to switch. These are huge federations that talk to each other using C/C++ bindings and have hashed out protocols over years and years of board meetings. I think Rust has a place. We can build new things in Rust or replace some things with Rust. But acting like everyone should learn Rust and C/C++ has no value is dangerously ignorant.
- zozbot234 5y ago
  C library bindings can be used directly in Rust, and there are facilities to improve interfacing with C++ as well.
  - pjmlp 5y ago
    Try to use those facilities with CUDA or Unreal.
kllrnohj 5y ago
> C++ is long in the tooth C++ is mature, there's a difference. It's definitely not "long in the tooth" as it still has plenty of modern features & niceties and is getting more all the time. > C++ is really struggling with its identity now that Rust is on the scene C++'s identity struggles have nothing to do with Rust whatsoever. It's struggling to balance ABI & historical compatibility with moving the language forward, that's about it. And that's just something many mature languages face at some point (see Python3 for example). Beyond that struggle of supporting legacy code, there's no identity crisis with C++ at all. > the best argument for C++ is just that it has a larger ecosystem (which says more about how old C++ is than how good it is as a language). That argument becomes less convincing with each passing day. It's still an incredibly convincing argument. Rust has decent C interop, but it's not especially seamless to do safely. But Rust's interop with C++ is rather complicated. So if you have any C++ dependencies, you're almost certainly far better off to just go with C++. Even if you just have C dependencies and someone else hasn't yet made a crate for it, you might still be better of with C++. Particularly since many of the Rust crates that bind to popular C & C++ libraries are not owned or maintained by the library in question. So you're entering into a bit of a sketchy maintenance world. And there's already been churn & abandonware here, for example the various projects (including one from Mozilla/Servo!) to bind to libpng that were then later all abandoned, and you're supposed to migrate to rewrites of PNG support in Rust like LodePNG. This is not ignorable churn & risk. It can be fun, and if it's a hobby project absolutely go for it. But if you're on the clock to ship & maintain something, it's a risk you must consider quite seriously.
- zahllos 5y ago
  I mostly agree. C++ is mature, has standards and a whole array of production ready libraries. If I wanted to build a production cross platform GUI app today and not use electron (vomit) I would likely use Qt for it. Rust has nothing that is quite ready yet to offer there. However, my overall view is that Rust is the right direction. If I had to improve C++, it would look a lot like Rust: move bounds checking and ownership to the compiler not the template compiler, remove classes, introduce traits and make C++ have concepts that don't require me to type every punctuation symbol on my keyboard to use, const by default. Getting the compiler to do some of this checking by default is exactly what I want. If we can have an Ada/Spark style subset via Kani, also done at compile time to check correctness, even better. > It's still an incredibly convincing argument. Rust has decent C interop, but it's not especially seamless to do safely. I would make this statement slightly stronger. If you interop with C code and there are bugs in C code, all bets are off. You don't get any magical protection because your main routine is written in Rust. Cross-language safety, e.g. C++/Javascript, for example, is a very difficult problem. Here's a discussion of C++ and Rust https://dl.acm.org/doi/fullHtml/10.1145/3485832.3485903 https://dl.acm.org/doi/fullHtml/10.1145/3485832.3485903 If you want a tl;dr of that paper, it is that memory corruptions in C or C++ code sharing the address space of safe Rust code can make safe Rust code unsafe too. There have been plenty of attempts to study for example the interactions between browser C++ and the various runtimes a browser hosts. The compact you are making with the Rust compiler when you type 'unsafe' is that you are saying you have verified the correctness of that code: that it is in fact already safe and the compiler should not (probably because it cannot) check it. The same is true of any FFI code you use. However, this is not how many people actually _use_ Rust. Here for example is a 2 year old unfixed segfault in a Rust crate caused by interfacing with non-Rust code: https://rustsec.org/advisories/RUSTSEC-2020-0159 https://rustsec.org/advisories/RUSTSEC-2020-0159. This a) demonstrates the issue and b) demonstrates that random crates pulled off crates.io can contain safety issues for 2+ years with no fix.
pjmlp 5y ago
Those students are up for a surprise when they get to do anything graphics or HPC related.
- aeonik 5y ago
  Can you explain more? I don't have any experience to infer what your comment means.
  - tux3 5y ago
    I think they mean that C++ has a lot of momentum in graphics and HPC. So in their model of the world, students who learn Rust would be surprised that there are people who do not use Rust.
  - pjmlp 5y ago
    HPC is all about C, C++, Fortran, Python (as scripting language), and now Julia is slowly being the new kid in town. Stuff like OpenACC, OpenMP and MPI are expected to be in the box, regardless of the language. On the graphics space, Khronos, NVidia, Intel and AMD are driving the adoption of standard C++ as compute language. NVidia now has many key contributors to ISO C++ on their payroll and as shown at GTC 2022, wants to make CUDA the best GPU implementation of such features. Then on game consoles, C++ is the main language on the SDKs, alongside C# and Unity. One can naturally use other stacks, like Embark Studios is doing with Rust, but then it is on them to spend development resources on making it work, and deal with possible integration issues.
    - scythe 5y ago
      Most of the interfaces you're discussing are more-or-less "purely functional", though. Interop overhead is going to be a lot less when you're squaring a matrix than when you're trying to write an event loop. In fact, most people who use those C++ libraries never touch C++, as you've pointed out yourself: they use Python or (recently) Julia. The ecosystem as it exists is already a hodgepodge of C[++] and Fortran, and while the interop between those might be annoying if you were building a video game, a NumPy user doesn't care if one subroutine is in C++ and the next one is in Fortran. So, I don't see why one more backend language would be a problem, realistically.
DrBazza 5y ago
> But I teach students both C++ and Rust, and by far Rust is preferred. It’s never even a contest. Why is Rust preferred though? Is it "fearless concurrency" (or whatever the old tag line was), a more modern stdlib, or is it Rust's tooling with `cargo` rather the shitty tool-scape of C++'s make/cmake/meson and vcpkg/conan and whatever else.
- e3bc54b2 5y ago
  As a newbie who only learned Java and JS in bootcamp, and C in EE, Rust's tooling is absolutely phenomenal. Things just work, and that is a rare experience.
  - ModernMech 5y ago
    It’s a rare experience but once you’ve had it, anything less becomes unacceptable. Rust has ruined me for so many languages, my bullshit tolerance used to be much higher.
    - pjmlp 5y ago
      Borland languages and IDEs did that to me, that is the minimum bar.
- adwn 5y ago
  > Why is Rust preferred though? Is it "fearless concurrency" Yes. > a more modern stdlib Yes. > is it Rust's tooling with `cargo` rather the shitty tool-scape of C++'s make/cmake/meson and vcpkg/conan and whatever else Yes. I don't mean to be flippant. The entire experience with Rust is just so much better than with C or C++, and that's even before you get to the actual language.
Koshkin 5y ago
> by far Rust is preferred. It’s never even a contest But it is (for the most part) C++ that pays the bills.
- tialaramex 5y ago
  Judging from the same Stack Overflow polling, only by about 3:1 and so we might also say it's really Javascript paying the bills since that's what is most used rather than C++. Just not to write operating systems. If we're thinking about University students it's very likely the ratio is even smaller by the time they graduate and are looking for employment. Rust jobs grow, there are lots of new Rust codebases, and they need maintenance people just the same as C++. You may have fewer mysterious unsafety bugs to fix but your customers still have changing requirements, other people's APIs still change, so you aren't going to go hungry any time soon programming in Rust any more than C++ And if we're talking about in-house training, whatever they are teaching pays the bills, the employer isn't sending employees to learn how to do stuff they've no use for, otherwise they'd just give you indefinite leave on full pay.
  - ncmncm 5y ago
    Wishing is very popular, but makes a poor foundation for argument. Or reputation.
    - tialaramex 5y ago
      Nevertheless, even if you wish it was otherwise, the thing paying the bills for the most people isn't C++ it's Javascript. Brendan Eich's slapped together Lisp clone with semi-colon language syntax is paying the bills more than Bjarne's "What if C but with a kitchen sink of extra stuff bolted on more or less at random?" language. They're both terrible in different ways, but at least Brendan had the excuse of a hard deadline.
      - ncmncm 5y ago
        It would be miraculous if even a single person were paid $1M to code JS. But many get that coding C++.

jnash 5y ago

99.999% of C++ developers either don't care about Rust or has never heard of it. There are 5 million+ C++ developers out there. And the number is going up.

bayindirh 5y ago

> IMO in 2022 there’s not a good reason to start a new project in C++ unless that’s all you know, or you have some constraint tied to C++. I personally don't agree. I can start with performance and continue with a better compiler ecosystem, and add suitability for low resource applications. I'm just not scratching the surface here. Rust is not bad, but it's not a replacement of C++. They aspire to be different things.

deleted 5y ago
[deleted]
School-Cotton 5y ago
When is C++ higher-performance than Rust?
- bayindirh 5y ago
  High performance and scientific computing, or more generally when you transfer a lot of data structures via pointers to a lot of threads. In that scenarios, a half second performance difference in main loop can translate to hours in long runs. The code I'm developing is running with ~1.7M iterations/core/second. Every one of these iterations contain another set of 1000 iterations or so (the number is variable, so I don't remember the exact mean, but the total is a lot). Also, this number is on an 8 year old system. More benchmarks are here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - ModernMech 5y ago
    The link you provided shows C++ and Rust both performing best in various benchmarks. Seems like a wash to me, and to the extent one beats the other it's marginal. Which is to be expected because as long as the language is compiled and the compiler is good enough, you should be able to get as much performance out of it as your CPU can handle.
    - bayindirh 5y ago
      The numbers might look small, and indeed for most cases it can be considered a wash, but in some cases, these small differences return as hours. For example, I'm using a lot of vector, matrix and array accesses in my code. A lot of these are copied around for computation. Moving that amount of data will trigger a lot of checks in Rust, and will create a slowdown inevitably.
      - ModernMech 5y ago
        Do you have a link to your code that you've benchmarked in C++ and Rust? I'm also doing a lot of vector/matrix/array access in my code, so I'm curious as to what you'd be doing that would cause slow downs to the point that C++ can beat Rust by hours. That would be very enlightening to see.
        5y ago
- jcelerier 5y ago
  Rust's Vec indexing is bound-checked by default. Just something like this is abysmal for performance (but pretty good for consultants who get called to fix stuff afterwards, so, like, keep them coming!): - Rust: https://rust.godbolt.org/z/GK8WY599o https://rust.godbolt.org/z/GK8WY599o - CPP: https://gcc.godbolt.org/z/qvxzKfv8q https://gcc.godbolt.org/z/qvxzKfv8q
  - School-Cotton 5y ago
    Both languages let you access vector elements with or without bounds checking. Stroustrup even recommends you use .at by default in c++.
  - titzer 5y ago
    > Rust's Vec indexing is bound-checked by default. Just something like this is abysmal for performance Unless you can provide numbers to back this claim up, I'll continue to rely on my measurements that bounds checking (in Virgil) costs anywhere from 0.5% to 3% of performance. It's sometimes more or less in other languages, but it is by far not the reason any programming language has bad performance. I have no reason to suspect that it costs more in Rust, other than misleading microbenchmarks.
    - jcelerier 5y ago
      Here's a quick and dirty example: https://gcc.godbolt.org/z/3WK7eYM4z https://gcc.godbolt.org/z/3WK7eYM4z I observe (-Ofast -march=native -std=c++20 ; CPU is intel 6900k with performance governor on Arch... blasting at 4GHz) : - clang 13: 8.93 ms per iteration - gcc 11: 9.46 ms per iteration so roughly around 9ms. Replacing return mat[r * matrix_size + c]; by return mat.at(r * matrix_size + c); I observe - clang 13: 20.95 ms per iteration - gcc 11: 18.11 ms per iteration so literally more than twice as slow. I also tried with libc++ instead of libstdc++ for clang and the results did not meaningfully change (around 9ms without bound-checking and 21 ms with).
      - titzer 5y ago
        From the godbolt link, it looked like most of the vector operations were not getting inlined. You'll need -O2 or higher to have representative results. I could counter by just writing a Virgil program and turning off bounds check with a compiler flag. We could stare at the machine code together; it's literally an additional load, compare, and branch. The Virgil compiler loves eliminating bounds checks when it can. I know your original comment was in the context of the STL, but it really muddies the waters to see huge piles of code get inlined or not depending on compiler flags. Machine code is what matters. Regardless, this is still microbenchmarking. Maybe matrix multiply is an important kernel, but we need to benchmark whole programs. If I turn off bounds checks in a big program like the Virgil compiler, I cannot measure more than about 1.5% performance difference.
- nivenkos 5y ago
  There's no placement new IIRC so you always build on the stack and copy it to the heap. https://users.rust-lang.org/t/how-to-create-large-objects-directly-in-heap/26405 https://users.rust-lang.org/t/how-to-create-large-objects-di...
  - andrewaylett 5y ago
    I think that's a question of an "insufficiently smart compiler" rather than necessarily something the programmer should be concerned about?
    - Koshkin 5y ago
      The programmer should certainly be concerned about the compiler being insufficiently smart.
    - steveklabnik 5y ago
      No, it is a language semantics issue. You can get the compiler to optimize it away today, if you're careful. But that's a bad user experience. You should be able to specifically request this semantic, and be sure it works.
  - School-Cotton 5y ago
    Fair point.
  - tialaramex 5y ago
    You can do "placement new" (Rust has no new operator, but in this context) unsafely with MaybeUninit -- https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.h... Make a MaybeUninit<Doodad> on the heap, initialise it, and then unsafely assume_init() remembering to write your safety justification ("I initialised this, so it's fine") and get a Doodad, on the heap. The reason it isn't mentioned in that 2019 u.r-l.o post is that MaybeUninit wasn't stabilized until mid-2019.
- jandrewrogers 5y ago
  I would frame the question more in terms of economy than performance. In theory, I could write a database engine in Rust that is as performant as C++, but it would not make sense to. Making Rust perform the same as C++ in database engines requires marking large portions of the code base as "unsafe", while requiring substantially more lines of code due to being less expressive. Note that this doesn't imply that the code is actually unsafe, just that the Rust compiler cannot reason about the safety of correct and idiomatic code in database engines. And this is why state-of-the-art database engines are still written in C++. There is not much point in using Rust if doing so requires disabling the safety features and writing a lot more code to achieve the same result.
  - pkolaczk 5y ago
    Definitely not my experience with file io and database-related software in rust. Actually two of my publically available programs - fclones and latte - seem to be the most efficient in their respective classes, beating a wide variety of C and C++ programs, yet they contain almost no unsafe code (< 0.1%). The state of the art database engines are written in C++ (and Java) because at the time they were developed Rust didn't exist.
    - jandrewrogers 5y ago
      All high-performance database engines do full kernel bypass -- Linux has standard APIs for this. Databases designed this way are much higher performance, which is people do it. It may not be obvious what this has to do with Rust. The downside of kernel bypass is that the kernel is no longer transparently hiding the relationship between storage, memory, and related low-level hardware mechanics. A consequence of this is that the mutability and lifetime of most objects cannot be evaluated at compile-time, which Rust relies on for its safety model. The hardware can hold mutable references to memory that are not represented in software and which don't understand your object model. How do you manage lifetimes when references to objects are not visible in the code? When an object does not have a fixed address? And so on. This is not trivial even in C++ but the language does allow you to write transparent abstractions that hide this behind something that behaves like a reference without complaining. There are proven models that guarantee safety under these constraints, widely used in database engines. Instead of ownership semantics, they are based on dynamic scheduling semantics. The execution scheduler can dynamically detect unsafe (or other) situations and rewrite the execution schedule to guarantee safety and forward progress without violating other invariants. This is why, as a simple example, some databases never seem to produce deadlocks -- deadlock situations still occur but they are dynamically detected before they occur and are resolved transparently by editing the lock and execution graph. Some major classes of database architecture optimization don't work in garbage collected languages. For this reason, you never see state-of-the-art database engines written in e.g. Java.
- infamouscow 5y ago
  Rust's lack of fast thread-local storage makes it a non-starter for me. It's really disappointing, especially when the language has incorporated so many other excellent performance improvements like Google's SwissTable and pattern-defeating quicksort. https://github.com/rust-lang/rust/issues/29594 https://github.com/rust-lang/rust/issues/29594 https://matklad.github.io/2020/10/03/fast-thread-locals-in-rust.html https://matklad.github.io/2020/10/03/fast-thread-locals-in-r...
  - roblabla 5y ago
    FWIW, Rust does have fast thread locals, but only in nightly. https://github.com/rust-lang/rust/issues/29594 https://github.com/rust-lang/rust/issues/29594
    - infamouscow 5y ago
      How many companies are running Rust nightly in production?
      - roblabla 5y ago
        According to the 2020 Rust Survey[0], a decent amount. The majority is on stable rust, but a bit less than a third of rust users are on nightly. The company I work at uses a pinned nightly rust in order to access some soon-to-be-stabilized features that simplify our life a bit. We update our pinned nightly in lockstep with stable rust releases. In practice, we've almost never had problems with using nightly rust - those are still very well tested, and problems are caught early and fast. The Rust test suite is quite thorough! However, we do try to avoid using features that don't have a clear trajectory towards stabilization, so for us to consider thread_locals, we'd need to have some very solid proof that it would fix some critical performance problems. I suspect every org will have their own policy, and while the majority will use stable rust, it's not like nightly rust is completely unthinkable. [0]: https://blog.rust-lang.org/2020/12/16/rust-survey-2020.html https://blog.rust-lang.org/2020/12/16/rust-survey-2020.html
        5y ago

zozbot234 5y ago

C++ is really struggling with whether or not to break their ABI. But their "identity" is clear enough - much like C, they want to support their existing code, while still opening up support for newer features if possible. Rust could actually benefit from cribbing a few things that are now getting defined in C++, such as their support for heterogenous executors.

zabzonk 5y ago
C++ doesn't have a standardised ABI. I'm not aware of any languages that do, but I would be interested in any more information on this.
- legalcorrection 5y ago
  COM and Windows Runtime (WinRT) provide standardized ABIs across multiple languages. With the WinRT language projections, it's just like writing 'normal' code.
  - pjmlp 5y ago
    And with C++/WinRT you even get back the experience of how it was like to do ATL development.
    - legalcorrection 5y ago
      So I gather that, much more than previous COM projections and templating libraries, C++/WinRT is much nicer to work with. And you can target the WinRT ABI with Rust, .NET (C#, F#, etc.), Python, and JS too.
      - pjmlp 5y ago
        I completely disagree, C++/CX was the best that Microsoft ever had closer to C++ Builder and they killed with their office politics. On top of that, the C++/WinRT folks are adamant to push their east const preference into every Microsoft customer. If you enjoy editing IDL files without tooling support and merging generated files by hand, please do.

dan-robertson 5y ago

If you have a very deep understanding of C++ then you are potentially yourself a good reason to start a project in C++ and this statement is true of any language. Knowing the language very well can mean more time focusing on the actual goals and less time messing around with incidental language things. C++ is not sufficiently bad that mastery of it doesn’t trump other concerns for personal projects. Even in companies you are often likely to find more C++ expertise than Rust expertise.

jcelerier 5y ago

Can you point to a Rust alternative to https://doc.qt.io/qt-5/qtreeview.html https://doc.qt.io/qt-5/qtreeview.html ?

scoutt 5y ago
Exactly. I think you managed to summarize all my concerns in a single sentence. https://www.areweguiyet.com/ https://www.areweguiyet.com/
steveklabnik 5y ago
https://slint-ui.com/ https://slint-ui.com/ is an in-progress one from some ex-Trolltech folks.
- jcelerier 5y ago
  As much as I have an extreme confidence in the technical ability of the involved folk, even TQTC did not manage to replicate it in an useful enough way so far in QML, and QML has been around for something like 11 years now.
  - steveklabnik 5y ago
    Yeah, I'm certainly not claiming it's equivalent today, I haven't even tried a demo. Just a thing to watch if you're interested in this space.

ilovecaching 5y ago

I don't think you understand just how much of your system and the libraries out there are C/C++. Popularity isn't a measure of entrenchment. C/C++ will likely exist forever because the industry isn't going to rewrite every single piece of the system into Rust. And it isn't like you can just go to one community and ask them to switch. These are huge federations that talk to each other using C/C++ bindings and have hashed out protocols over years and years of board meetings. I think Rust has a place. We can build new things in Rust or replace some things with Rust. But acting like everyone should learn Rust and C/C++ has no value is dangerously ignorant.

zozbot234 5y ago
C library bindings can be used directly in Rust, and there are facilities to improve interfacing with C++ as well.
- pjmlp 5y ago
  Try to use those facilities with CUDA or Unreal.

kllrnohj 5y ago

> C++ is long in the tooth C++ is mature, there's a difference. It's definitely not "long in the tooth" as it still has plenty of modern features & niceties and is getting more all the time. > C++ is really struggling with its identity now that Rust is on the scene C++'s identity struggles have nothing to do with Rust whatsoever. It's struggling to balance ABI & historical compatibility with moving the language forward, that's about it. And that's just something many mature languages face at some point (see Python3 for example). Beyond that struggle of supporting legacy code, there's no identity crisis with C++ at all. > the best argument for C++ is just that it has a larger ecosystem (which says more about how old C++ is than how good it is as a language). That argument becomes less convincing with each passing day. It's still an incredibly convincing argument. Rust has decent C interop, but it's not especially seamless to do safely. But Rust's interop with C++ is rather complicated. So if you have any C++ dependencies, you're almost certainly far better off to just go with C++. Even if you just have C dependencies and someone else hasn't yet made a crate for it, you might still be better of with C++. Particularly since many of the Rust crates that bind to popular C & C++ libraries are not owned or maintained by the library in question. So you're entering into a bit of a sketchy maintenance world. And there's already been churn & abandonware here, for example the various projects (including one from Mozilla/Servo!) to bind to libpng that were then later all abandoned, and you're supposed to migrate to rewrites of PNG support in Rust like LodePNG. This is not ignorable churn & risk. It can be fun, and if it's a hobby project absolutely go for it. But if you're on the clock to ship & maintain something, it's a risk you must consider quite seriously.

zahllos 5y ago
I mostly agree. C++ is mature, has standards and a whole array of production ready libraries. If I wanted to build a production cross platform GUI app today and not use electron (vomit) I would likely use Qt for it. Rust has nothing that is quite ready yet to offer there. However, my overall view is that Rust is the right direction. If I had to improve C++, it would look a lot like Rust: move bounds checking and ownership to the compiler not the template compiler, remove classes, introduce traits and make C++ have concepts that don't require me to type every punctuation symbol on my keyboard to use, const by default. Getting the compiler to do some of this checking by default is exactly what I want. If we can have an Ada/Spark style subset via Kani, also done at compile time to check correctness, even better. > It's still an incredibly convincing argument. Rust has decent C interop, but it's not especially seamless to do safely. I would make this statement slightly stronger. If you interop with C code and there are bugs in C code, all bets are off. You don't get any magical protection because your main routine is written in Rust. Cross-language safety, e.g. C++/Javascript, for example, is a very difficult problem. Here's a discussion of C++ and Rust https://dl.acm.org/doi/fullHtml/10.1145/3485832.3485903 https://dl.acm.org/doi/fullHtml/10.1145/3485832.3485903 If you want a tl;dr of that paper, it is that memory corruptions in C or C++ code sharing the address space of safe Rust code can make safe Rust code unsafe too. There have been plenty of attempts to study for example the interactions between browser C++ and the various runtimes a browser hosts. The compact you are making with the Rust compiler when you type 'unsafe' is that you are saying you have verified the correctness of that code: that it is in fact already safe and the compiler should not (probably because it cannot) check it. The same is true of any FFI code you use. However, this is not how many people actually _use_ Rust. Here for example is a 2 year old unfixed segfault in a Rust crate caused by interfacing with non-Rust code: https://rustsec.org/advisories/RUSTSEC-2020-0159 https://rustsec.org/advisories/RUSTSEC-2020-0159. This a) demonstrates the issue and b) demonstrates that random crates pulled off crates.io can contain safety issues for 2+ years with no fix.

pjmlp 5y ago

Those students are up for a surprise when they get to do anything graphics or HPC related.

aeonik 5y ago
Can you explain more? I don't have any experience to infer what your comment means.
- tux3 5y ago
  I think they mean that C++ has a lot of momentum in graphics and HPC. So in their model of the world, students who learn Rust would be surprised that there are people who do not use Rust.
- pjmlp 5y ago
  HPC is all about C, C++, Fortran, Python (as scripting language), and now Julia is slowly being the new kid in town. Stuff like OpenACC, OpenMP and MPI are expected to be in the box, regardless of the language. On the graphics space, Khronos, NVidia, Intel and AMD are driving the adoption of standard C++ as compute language. NVidia now has many key contributors to ISO C++ on their payroll and as shown at GTC 2022, wants to make CUDA the best GPU implementation of such features. Then on game consoles, C++ is the main language on the SDKs, alongside C# and Unity. One can naturally use other stacks, like Embark Studios is doing with Rust, but then it is on them to spend development resources on making it work, and deal with possible integration issues.
  - scythe 5y ago
    Most of the interfaces you're discussing are more-or-less "purely functional", though. Interop overhead is going to be a lot less when you're squaring a matrix than when you're trying to write an event loop. In fact, most people who use those C++ libraries never touch C++, as you've pointed out yourself: they use Python or (recently) Julia. The ecosystem as it exists is already a hodgepodge of C[++] and Fortran, and while the interop between those might be annoying if you were building a video game, a NumPy user doesn't care if one subroutine is in C++ and the next one is in Fortran. So, I don't see why one more backend language would be a problem, realistically.

DrBazza 5y ago

> But I teach students both C++ and Rust, and by far Rust is preferred. It’s never even a contest. Why is Rust preferred though? Is it "fearless concurrency" (or whatever the old tag line was), a more modern stdlib, or is it Rust's tooling with `cargo` rather the shitty tool-scape of C++'s make/cmake/meson and vcpkg/conan and whatever else.

e3bc54b2 5y ago
As a newbie who only learned Java and JS in bootcamp, and C in EE, Rust's tooling is absolutely phenomenal. Things just work, and that is a rare experience.
- ModernMech 5y ago
  It’s a rare experience but once you’ve had it, anything less becomes unacceptable. Rust has ruined me for so many languages, my bullshit tolerance used to be much higher.
  - pjmlp 5y ago
    Borland languages and IDEs did that to me, that is the minimum bar.
adwn 5y ago
> Why is Rust preferred though? Is it "fearless concurrency" Yes. > a more modern stdlib Yes. > is it Rust's tooling with `cargo` rather the shitty tool-scape of C++'s make/cmake/meson and vcpkg/conan and whatever else Yes. I don't mean to be flippant. The entire experience with Rust is just so much better than with C or C++, and that's even before you get to the actual language.

Koshkin 5y ago

> by far Rust is preferred. It’s never even a contest But it is (for the most part) C++ that pays the bills.

tialaramex 5y ago
Judging from the same Stack Overflow polling, only by about 3:1 and so we might also say it's really Javascript paying the bills since that's what is most used rather than C++. Just not to write operating systems. If we're thinking about University students it's very likely the ratio is even smaller by the time they graduate and are looking for employment. Rust jobs grow, there are lots of new Rust codebases, and they need maintenance people just the same as C++. You may have fewer mysterious unsafety bugs to fix but your customers still have changing requirements, other people's APIs still change, so you aren't going to go hungry any time soon programming in Rust any more than C++ And if we're talking about in-house training, whatever they are teaching pays the bills, the employer isn't sending employees to learn how to do stuff they've no use for, otherwise they'd just give you indefinite leave on full pay.
- ncmncm 5y ago
  Wishing is very popular, but makes a poor foundation for argument. Or reputation.
  - tialaramex 5y ago
    Nevertheless, even if you wish it was otherwise, the thing paying the bills for the most people isn't C++ it's Javascript. Brendan Eich's slapped together Lisp clone with semi-colon language syntax is paying the bills more than Bjarne's "What if C but with a kitchen sink of extra stuff bolted on more or less at random?" language. They're both terrible in different ways, but at least Brendan had the excuse of a hard deadline.
    - ncmncm 5y ago
      It would be miraculous if even a single person were paid $1M to code JS. But many get that coding C++.