5 ms·

This matches my experience. I have been doing compiler development in C++ for about 10 years, lisp before that and a bit of python more recently. We could not

by fooker 4y ago

This matches my experience. I have been doing compiler development in C++ for about 10 years, lisp before that and a bit of python more recently. We could not figure out how to be productive in Rust after starting a greenfield project and sticking to it for a month. Luckily this was not a project which requires incremental updates, we were on the verge of rewriting it in C++.

virtualritz 4y ago
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.
pjmlp 4y ago
Although I like Rust, C++ keeps being my systems language when coding outside Java, .NET and Web. Why? Those ecosystems are built alongside C++ tooling, so no need to add an extra layer of indirection. I already have the safety from those ecosytems, if I am reaching out to C++ is exactly because I need to do some unsafe stuff, or binding libraries that are anyway written in C++.
karmakurtisaani 4y ago
Well if you had 10 yoe with C++, you would certainly not achieve the same level of productivity with Rust for a while. Your point is valid in the sense that you should use the tool that you know if you need results, but it's not great criticism towards Rust.
- fooker 4y ago
  For most languages it takes a few weeks to be reasonably productive. This is not a criticism of Rust, just a trait which needs to be acknowledged if the situation has to be improved.
  - karmakurtisaani 4y ago
    Fair enough.

by fooker 4y ago

virtualritz 4y ago

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.

pjmlp 4y ago

Although I like Rust, C++ keeps being my systems language when coding outside Java, .NET and Web. Why? Those ecosystems are built alongside C++ tooling, so no need to add an extra layer of indirection. I already have the safety from those ecosytems, if I am reaching out to C++ is exactly because I need to do some unsafe stuff, or binding libraries that are anyway written in C++.

karmakurtisaani 4y ago

Well if you had 10 yoe with C++, you would certainly not achieve the same level of productivity with Rust for a while. Your point is valid in the sense that you should use the tool that you know if you need results, but it's not great criticism towards Rust.

fooker 4y ago
For most languages it takes a few weeks to be reasonably productive. This is not a criticism of Rust, just a trait which needs to be acknowledged if the situation has to be improved.
- karmakurtisaani 4y ago
  Fair enough.