> Should new languages artificially restrict themselves based on the restrictions of their main competitor even if it's possible to serve a wider range of usecases?
Nope - and indeed, we're seeing Rust used in a more diverse set of applications than C++ (e.g. there are several Rust web frontend frameworks, it's a popular WASM language in general, etc)
However, Rust is targeting the same kind of general constraints as C++ for development and deployment, which means it can't add anything that would depend on a runtime or impose an undue burden on users. (Of course, C++ cheats in this regard - RTTI and exceptions - but Rust matches that, and doesn't go beyond.)
> Dynamic can be implemented in a compile-to-native lang.
Requires runtime functionality, and it's not really clear what the resulting semantics would be, anyway: aside from the usual type-safety concerns, how do you deal with lifetimes and other compile-time constraints?
> Contexts with different rules as well.
What kind of different rules? The problem is that any deviation from the rules needs to be reconciled at some point, and that reconciliation has to be watertight: you can't weaken the guarantees somewhere that interacts with safe Rust code, because the weakness you've introduced can spread. This is already a pretty significant issue with unsafe Rust.
Similarly, moving to a higher level of abstraction has similar issues: how do you reconcile the interactions of GC'd objects with the rest of Rust, which expects deterministic destruction and somewhat-predictable object lifetimes?
> Reflection support would likely have overhead which would need a granular opt in mechanism but is very likely possible.
> Similarly many features rust is missing like compile time reflection, field in traits, ...
I'll give you compile-time reflection; that would have been quite nice to have, but the Rust Foundation alienated the primary person with a plan (https://thephd.dev/i-am-no-longer-speaking-at-rustconf-2023), so who knows when we'll see the next proposal? I agree that it's a shame, but there's usually ways to work around it (proc macros can be used to patch over a lot of Rust's relative deficiencies)
In general, the borrow checker is the primary impediment to copying features from other languages; it's just generally non-trivial to fit them into the Rust paradigm without significant R&D. That's why I think a higher-level Rust would have to be a separate language, not an extension of Rust proper: resolving the collision of semantics between abstraction levels is just too difficult in the general case.
Nope - and indeed, we're seeing Rust used in a more diverse set of applications than C++ (e.g. there are several Rust web frontend frameworks, it's a popular WASM language in general, etc)
However, Rust is targeting the same kind of general constraints as C++ for development and deployment, which means it can't add anything that would depend on a runtime or impose an undue burden on users. (Of course, C++ cheats in this regard - RTTI and exceptions - but Rust matches that, and doesn't go beyond.)
> Dynamic can be implemented in a compile-to-native lang.
Requires runtime functionality, and it's not really clear what the resulting semantics would be, anyway: aside from the usual type-safety concerns, how do you deal with lifetimes and other compile-time constraints?
> Contexts with different rules as well.
What kind of different rules? The problem is that any deviation from the rules needs to be reconciled at some point, and that reconciliation has to be watertight: you can't weaken the guarantees somewhere that interacts with safe Rust code, because the weakness you've introduced can spread. This is already a pretty significant issue with unsafe Rust.
Similarly, moving to a higher level of abstraction has similar issues: how do you reconcile the interactions of GC'd objects with the rest of Rust, which expects deterministic destruction and somewhat-predictable object lifetimes?
> Reflection support would likely have overhead which would need a granular opt in mechanism but is very likely possible.
If you're already committing to a granular opt-in mechanism, you might as well use a library, which offers you more options: https://docs.rs/bevy_reflect/latest/bevy_reflect/
> Similarly many features rust is missing like compile time reflection, field in traits, ...
I'll give you compile-time reflection; that would have been quite nice to have, but the Rust Foundation alienated the primary person with a plan (https://thephd.dev/i-am-no-longer-speaking-at-rustconf-2023), so who knows when we'll see the next proposal? I agree that it's a shame, but there's usually ways to work around it (proc macros can be used to patch over a lot of Rust's relative deficiencies)
Field-in-traits has been discussed before, but is complicated due to the borrow checker: https://internals.rust-lang.org/t/fields-in-traits/6933/1
In general, the borrow checker is the primary impediment to copying features from other languages; it's just generally non-trivial to fit them into the Rust paradigm without significant R&D. That's why I think a higher-level Rust would have to be a separate language, not an extension of Rust proper: resolving the collision of semantics between abstraction levels is just too difficult in the general case.