7 ms·

At this point I just internally assume that ‘general purpose’ C/C++ codebases that aren’t at least open to the idea of Rust are the “if your code has memory iss

At this point I just internally assume that ‘general purpose’ C/C++ codebases that aren’t at least open to the idea of Rust are the “if your code has memory issues, you’re just an idiot, except for the times that my code has had memory issues” types of C developers. More browser code being written in a language with fewer footguns is always cause for celebration

maccard 4y ago
C and C++ codebases are two very different things. I work on a large c++ project, and our compile times are awful. From my limited experience, moving to rust would absolutely ruin our compile times.
- cschep 4y ago
  I know rust compile times aren't great but.. are they WORSE than C++?? yeesh.
  - maccard 4y ago
    Yeah, they are. The compile times on the toy rust projects I've worked on are in the same region of my work c++ projects.
  - aliqot 4y ago
    In my experience, yes.
  - sli 4y ago
    There are a few things you can do to help it. The Bevy project has a section of their setup documentation that lists a few strategies[0]. In general though it can be relatively pretty slow. [0]: https://bevyengine.org/learn/book/getting-started/setup/#enable-fast-compiles-optional https://bevyengine.org/learn/book/getting-started/setup/#ena...
  - meindnoch 4y ago
    By a wide margin.
  - nequo 4y ago
    Yes. This benchmark was recently posted on HN[1]: https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ [1] https://news.ycombinator.com/item?id=34271293 https://news.ycombinator.com/item?id=34271293
  - bfrog 4y ago
    Frankly it depends, just like in C++, how the code is written. Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.
  - raphlinus 4y ago
    As with most such things, there is considerable nuance to this question. If you're careful with your dependencies and optimizing for compile time, it can be quite good. For example, a clean release build of makepad studio on M1 Max is 8.81s. There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions). There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.
    - maccard 4y ago
      > you're careful with your dependencies and optimizing for compile time, it can be quite good. The same can be said about c++. On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times. > So overall I would say it's definitely a factor, but not necessarily a showstopper. I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
      - raphlinus 4y ago
        Another real world example, and actually quite relevant to the use case of the original article. Tint and naga are both shader compilers, primarily used for compiling WGSL into SPIR-V, MSL, and HLSL so shaders can be used portably. Tint is in C++ and takes 113.6s for a clean compile on M1 Max. Naga, in Rust, is 17s. That includes serde and a bunch of the usual community crates (quote, syn, thiserror, petgraph). Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.
  - pjmlp 4y ago
    It depends on C++ code is written, plus contrary to Rust, most C and C++ shops make heavy use of binary libraries, so they only get to compile what they actually need for the project.
- aliqot 4y ago
  Go compiles near instantly, having used Rust and Go for some time now, and shipped in both, Go is the clear winner if you value being able to iterate quickly.
  - jorvi 4y ago
    They have very different purposes. By your logic, Python is king over Go since Python doesn’t need to compile at all.
    - arthurcolle 4y ago
      Wait until you hear about Python bytecode: https://opensource.com/article/18/4/introduction-python-bytecode https://opensource.com/article/18/4/introduction-python-byte...
      - super_flanker 4y ago
        Python bytecode is interpreted by cpython.
  - bfrog 4y ago
    Maybe? I found Go pretty stifling and ran into corners where I was faced with having to copy/paste a lot, write a code generator, or resort to ditching type safety. None of those options are very satisfying. I know generics are now there so maybe this has changed since I last used it. Good if so! 100kloc go program was fast to compile, but awful to modify. It was amusing to me that often times the answer in Go to avoiding repeating yourself was creating a code generator though, because the language didn't have the native abilities in macros/generics/meta programming itself to do it.
    - aliqot 4y ago
      Look, I'm not trying to start a holy war, I'm just relating my experience of more than just a toe being dipped in. Find the argument somewhere else.
- bfrog 4y ago
  It's not solely about compile times though. If you consider all the debugging time Rust saves you from, I'd guess Rust even with its slower compile time, comes out ahead in terms of productivity. That is after all what this link is telling us. One of the main points made was "speed up development" If it were solely about compile times that wouldn't be a major reason to use Rust here.
  - dralley 4y ago
    Not having spurious race conditions that take days if not weeks to hunt down is quite nice.
    - menaerus 4y ago
      That's not possible at all with the bare-metal languages. I think many people do not understand that race conditions are a direct consequence of the complexity of our CPUs, memory etc. It is not the "flawed" programming language design that allowed them to sneak in but it is because the problem isn't fundamentally solvable. Some languages try to minimize the surface area but it's not for free: there's always a trade-off attached to it. In that sense it is not anymore a bare-metal language.
      - tialaramex 4y ago
        You're thinking of data races, but, (safe) Rust doesn't have data races. You can't write them. In C++ if you write a data race, that's Undefined Behaviour, game over. This difference might be astonishing, but it's a fundamental design choice. The data race requires two things to coincide and in (safe) Rust they can't. You need mutation of a value which isn't synchronised with access to that value. In concurrent C or C++ it's trivial to do this by mistake, you now have a data race and so UB. But you can't write this in safe Rust.
  - maccard 4y ago
    Only a sith deals in absolutes, it's not solely about _anything_. I write multithreaded code every day, and I'm constantly pushing for us modernizing and cleaning up our c++ codebase. Mistakes happen, subtle bugs slip through, but probably 95% of the code I write and features I write don't benefit from the extra checks that rust provides. The 5% that _do_, that's a trade-off, and we need to decide whether it's worth it. In the long tail, yeah there's less bugs of various categories. Is that worth the cost of the rewrite and the productivity hit for 95% of what I do (as someone who would genuinely benefit from having a borrow checked), the answer right now is probably not
ognarb 4y ago
Please don't put C and C++ in the same boat. This are two different languages and while C++ is definitely far from perfect, at least there is a lot of contruct to manage memory in a safer way (smart pointers raii) and usage of void pointers and c-like arrays are heavily discouraged. Obliviously if you can use Rust, it's even better but that's not always the case.
- tptacek 4y ago
  Empirically, if they're not the same boat, they're very similar boats. People made impassioned arguments for the plausibility of memory-safe C, too --- in fact, they still do. But look where the bugs come from, and there's a clear pattern.
  - avgcorrection 4y ago
    Can we please have this argument withoutboats?
    - pvg 4y ago
      it's 'whataboutism' that's forbidden, not whataboatism
deleted 4y ago
[deleted]
IshKebab 4y ago
I generally agree although the article is right about the integration mostly working for small API surfaces. Due to some big differences between the languages (e.g. no move constructors in Rust) doing Rust-C++ FFI is still painful, even with tools to help.
mid-kid 4y ago
Or maybe it's because the tooling's lacking, the support in linux distributions is spotty, some architectures aren't supported, is complex to interoperate and integrate with build systems, or any of the above? There's plenty of reasons one may opt to not to, however valid you may think they are.
- colonwqbang 4y ago
  This is an important point which is often ignored. Rust tooling isn't bad, but compared to C++ and especially C...
  - Ygg2 4y ago
    Rust reuses a lot of C tooling (debugger, valgrind, callgrind, etc.). So...?
  - woodruffw 4y ago
    Am I reading you correctly in saying that C and C++'s tooling is good compared to Rust? My experience in both (10+ years for C and C++ at this point, 3+ for Rust) is the exact opposite; I can't remember the last time a C or C++ build system, test framework, documentation engine made me one tenth as happy and satisfied as `cargo` does.
    - huggingmouth 4y ago
      Depends on what you care about in your tooling.
    - toyg 4y ago
      Depends on what you mean by "good". C/C++ tooling is certainly more plentiful, better-supported, and available on more platforms, than Rust at this point. That's somewhat natural, considering how much older the ecosystem is.
- sanxiyn 4y ago
  Rust is supported in all Debian release architectures. It kinds of has to, it is a build dependency of Firefox (and soon, Linux itself). To be more than a FUD, you should specify which Linux distribution and which architecture. Yes, it was bad in Rust's early days, but not anymore. I speak this as someone who worked to improve Rust support in Linux distributions and across architectures. It is fair to say Swift support in Linux distributions is spotty, as Swift is not packaged in Debian at all, and Swift upstream is developed against its own LLVM fork, which distributions are reluctant to package. I don't think it is fair to say the same to Rust. Rust upstream takes care to support LLVM releases, precisely so that it is easier to package by Linux distributions.
qsdf38100 4y ago
You are basically saying that not abandoning c++ for Rust makes someone a bad developer. Sounds like suprematism to me. Not all programs are as critical and complex as web browsers. Not all code bases have the same security requirements, there are some legit use cases for trading performance or ease versus guaranteed memory safety. And then even Rust is not a guarantee that an application has no vulnerabilities, as memory isn’t everything. So please use rust if it make sense, but please also don’t force it upon every possible c++ software projects.

maccard 4y ago

C and C++ codebases are two very different things. I work on a large c++ project, and our compile times are awful. From my limited experience, moving to rust would absolutely ruin our compile times.

cschep 4y ago
I know rust compile times aren't great but.. are they WORSE than C++?? yeesh.
- maccard 4y ago
  Yeah, they are. The compile times on the toy rust projects I've worked on are in the same region of my work c++ projects.
- aliqot 4y ago
  In my experience, yes.
- sli 4y ago
  There are a few things you can do to help it. The Bevy project has a section of their setup documentation that lists a few strategies[0]. In general though it can be relatively pretty slow. [0]: https://bevyengine.org/learn/book/getting-started/setup/#enable-fast-compiles-optional https://bevyengine.org/learn/book/getting-started/setup/#ena...
- meindnoch 4y ago
  By a wide margin.
- nequo 4y ago
  Yes. This benchmark was recently posted on HN[1]: https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ [1] https://news.ycombinator.com/item?id=34271293 https://news.ycombinator.com/item?id=34271293
- bfrog 4y ago
  Frankly it depends, just like in C++, how the code is written. Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.
- raphlinus 4y ago
  As with most such things, there is considerable nuance to this question. If you're careful with your dependencies and optimizing for compile time, it can be quite good. For example, a clean release build of makepad studio on M1 Max is 8.81s. There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions). There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.
  - maccard 4y ago
    > you're careful with your dependencies and optimizing for compile time, it can be quite good. The same can be said about c++. On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times. > So overall I would say it's definitely a factor, but not necessarily a showstopper. I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
    - raphlinus 4y ago
      Another real world example, and actually quite relevant to the use case of the original article. Tint and naga are both shader compilers, primarily used for compiling WGSL into SPIR-V, MSL, and HLSL so shaders can be used portably. Tint is in C++ and takes 113.6s for a clean compile on M1 Max. Naga, in Rust, is 17s. That includes serde and a bunch of the usual community crates (quote, syn, thiserror, petgraph). Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.
- pjmlp 4y ago
  It depends on C++ code is written, plus contrary to Rust, most C and C++ shops make heavy use of binary libraries, so they only get to compile what they actually need for the project.
aliqot 4y ago
Go compiles near instantly, having used Rust and Go for some time now, and shipped in both, Go is the clear winner if you value being able to iterate quickly.
- jorvi 4y ago
  They have very different purposes. By your logic, Python is king over Go since Python doesn’t need to compile at all.
  - arthurcolle 4y ago
    Wait until you hear about Python bytecode: https://opensource.com/article/18/4/introduction-python-bytecode https://opensource.com/article/18/4/introduction-python-byte...
    - super_flanker 4y ago
      Python bytecode is interpreted by cpython.
- bfrog 4y ago
  Maybe? I found Go pretty stifling and ran into corners where I was faced with having to copy/paste a lot, write a code generator, or resort to ditching type safety. None of those options are very satisfying. I know generics are now there so maybe this has changed since I last used it. Good if so! 100kloc go program was fast to compile, but awful to modify. It was amusing to me that often times the answer in Go to avoiding repeating yourself was creating a code generator though, because the language didn't have the native abilities in macros/generics/meta programming itself to do it.
  - aliqot 4y ago
    Look, I'm not trying to start a holy war, I'm just relating my experience of more than just a toe being dipped in. Find the argument somewhere else.
bfrog 4y ago
It's not solely about compile times though. If you consider all the debugging time Rust saves you from, I'd guess Rust even with its slower compile time, comes out ahead in terms of productivity. That is after all what this link is telling us. One of the main points made was "speed up development" If it were solely about compile times that wouldn't be a major reason to use Rust here.
- dralley 4y ago
  Not having spurious race conditions that take days if not weeks to hunt down is quite nice.
  - menaerus 4y ago
    That's not possible at all with the bare-metal languages. I think many people do not understand that race conditions are a direct consequence of the complexity of our CPUs, memory etc. It is not the "flawed" programming language design that allowed them to sneak in but it is because the problem isn't fundamentally solvable. Some languages try to minimize the surface area but it's not for free: there's always a trade-off attached to it. In that sense it is not anymore a bare-metal language.
    - tialaramex 4y ago
      You're thinking of data races, but, (safe) Rust doesn't have data races. You can't write them. In C++ if you write a data race, that's Undefined Behaviour, game over. This difference might be astonishing, but it's a fundamental design choice. The data race requires two things to coincide and in (safe) Rust they can't. You need mutation of a value which isn't synchronised with access to that value. In concurrent C or C++ it's trivial to do this by mistake, you now have a data race and so UB. But you can't write this in safe Rust.
- maccard 4y ago
  Only a sith deals in absolutes, it's not solely about _anything_. I write multithreaded code every day, and I'm constantly pushing for us modernizing and cleaning up our c++ codebase. Mistakes happen, subtle bugs slip through, but probably 95% of the code I write and features I write don't benefit from the extra checks that rust provides. The 5% that _do_, that's a trade-off, and we need to decide whether it's worth it. In the long tail, yeah there's less bugs of various categories. Is that worth the cost of the rewrite and the productivity hit for 95% of what I do (as someone who would genuinely benefit from having a borrow checked), the answer right now is probably not

ognarb 4y ago

Please don't put C and C++ in the same boat. This are two different languages and while C++ is definitely far from perfect, at least there is a lot of contruct to manage memory in a safer way (smart pointers raii) and usage of void pointers and c-like arrays are heavily discouraged. Obliviously if you can use Rust, it's even better but that's not always the case.

tptacek 4y ago
Empirically, if they're not the same boat, they're very similar boats. People made impassioned arguments for the plausibility of memory-safe C, too --- in fact, they still do. But look where the bugs come from, and there's a clear pattern.
- avgcorrection 4y ago
  Can we please have this argument withoutboats?
  - pvg 4y ago
    it's 'whataboutism' that's forbidden, not whataboatism

deleted 4y ago

[deleted]

IshKebab 4y ago

I generally agree although the article is right about the integration mostly working for small API surfaces. Due to some big differences between the languages (e.g. no move constructors in Rust) doing Rust-C++ FFI is still painful, even with tools to help.

mid-kid 4y ago

Or maybe it's because the tooling's lacking, the support in linux distributions is spotty, some architectures aren't supported, is complex to interoperate and integrate with build systems, or any of the above? There's plenty of reasons one may opt to not to, however valid you may think they are.

colonwqbang 4y ago
This is an important point which is often ignored. Rust tooling isn't bad, but compared to C++ and especially C...
- Ygg2 4y ago
  Rust reuses a lot of C tooling (debugger, valgrind, callgrind, etc.). So...?
- woodruffw 4y ago
  Am I reading you correctly in saying that C and C++'s tooling is good compared to Rust? My experience in both (10+ years for C and C++ at this point, 3+ for Rust) is the exact opposite; I can't remember the last time a C or C++ build system, test framework, documentation engine made me one tenth as happy and satisfied as `cargo` does.
  - huggingmouth 4y ago
    Depends on what you care about in your tooling.
  - toyg 4y ago
    Depends on what you mean by "good". C/C++ tooling is certainly more plentiful, better-supported, and available on more platforms, than Rust at this point. That's somewhat natural, considering how much older the ecosystem is.
sanxiyn 4y ago
Rust is supported in all Debian release architectures. It kinds of has to, it is a build dependency of Firefox (and soon, Linux itself). To be more than a FUD, you should specify which Linux distribution and which architecture. Yes, it was bad in Rust's early days, but not anymore. I speak this as someone who worked to improve Rust support in Linux distributions and across architectures. It is fair to say Swift support in Linux distributions is spotty, as Swift is not packaged in Debian at all, and Swift upstream is developed against its own LLVM fork, which distributions are reluctant to package. I don't think it is fair to say the same to Rust. Rust upstream takes care to support LLVM releases, precisely so that it is easier to package by Linux distributions.

qsdf38100 4y ago

You are basically saying that not abandoning c++ for Rust makes someone a bad developer. Sounds like suprematism to me. Not all programs are as critical and complex as web browsers. Not all code bases have the same security requirements, there are some legit use cases for trading performance or ease versus guaranteed memory safety. And then even Rust is not a guarantee that an application has no vulnerabilities, as memory isn’t everything. So please use rust if it make sense, but please also don’t force it upon every possible c++ software projects.