[cogman10]

> modern C++ is notably more performant than C and by implication Rust

I don't think this holds. Rust has the same facilities which C++ has. Rust's metaprogramming capabilities are now on par with C++ (they weren't always). Rust has a similar generics implementation which allows it to do what C++ does in terms of method dispatch and generation. And now Rust has pretty much the same compile time constant generation capabilities that C++ has.

I don't think there's a part of C++ which isn't in Rust at this point. The only thing potentially missing is the experience and investment using those features.

[spacechild1]

> Rust's metaprogramming capabilities are now on par with C++ (they weren't always).

Is that really true, though? I haven't really written any Rust code, so I have no idea, but I don't think Rust has static reflection. Also, aren't const generics much more limited? I've also heard there is no template specialization and no "if constexpr". Or what about dynamic allocations in constexpr functions?

[cogman10]

> I don't think Rust has static reflection.

Before C++ in fact through procedural macros. You can do everything you can do with C++ static reflection.

Now, it could be better. Proc macros require you to pull in secondary packages for parsing the token stream. But all the sorts of operations you can do via static reflection you can do via proc macros. That's how the most popular rust serialization package like serde works. It's also how some more popular database libs work like sqlx.

> Also, aren't const generics much more limited? I've also heard there is no template specialization and no "if constexpr".

Both have been added and expanded. AFAIK they are now roughly on par with what C++ const expressions can do. What they can't do, proc macros can do.

> Or what about dynamic allocations in constexpr functions?

IDK if that's possible in rust. Const expr capabilities of rust have been rapidly expanding though in the last year.

[spacechild1]

> You can do everything you can do with C++ static reflection.

Are you really sure about that?

I have a slight problem with such sweeping statements and also with your original claim that "Rust's metaprogramming capabilities are now on par with C++". I think you can only make such claims if you know both languages really, really well.

That being said, I acknowledge that Rust's metaprogramming capabilities have improved significantly in recent years.

> Both have been added and expanded.

In stable Rust?

[dwattttt]

It's hard to be concrete without talking about something specific. At the limit, in stable Rust (for 8 years?), a proc_macro consumes and emits an arbitrary token stream at compile time; it's not ergonomic, but it's possible.

The equivalent in C++ is in the realm of arbitrary codegen.

[zamalek]

Last I checked (which was a while ago to be fair), LLVM machine code quality still lagged behind GCC - so things should be slightly more interesting with the GCC back end.

There were also some bugs (hence disabled optimization passes) and missed opportunities from the lack of aliasing Rust precipitates - again, not sure where those sit - and GCC will have to play catch up here (unless there are other languages that exercise this part of the backend).

[pjmlp]

Reflection, Rust community did a very good job driving away the person that cared to do that work, to the point he went back to C and C++ ISO comittees.

Several features on C23 were done thanks to his work.

Also compile time execution is much more rich in C++ than Rust, regardling language features and standard library that can be used at compile time.

Naturally none of the languages is standing still, and they will both improve on that regard.

[cogman10]

I agree. Rust could definitely be more ergonomic and IIRC the main reason it wasn't made that way years ago was because the users of proc macros vetoed the new 2.0 API. IIRC over stilly things like it'd make some of their other crates pointless.