| ▲ | GrantMoyer 11 hours ago |
| While programming in Rust, I've never thought to myself, "man, this would be so much easier to express in C++". I've plenty of times thought the reverse while programming in C++ though. Edit: except when interfacing with C APIs. |
|
| ▲ | kkert 9 hours ago | parent | next [-] |
| This is interesting because i'm writing quite a bit of embedded Rust, and i always run into limitations of very barebones const generics. I always wish they'd have half the expressiveness of C++ constexpr and templates. Win some, lose some though, as the overall development workflow is lightyears ahead of C++, mostly due to tooling |
| |
| ▲ | zozbot234 3 hours ago | parent | next [-] | | Rust generics are not intended as a one-to-one replacement for C++ templates. Most complex cases of template-level programming would be addressed with macros (possibly proc macros) in Rust. | | |
| ▲ | galangalalgol an hour ago | parent [-] | | Const generic expressions are still being worked. They are what is blocking portable simd. They are also a much cleaner way to implement things like matrix operations or really anything where a function with two or more arguments of one or more types returns things that have types that are a combination or modification of the input types. | | |
| ▲ | zozbot234 a few seconds ago | parent [-] | | The problem AIUI is that "const generic expressions" in full generality are as powerful as dependent types. It's not clear to me that the Rust folks will want to open that particular can of worms. |
|
| |
| ▲ | badmintonbaseba 5 hours ago | parent | prev | next [-] | | The expressiveness of const generics (NTTPs) in C++ wouldn't go away if it adopted lifetime annotations and "safe" scopes. It's entirely orthogonal. Rust decided to have more restrictive generic programming, with the benefit of early diagnostic of mistakes in generic code. C++ defers that detection to instantiation, which allows the generics to be more expressive, but it's a tradeoff. But this is an entirely different design decision to lifetime tracking. | |
| ▲ | afdbcreid 7 hours ago | parent | prev [-] | | That's actually quite interesting because this is not an inherent limitation of Rust, and it is definitely planned to be improved. And AFAIK, today (as opposed to last years) it is even being actively worked on! |
|
|
| ▲ | bowsamic 4 hours ago | parent | prev [-] |
| Then you must be avoiding situations that traditionally use OOP |
| |
| ▲ | zozbot234 3 hours ago | parent [-] | | Most kinds of OOP can be expressed idiomatically in Rust. The big exception is implementation inheritance, which is highly discouraged in modern code anyway due to its complex and unintuitive semantics. (Specifically, its reliance on "open recursion", and the related "fragile base class" problem) | | |
| ▲ | galangalalgol 23 minutes ago | parent [-] | | People often say that modern c++ doesn't have the problems needing a solution like rust. Ironically that means people who write modern c++ haven't had any aramp up time needed when joining our rust projects. They were already doing things the right way. At least mostly. But now they don't have to worry about that one person who seems to be trying to trick the static analysis tools on purpose. |
|
|