3 ms·

Yes, this matches my experience. It took me almost a year to be as productive (and my code as canonical) in Rust as I was after over two decades of C++. After

Yes, this matches my experience. It took me almost a year to be as productive (and my code as canonical) in Rust as I was after over two decades of C++. After a month of Rust I was still fighting the borrow checker and grokking basic concepts of the language. So no surprise in what you wrote. However, after that year I am probably a factor of two to ten more productive in Rust. The speedup is about two for everyday code (if it compiles it runs and doesn't crash). Ten (or more) when I need to bring in a dependency. To qualify the latter: if a crate with same functionality or a Rust wrapper for a C/C++ lib exists, the factor can be much, much higher than ten since it is just adding a line to Cargo.toml. If the dependency is a C/C++ lib it is as slow as using it from C++. It needs to be integrated with the build and that takes about the same time plus writing/generating a wrapper. All that said: I had to write code in C++ the other day again. It almost felt painful after three years of only Rust.

fooker 4y ago
>It needs to be integrated with the build and that takes about the same time plus writing/generating a wrapper. It's one line of change for any build system..
- virtualritz 4y ago
  > It's one line of change for any build system.. That is simply not true. Lots of build systems assume certain things in certain places and output to be something (what if you want a .so but the build only spits out .a etc.). In any case you may have to resort to shell scrips or launching shell scrips from your own build system. In short: it sucks. And there is also the case when the dependency has dependencies itself. Adding a dependency is one of the biggest PITAs in any C/C++ project. For these reasons: 1. No standardized build system. 2. No standardized use/configuration of common build systems (everyone uses CMake/SCons/whatever slightly differently) 3. Dependencies may have other dependencies, which use yet another build system (see 1. & 2.) This is the reason why 'single header library' is a 'feature' C/C++ devs look out for when deciding on taking on a dependency. It makes adding such 'libraries' as deps a no brainer as far as the above is concerned. I.e. your average Rust crate is to your Rust project as is a single header C/C++ to your C/C++ project. Every other kind of dependency is potential pain.
  - fooker 4y ago
    This is a view of C++ outdated by about 5 years.

fooker 4y ago

>It needs to be integrated with the build and that takes about the same time plus writing/generating a wrapper. It's one line of change for any build system..

virtualritz 4y ago
> It's one line of change for any build system.. That is simply not true. Lots of build systems assume certain things in certain places and output to be something (what if you want a .so but the build only spits out .a etc.). In any case you may have to resort to shell scrips or launching shell scrips from your own build system. In short: it sucks. And there is also the case when the dependency has dependencies itself. Adding a dependency is one of the biggest PITAs in any C/C++ project. For these reasons: 1. No standardized build system. 2. No standardized use/configuration of common build systems (everyone uses CMake/SCons/whatever slightly differently) 3. Dependencies may have other dependencies, which use yet another build system (see 1. & 2.) This is the reason why 'single header library' is a 'feature' C/C++ devs look out for when deciding on taking on a dependency. It makes adding such 'libraries' as deps a no brainer as far as the above is concerned. I.e. your average Rust crate is to your Rust project as is a single header C/C++ to your C/C++ project. Every other kind of dependency is potential pain.
- fooker 4y ago
  This is a view of C++ outdated by about 5 years.