[tick_tock_tick]

Until Rust has equal meta-programming support to C++ it's always going to be "slower". That's why people always say this because it's always true there is nothing Rust can do C++ can't but there is quite a few things you can do in C++ but not in Rust.

Realistically the difference doesn't matter much and if you're writing code that must be as fast as possible your writing unsafe Rust that looks a lot more like C/C++ then anything Rust.

[josephg]

> Until Rust has equal meta-programming support to C++ it's always going to be "slower".

What metaprogramming does C++ have that rust is lacking?

If you need more than traits + generics, rust also has proc macros. Proc macros are essentially portable compiler extensions. They take in a stream of symbols from the user's program at compile time and emit rust code that gets passed straight to the compiler. You lose out on syntax highlighting and they make compilation slower. But macros are essentially compile-time code gen. They work great. In rust, you can do things like JSX at compile-time without any special compiler support. (See: leptos.)

> Realistically the difference doesn't matter much and if you're writing code that must be as fast as possible your writing unsafe Rust that looks a lot more like C/C++ then anything Rust.

I agree that the difference is small in practice. Good rust often does look a lot like C - with plain structs everywhere and lots of global-ish scoped functions.

But I don't agree about unsafe. I've spent some time porting well optimised code from C to rust. I generally find I need far less unsafe code than I expected. I ported a ~500 line skip list implementation from C to rust a few years ago. I think my rust code ended up using just 2 unsafe functions. The rest of the code didn't need any unsafe at all.

My skip list was a monster to debug in C because most logic bugs ended up corrupting memory. As a result, a bug in one function caused crashes in far away code. In rust, debugging was much easier. There wasn't any "spooky action at a distance". And that let me reason about the code much more easily. As a result, once I got it working I ended up adding a few more optimisations in rust that I was too overwhelmed to write in C. The rust code is now ~2-3x faster.

If you're interested:

https://github.com/josephg/jumprope-rs#benchmarks

C code is here: https://github.com/josephg/librope

[pjmlp]

> What metaprogramming does C++ have that rust is lacking?

Compile time execution, and compile time reflection, with the same syntax.

Proc macros are still a kludge having to depend on syn crate, and some stuff used to depend on nightly, is that still the case, I don't keep track?

Additionally type specialisation, and explicit templates.

[steveklabnik]

Proc macros haven't depended on nightly things in a very, very very long time.

[pjmlp]

Thanks for the update, outside some weekend experiments, or having to compile from source some specific tools, I don't have much reasons to write Rust, thus not keeping that much other than conference talks that pop up on my feeds.

[saghm]

> there is nothing Rust can do C++ can't but there is quite a few things you can do in C++ but not in Rust

The point the parent comment is making is that this doesn't really matter if no one actually does do these things in C++. It's absolutely wild to me how quickly the arguments in favor of C++ instead of Rust have reversed in about a decade; people used to argue that the benefits of Rust were all theoretical and in practice people who were used to C++ could write it perfectly fine without safety issues, and now it's somehow that the theory that gives C++ the advantage and we don't need to care about whether those supposed advantages ever actually exist in practice.

[tialaramex]

> Until Rust has equal meta-programming support to C++ it's always going to be "slower".

I don't think that makes a lot of sense even theoretically because of e.g. aliasing, but it doesn't matter because as I said, C++ chooses to be slower, Titus gives a number of examples where we know how to do X fast, and that's how Rust does X - in theory C++ could X the same way, but none of the three C++ compilers people actually use do it, because they picked wrong and then froze their ABI and won't thaw it.

[tick_tock_tick]

No one writing anything that needs performance cares about some standard library ABI issues. Rust already has warts from bad API designs that constrains performance and they are unlikely to ever be fixed even with new editions. Rust will continue to pick up baggage as basically every language has done.

Aliasing has yet to provide any real benefit for Rust and a hell of a lot of issues. Maybe one day it will be a big win but realistically anyplace that aliasing matter c/c++ will just drop __restrict on it.

[josephg]

> Rust already has warts from bad API designs that constrains performance and they are unlikely to ever be fixed even with new editions.

Like what?

> Aliasing has yet to provide any real benefit for Rust and a hell of a lot of issues.

Yeah, the performance wins so far are quite small. But rust's noalias-by-default did unearth a whole lot of latent bugs in LLVM. Even if you don't care about rust, its great that rust led LLVM to track down and fix these bugs. They affected C/C++ code too.

> realistically anyplace that aliasing matter c/c++ will just drop __restrict on it.

Is there a way to tell? When I'm writing C, I have no idea if using restrict will help other than staring at the assembly. (Or just trying it). I'm also leery of using restrict in C because its so hard to audit callers. How do you know when restrict is safe?

[1718627440]

> When I'm writing C, I have no idea if using restrict will help other than staring at the assembly.

It's also a statement, whether you want callers to pass the same object to different parameters. If that doesn't make sense or you don't want that, write restrict.