4 ms·

In many ways the '++' in 'C++' comes from giving the compiler more information to work with. You can opt to trust the compiler much more than in C, and the idea

In many ways the '++' in 'C++' comes from giving the compiler more information to work with. You can opt to trust the compiler much more than in C, and the idea is that you gain time at develop-time and hopefully run-time with the tradeoff of losing it at compile-time. At least, that's how I've usually understood it. And the example you mention seems like a complaint with C++20's Ranges in particular. I guess I'd fall into the, "but can't you just ignore the parts you don't like?" camp. This post is written in the context of game engines, but I see a lot of the same 'OG C' arguments made when people in embedded development resist giving C++ a try. We're all writing resource-constrained applications that work on tight time budgets, and none of us feel comfortable throwing up our hands and 'trusting the compiler' in that sort of atmosphere. But C isn't getting any younger, and it's hard to do polymorphism without getting hack-y. Now, who's turn is it to advocate Rust?

swsieber 8y ago
Me! Sort of. Rust is definitely further along the scale towards the end of "giving more to the compiler so it takes longer". I usually like the trade. Most of the time.
- adrianN 8y ago
  Rust also has a saner module system that makes incremental builds much quicker. They're still pretty slow, but not as agonizingly slow as a clean build.
  - nicoburns 8y ago
    Rust is only fast compared to C++ (and then only sometimes). Literally every other language is significantly faster to compile. I'm hoping this can change though. Rust with fast compile times and a more complete library ecosystem (and ideally better IDE support) would be an incredibly productive language.
    - dzdt 8y ago
      Scala is slower to compile than C++ in large scale enterprise development. (The exception that proves the rule?)
      - aphexairlines 8y ago
        Compared with C++, Scala projects are not slow to compile when you use Gradle multi-project builds (with granular sub-projects) and Gradle build caching.
      - nicoburns 8y ago
        Ah, I forgot about Scala. Someone below mentioned Haskell too (which I haven't used). Still, calling Rust fast seems wrong to me!
  - swsieber 8y ago
    Not as agonizingly slow, but still agonizingly slow. While I do appreciate build speed improvements, saying that it's better than it was isn't a super high bar in terms of user experience. I love Rust, I really do, but it's still incredibly slow. I'm excited for any progress it makes on this front.
    - kodemizer 8y ago
      I think the most promising thing on this front is Cranelift (https://github.com/CraneStation/cranelift https://github.com/CraneStation/cranelift). The idea is that, when cranelift is ready, we might use it for debug builds (but still use LLVM for release builds).
arka2147483647 8y ago
> You can opt to trust the compiler much more than in C, I feel that in modern C++ modern style ”trust the compiler” often means ”leave the programmer out of the loop” I really, really would hate to have to try to debug the ranges example, for example.
blattimwind 8y ago
> At least, that's how I've usually understood it. And the example you mention seems like a complaint with C++20's Ranges in particular. I guess I'd fall into the, "but can't you just ignore the parts you don't like?" camp. The issue is that many libraries (including std/stl) tend to produce long compile times.
SomeHacker44 8y ago
I was an early user of the language in the 80s and early 90s (with for example cfront which compiled to C and later the original g++ and its libg++). > In many ways the '++' in 'C++' comes from giving the compiler more information to work with. This is definitely not the origin of the '++'. I believe the '++' name was literally a play about "one better than C."
lambda 8y ago
Here's an implementation that is equivalent to the modern C++ example (playground link: https://play.rust-lang.org/?version=stable&mode=release&edition=2018 https://play.rust-lang.org/?version=stable&mode=release&edit...): use std::time::SystemTime; fn main() -> Result<(), Box<dyn std::error::Error>> { let t0 = SystemTime::now(); let triples = (1..).flat_map(|z| (1..=z).flat_map(move |x| (x..=z).filter_map(move |y| if x * x + y * y == z * z { Some((x, y, z)) } else { None } ) ) ); for triple in triples.take(100) { println!("{:?}", triple); } let elapsed = t0.elapsed()?; println!( "{}", elapsed.as_secs() as f64 + elapsed.subsec_nanos() as f64 * 1e-9 ); Ok(()) } It takes about .376s to compile in debug mode, about 0.491s in release mode. This was after warming caches; the first run took about 2.071s, of which a large portion was probably loading the compiler and standard library. In debug mode, it runs in 0.047586s, in release mode, 0.002304. I was pleasantly surprised to see this is actually better on the build times and debug build performance, given that those are two often cited sore points in Rust. I would also say that while this is a little bit noisy, it is more readable than the proposed C++20 version. "1.." looks more like a range starting at 1 than "iota(1)" does. There's an actual "if" statement in there. In fact, while Rust doesn't officially have generator/coroutine support yet, it is available in nightly builds for the implementation of async/await. If you use the nightly compiler, enable the unstable features, and wrap an adapter type around Generator that implements Iterator, you can write: let triples = IterGen(|| for z in 1.. { for x in 1..=z { for y in x..=z { if x*x + y*y == z*z { yield (x, y, z) } } } } ); It's expected that at some point in the coming year or so async/await, and probably the underlying Generator feature, will be stabilized, and I presume the standard library will implement the Iterator trait for appropriate types of Generators (though there is some bikeshedding about the details of that). Rust doesn't have generators yet, so this is only really fair to compare to the generator/co_yield example in C++ (which is also proposed but not yet standardized). I'd say Rust's syntax compares favorably to that example; the ranges are more clear than the traditional C-style "for" loops, there's native tuple syntax, and it's just be "yield" instead of "co_yield".

swsieber 8y ago

Me! Sort of. Rust is definitely further along the scale towards the end of "giving more to the compiler so it takes longer". I usually like the trade. Most of the time.

adrianN 8y ago
Rust also has a saner module system that makes incremental builds much quicker. They're still pretty slow, but not as agonizingly slow as a clean build.
- nicoburns 8y ago
  Rust is only fast compared to C++ (and then only sometimes). Literally every other language is significantly faster to compile. I'm hoping this can change though. Rust with fast compile times and a more complete library ecosystem (and ideally better IDE support) would be an incredibly productive language.
  - dzdt 8y ago
    Scala is slower to compile than C++ in large scale enterprise development. (The exception that proves the rule?)
    - aphexairlines 8y ago
      Compared with C++, Scala projects are not slow to compile when you use Gradle multi-project builds (with granular sub-projects) and Gradle build caching.
    - nicoburns 8y ago
      Ah, I forgot about Scala. Someone below mentioned Haskell too (which I haven't used). Still, calling Rust fast seems wrong to me!
- swsieber 8y ago
  Not as agonizingly slow, but still agonizingly slow. While I do appreciate build speed improvements, saying that it's better than it was isn't a super high bar in terms of user experience. I love Rust, I really do, but it's still incredibly slow. I'm excited for any progress it makes on this front.
  - kodemizer 8y ago
    I think the most promising thing on this front is Cranelift (https://github.com/CraneStation/cranelift https://github.com/CraneStation/cranelift). The idea is that, when cranelift is ready, we might use it for debug builds (but still use LLVM for release builds).

arka2147483647 8y ago

> You can opt to trust the compiler much more than in C, I feel that in modern C++ modern style ”trust the compiler” often means ”leave the programmer out of the loop” I really, really would hate to have to try to debug the ranges example, for example.

blattimwind 8y ago

> At least, that's how I've usually understood it. And the example you mention seems like a complaint with C++20's Ranges in particular. I guess I'd fall into the, "but can't you just ignore the parts you don't like?" camp. The issue is that many libraries (including std/stl) tend to produce long compile times.

SomeHacker44 8y ago

I was an early user of the language in the 80s and early 90s (with for example cfront which compiled to C and later the original g++ and its libg++). > In many ways the '++' in 'C++' comes from giving the compiler more information to work with. This is definitely not the origin of the '++'. I believe the '++' name was literally a play about "one better than C."

lambda 8y ago

Here's an implementation that is equivalent to the modern C++ example (playground link: https://play.rust-lang.org/?version=stable&mode=release&edition=2018 https://play.rust-lang.org/?version=stable&mode=release&edit...): use std::time::SystemTime; fn main() -> Result<(), Box<dyn std::error::Error>> { let t0 = SystemTime::now(); let triples = (1..).flat_map(|z| (1..=z).flat_map(move |x| (x..=z).filter_map(move |y| if x * x + y * y == z * z { Some((x, y, z)) } else { None } ) ) ); for triple in triples.take(100) { println!("{:?}", triple); } let elapsed = t0.elapsed()?; println!( "{}", elapsed.as_secs() as f64 + elapsed.subsec_nanos() as f64 * 1e-9 ); Ok(()) } It takes about .376s to compile in debug mode, about 0.491s in release mode. This was after warming caches; the first run took about 2.071s, of which a large portion was probably loading the compiler and standard library. In debug mode, it runs in 0.047586s, in release mode, 0.002304. I was pleasantly surprised to see this is actually better on the build times and debug build performance, given that those are two often cited sore points in Rust. I would also say that while this is a little bit noisy, it is more readable than the proposed C++20 version. "1.." looks more like a range starting at 1 than "iota(1)" does. There's an actual "if" statement in there. In fact, while Rust doesn't officially have generator/coroutine support yet, it is available in nightly builds for the implementation of async/await. If you use the nightly compiler, enable the unstable features, and wrap an adapter type around Generator that implements Iterator, you can write: let triples = IterGen(|| for z in 1.. { for x in 1..=z { for y in x..=z { if x*x + y*y == z*z { yield (x, y, z) } } } } ); It's expected that at some point in the coming year or so async/await, and probably the underlying Generator feature, will be stabilized, and I presume the standard library will implement the Iterator trait for appropriate types of Generators (though there is some bikeshedding about the details of that). Rust doesn't have generators yet, so this is only really fair to compare to the generator/co_yield example in C++ (which is also proposed but not yet standardized). I'd say Rust's syntax compares favorably to that example; the ranges are more clear than the traditional C-style "for" loops, there's native tuple syntax, and it's just be "yield" instead of "co_yield".