7 ms·

In my experience (20+ years with C/C++, and about 4 years with Rust), Rust is significantly less complex than C++, while being similarly capable. The extra syn

In my experience (20+ years with C/C++, and about 4 years with Rust), Rust is significantly less complex than C++, while being similarly capable. The extra syntax that throws off so many C++ devs is almost exclusively about data types and lifetimes, which I find very useful for understanding my own code and others', and which I wish I had in C++.

wewewedxfgdf 9mo ago
The real answer should have been a new language that has memory safety without all the extra conceptual changes and orthogonal subsystems that Rust brings. The core value of safety did not need the reinvention of everything else with the accompanying complexity and cognitive load. For example Zig which instead of introducing a new metaprogramkming language, it uses...... Zig - imagine using the same language instead of inventing a new additional language with all the accompanying complexity and cognitive load and problems. Rust is for those who revel in complexity. And traits - traits and extra complexity not needed for safety. And result and option and move by dedfault - none of these things were needed but they all add up to more complexity and unfamiliarity and cognitive load. And when you add it all together and intertwine it you end up with something so unfamiliar that it no longer looks like "ordinary programming" it looks like something from the Cambrian period.
- LexiMax 9mo ago
  As a C++ developer, my experience with learning both Rust and Zig is that they're both good languages, and any reasonably skilled C++ developer could learn either language if they put their mind to it. If you forced me to pick between Zig and Rust for a long-running project though, I'd pick Rust 10/10 times for the simple fact that it has been stable for more than a decade and already has momentum and funding behind it. Zig is a cool language - one that I've actually written more of than Rust - but it hasn't hit 1.0 yet and still has significant churn in both the language and standard library.
  - wewewedxfgdf 9mo ago
    My point is this: Rust is complex. That is not a statement anyone can deny. Unless you're a Rust-bro "hey man I learned it so I’m baffled how you can't see it's super simple ..... etc etc" - often the implication that you're not very smart if you think Rust is complex. Of everything that I have learned about programming, this is the BIGGEST lesson: - complexity is bad, avoid complexity. Complex is not the same as "sophisticated", which implies necessary intricacy. Complex means unneeded unnecessary cognitive load - things made harder than they should be when it could have been avoided - that's complexity. If you are writing complex code then you're writing bad code. And Rust is complex. It is sad that we did not end up with a SIMPLE programming language that solves the memory safety problem. What we needed was Rust-- i.e Rust without all the non-safety related extras that make it different - it's all the non-safety add ons that makes Rust into a Rube Goldberg machine.
    - LexiMax 9mo ago
      > It is sad that we did not end up with a SIMPLE programming language that solves the memory safety problem. I am not a savant by any means, and yet I was able to get up and running with Rust relatively quickly. What Rust isn't is ergonomic, in that Rust gets very annoyed with the ways that one might want to structure their code. Trust me, I got bit by the borrow checker countless times, and it did grate on me. As a result, there are many tasks that I would avoid using Rust for, tasks where both speed and safety aren't critical. But if neither is a priority, the list of alternative languages I can resort to is quite long, much longer than Zig, C++, or C. And in the cases where both are a factor, I would consider being needled by the compiler to be a feature and not a bug.
    - adamnemecek 9mo ago
      > Rust is complex. Compared with what? C++? It is not.
      - wewewedxfgdf 9mo ago
        False equivalence.
- aw1621107 9mo ago
  > The real answer should have been a new language that has memory safety without all the extra conceptual changes and orthogonal subsystems that Rust brings. The core value of safety did not need the reinvention of everything else with the accompanying complexity and cognitive load. What would the minimal set of features be, in your opinion? > For example Zig which instead of introducing a new metaprogramkming language, it uses...... Zig - imagine using the same language instead of inventing a new additional language with all the accompanying complexity and cognitive load and problems. Zig probably isn't the best comparison since Zig doesn't try to achieve the same level of compile-time memory safety guarantees that Rust aims for. For instance, Zig doesn't try to statically prevent use-after-frees or data races. That being said, as with everything it's a question of tradeoffs. Zig's metaprogramming approach is certainly interesting, but from what I understand it doesn't offer the same set of features as Rust's approach. For example: - Zig's generics are more similar to C++ templates in that only instantiated functions are fully checked by the compiler. Rust's generics, on the other hand, are completely checked at the definition site so if the definition type-checks the author knows it will type-check for all possible instantiations. Rust's approach also lends itself to nicer error messages since everything a generic needs is visible up front. - Zig's comptime isn't quite 1:1 with Rust's macros. comptime is for... well, compile-time computation (e.g., reflection, compile-time branching, or instantiating types). Macros are for manipulating syntax (e.g., code generation or adding inline support for other languages). Each has things the other can't do, though to be fair there is overlap in problems they can be used to solve. In any case, metaprogramming approaches are (mostly?) independent of memory safety. > And result and option and move by dedfault - none of these things were needed but they all add up to more complexity and unfamiliarity and cognitive load. I don't think Result/Option are that complex (if at all) since they're trivially derivable from discriminated unions/sum types/enums. I'm also not sure how move by default is necessarily "more complexity... and cognitive load"? Maybe as a result of unfamiliarity, perhaps, but that seems more a property of a person than a language, no?
  - deleted 9mo ago
    [deleted]
  - timschmidt 9mo ago
    There's also https://docs.rs/proc-macro2/latest/proc_macro2/ https://docs.rs/proc-macro2/latest/proc_macro2/ which effectively allows for the construction of procedural macros with normal Rust possible. As well as enable the use of proc_macro types in normal rust. It'll make it to stable someday, I hope.
- timschmidt 9mo ago
  > The real answer should have been a new language that has memory safety without all the extra conceptual changes and orthogonal subsystems that Rust brings. So what you're saying here is that you don't understand that Rust's rules around memory ownership, aliasing, and mutability are what allow the language to provide deterministic compile time memory safety without runtime cost. If you figure out another way to guarantee memory safety at compile time with zero runtime overhead, you should write a paper and start another language around it! https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_RISC_Instructions https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R... exists, and is an exciting, laudable effort, I think. But requires hardware support as well as language modifications.
  - touisteur 9mo ago
    And even if you a runtime solution with no runtime cost, you'd still need to run the code, to find the memory safety bugs. Static analysis is supposed to tell you there is no path that violates memory safety.
- blubber 9mo ago
  Isn't Zig's repetitive ceremonial code around allocators+ allocation + defer *.deinit() a sign of a serious shortcoming like golang's error handling? If zig is so good at metaprogramming, why isn't there a metaprogramming solution to this repetitive code?
  - jordand 9mo ago
    Memory allocations are always done explicitly (nothing is hidden or implicit). I've not written enough Zig yet to appreciate that, but I've hit plenty of those issues year-after-year with C++ to know their approach is sane and rational.
    - Measter 9mo ago
      Memory allocations in Rust are also always done explicitly, but Rust's library types don't have APIs that allow you to get it wrong.
      - vacuity 9mo ago
        Rust doesn't (yet) have the same level of control over allocators as Zig does.
        Measter 9mo ago
        The Rust language has exactly that level of control. Rust's Alloc and STD implementations do not yet provide it.
        vacuity 9mo ago
        That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust. Rust recognizes allocations on a language basis, but does not provide the same level of control over allocations on a language basis as Zig does. For instance, there is no stable interface for custom allocators for alloc/std.
fooker 9mo ago
Great, if you are right everyone is going to be using Rust eventually. I like the concepts proposed by Rust but do not like fighting with the borrow checker or sprinkling code with box, ref, cell, rc, refcell, etc. At some point there’s going to be a better designed language that makes these pain point go away.
- LexiMax 9mo ago
  > Great, if you are right everyone is going to be using Rust eventually. Every task does not need speed and safety. Therefore, "everyone" doesn't need Rust. But I could easily see a future where C++ is relegated to legacy language status. It has already had decades of garbage-collected languages chipping away at most of its general-purpose uses, but Rust seems capable and in a position to take away most of its remaining niches. It's kind of why the old C++ programmer that I am decided to learn Rust in the first place - seemed like a good idea at the time to skate where the puck is heading.
  - fooker 9mo ago
    > But I could easily see a future where C++ is relegated to legacy language status. Yes, agreed. My prediction is that the replacement is a friendly language that makes Rust's ideas ergonomic to use.
    - adgjlsfhk1 9mo ago
      this seems somewhat unlikely to me. My guess is that we'll see a continued split where Rust takes the low level like OS kernels and cryptography that need time consistency and adversarial security guarantees, while most higher level programs (apps/databases etc) are written in fast garage collected languages (e.g C#/Julia).
      - fooker 9mo ago
        > this seems somewhat unlikely to me. Rust is literally the fast stab at making a memory safe systems language. Do you really think we are never going to be able to design a better one?
avadodin 9mo ago
C% agree. Rust is better than C++.
tialaramex 9mo ago
Some of this is just knowing from experience, by the time C++ programmers knew they wanted the destructive move assignment semantic at the turn of the century they already had large codebases which relied on C++ copy assignment, so, too bad. It took a significant extra effort to land C++ 11 move semantics, which are still less useful but also have worse ergonomics. Whereas Rust knew it wanted the destructive move so, that's just how everything works in Rust. But there are a bunch of unforced errors in C++ design beyond that. Default implicit conversion is a choice and a mistake. Multiple inheritance is a mistake, Stroustrup even says he did it because it was easy, which is exactly the same cause as Hoare's NULL. Choosing "All correct programs compile" (the other option was "No incorrect programs compile", you can't have both, see Henry Rice's PhD thesis) was a mistake. My favourite bad default in C++ is atomic memory ordering. The nasty trick here was that picking a default was the mistake, it's not that they picked the wrong one but that they picked a default at all. C++ programmers end up writing code which doesn't specify the ordering even though the ordering was their only important decision.
- fooker 9mo ago
  > Choosing "All correct programs compile" (the other option was "No incorrect programs compile", you can't have both … This is really the important distinction between C++ and Rust. In my opinion, it seems easier to complement the former to catch issues afterwards (like this article) than it is to design a language that does not require you to jump through hoops to get something correct to compile. I hope programming language design progresses to a state that makes my point invalid, but the “bro rust is easier than C++” gaslighting culture does not help.
  - ahartmetz 9mo ago
    I'm quite experienced at C++ and not that experienced in Rust... but I believe that writing correct Rust is easier than writing correct C++. People get C++ to compile alright, but it often has problems at runtime. You need to know what you are doing in both, but C++ allows you to compile with certain classes of bugs anyway. Even experts still occasionally introduce bugs in C++ that Rust wouldn't allow.
_zagj 9mo ago
> In my experience (20+ years with C/C++, and about 4 years with Rust), Rust is significantly less complex than C++, while being similarly capable OK, what about if you have an existing code base of hundreds of thousands, or even millions, of lines of C or C++? Still think it's going to be better, and especially cheaper, to "rewrite it in Rust" instead of just porting it to Fil-C or something similar?
- timschmidt 9mo ago
  Oh I'm all for pragmatism. I think Fil-C is great in that regard. For shoring up legacy code and maybe even for new projects if you're a C/C++ shop and velocity is important and you can eat the performance and memory costs. I've also written some bindings for C/C++ in Rust and it couldn't have been simpler. bindgen is amazing. So with the experience I have today, I wouldn't hesitate to start rewriting portions of a C/C++ project in Rust where it made sense. And keep the thing building before, during, and after. I'm currently in process on a rewrite of the RepRap.org stack I helped write 20 years ago in C++ and avr-c++, Python, OpenSCAD, and other languages to idiomatic Rust in order to reduce the number of languages involved, support building a fast wasm user interface, build the interface and firmware in the same language and share types across the boundary, explore GPU compute, enable multithreading of interface and firmware, and explore async firmware architecture. And I'm enjoying it a lot. Compared to writing it the first time, I am spending zero time fighting build systems, able to reuse much more code from libraries much easier, and have been able to delve deeper into complex issues like advanced numerical representations, ensuring algorithmic determinism under all possible cases, and the implementations of vector math library which is the foundation of much of the code. Even egui, the UI toolkit I've been using, seems simpler and easier to work with than QT or GTK or anything I've worked with save FLTK which was dead simple. I've really enjoyed Rust for all that. I have the sense, after working with rust, that I am much less likely to get myself into trouble with it than with C++, and much more likely to know where that might happen. Past some point, my big C++ projects got big enough that it got difficult to hold a coherent picture of the whole thing at runtime in your head all at once, to understand it's behavior. That point seems to be farther out, for me, in Rust. The most challenging thing about the rewrite has been chasing down all the little bits of state hidden away in various C++ functions, and normalizing all that into one of a few architectures which work well with Rust's borrowing rules. But the process of doing so consists entirely of things which are best-practice anyway, and the resulting code is definitely easier to read and understand to my eye. These are just observations from my position, as a person with a big legacy C++ codebase, currently rewriting in Rust. And occasionally working in other languages, of course. I have lots of projects.

wewewedxfgdf 9mo ago

The real answer should have been a new language that has memory safety without all the extra conceptual changes and orthogonal subsystems that Rust brings. The core value of safety did not need the reinvention of everything else with the accompanying complexity and cognitive load. For example Zig which instead of introducing a new metaprogramkming language, it uses...... Zig - imagine using the same language instead of inventing a new additional language with all the accompanying complexity and cognitive load and problems. Rust is for those who revel in complexity. And traits - traits and extra complexity not needed for safety. And result and option and move by dedfault - none of these things were needed but they all add up to more complexity and unfamiliarity and cognitive load. And when you add it all together and intertwine it you end up with something so unfamiliar that it no longer looks like "ordinary programming" it looks like something from the Cambrian period.

LexiMax 9mo ago
As a C++ developer, my experience with learning both Rust and Zig is that they're both good languages, and any reasonably skilled C++ developer could learn either language if they put their mind to it. If you forced me to pick between Zig and Rust for a long-running project though, I'd pick Rust 10/10 times for the simple fact that it has been stable for more than a decade and already has momentum and funding behind it. Zig is a cool language - one that I've actually written more of than Rust - but it hasn't hit 1.0 yet and still has significant churn in both the language and standard library.
- wewewedxfgdf 9mo ago
  My point is this: Rust is complex. That is not a statement anyone can deny. Unless you're a Rust-bro "hey man I learned it so I’m baffled how you can't see it's super simple ..... etc etc" - often the implication that you're not very smart if you think Rust is complex. Of everything that I have learned about programming, this is the BIGGEST lesson: - complexity is bad, avoid complexity. Complex is not the same as "sophisticated", which implies necessary intricacy. Complex means unneeded unnecessary cognitive load - things made harder than they should be when it could have been avoided - that's complexity. If you are writing complex code then you're writing bad code. And Rust is complex. It is sad that we did not end up with a SIMPLE programming language that solves the memory safety problem. What we needed was Rust-- i.e Rust without all the non-safety related extras that make it different - it's all the non-safety add ons that makes Rust into a Rube Goldberg machine.
  - LexiMax 9mo ago
    > It is sad that we did not end up with a SIMPLE programming language that solves the memory safety problem. I am not a savant by any means, and yet I was able to get up and running with Rust relatively quickly. What Rust isn't is ergonomic, in that Rust gets very annoyed with the ways that one might want to structure their code. Trust me, I got bit by the borrow checker countless times, and it did grate on me. As a result, there are many tasks that I would avoid using Rust for, tasks where both speed and safety aren't critical. But if neither is a priority, the list of alternative languages I can resort to is quite long, much longer than Zig, C++, or C. And in the cases where both are a factor, I would consider being needled by the compiler to be a feature and not a bug.
  - adamnemecek 9mo ago
    > Rust is complex. Compared with what? C++? It is not.
    - wewewedxfgdf 9mo ago
      False equivalence.
aw1621107 9mo ago
> The real answer should have been a new language that has memory safety without all the extra conceptual changes and orthogonal subsystems that Rust brings. The core value of safety did not need the reinvention of everything else with the accompanying complexity and cognitive load. What would the minimal set of features be, in your opinion? > For example Zig which instead of introducing a new metaprogramkming language, it uses...... Zig - imagine using the same language instead of inventing a new additional language with all the accompanying complexity and cognitive load and problems. Zig probably isn't the best comparison since Zig doesn't try to achieve the same level of compile-time memory safety guarantees that Rust aims for. For instance, Zig doesn't try to statically prevent use-after-frees or data races. That being said, as with everything it's a question of tradeoffs. Zig's metaprogramming approach is certainly interesting, but from what I understand it doesn't offer the same set of features as Rust's approach. For example: - Zig's generics are more similar to C++ templates in that only instantiated functions are fully checked by the compiler. Rust's generics, on the other hand, are completely checked at the definition site so if the definition type-checks the author knows it will type-check for all possible instantiations. Rust's approach also lends itself to nicer error messages since everything a generic needs is visible up front. - Zig's comptime isn't quite 1:1 with Rust's macros. comptime is for... well, compile-time computation (e.g., reflection, compile-time branching, or instantiating types). Macros are for manipulating syntax (e.g., code generation or adding inline support for other languages). Each has things the other can't do, though to be fair there is overlap in problems they can be used to solve. In any case, metaprogramming approaches are (mostly?) independent of memory safety. > And result and option and move by dedfault - none of these things were needed but they all add up to more complexity and unfamiliarity and cognitive load. I don't think Result/Option are that complex (if at all) since they're trivially derivable from discriminated unions/sum types/enums. I'm also not sure how move by default is necessarily "more complexity... and cognitive load"? Maybe as a result of unfamiliarity, perhaps, but that seems more a property of a person than a language, no?
- deleted 9mo ago
  [deleted]
- timschmidt 9mo ago
  There's also https://docs.rs/proc-macro2/latest/proc_macro2/ https://docs.rs/proc-macro2/latest/proc_macro2/ which effectively allows for the construction of procedural macros with normal Rust possible. As well as enable the use of proc_macro types in normal rust. It'll make it to stable someday, I hope.
timschmidt 9mo ago
> The real answer should have been a new language that has memory safety without all the extra conceptual changes and orthogonal subsystems that Rust brings. So what you're saying here is that you don't understand that Rust's rules around memory ownership, aliasing, and mutability are what allow the language to provide deterministic compile time memory safety without runtime cost. If you figure out another way to guarantee memory safety at compile time with zero runtime overhead, you should write a paper and start another language around it! https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_RISC_Instructions https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R... exists, and is an exciting, laudable effort, I think. But requires hardware support as well as language modifications.
- touisteur 9mo ago
  And even if you a runtime solution with no runtime cost, you'd still need to run the code, to find the memory safety bugs. Static analysis is supposed to tell you there is no path that violates memory safety.
blubber 9mo ago
Isn't Zig's repetitive ceremonial code around allocators+ allocation + defer *.deinit() a sign of a serious shortcoming like golang's error handling? If zig is so good at metaprogramming, why isn't there a metaprogramming solution to this repetitive code?
- jordand 9mo ago
  Memory allocations are always done explicitly (nothing is hidden or implicit). I've not written enough Zig yet to appreciate that, but I've hit plenty of those issues year-after-year with C++ to know their approach is sane and rational.
  - Measter 9mo ago
    Memory allocations in Rust are also always done explicitly, but Rust's library types don't have APIs that allow you to get it wrong.
    - vacuity 9mo ago
      Rust doesn't (yet) have the same level of control over allocators as Zig does.
      - Measter 9mo ago
        The Rust language has exactly that level of control. Rust's Alloc and STD implementations do not yet provide it.
        vacuity 9mo ago
        That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust. Rust recognizes allocations on a language basis, but does not provide the same level of control over allocations on a language basis as Zig does. For instance, there is no stable interface for custom allocators for alloc/std.

fooker 9mo ago

Great, if you are right everyone is going to be using Rust eventually. I like the concepts proposed by Rust but do not like fighting with the borrow checker or sprinkling code with box, ref, cell, rc, refcell, etc. At some point there’s going to be a better designed language that makes these pain point go away.

LexiMax 9mo ago
> Great, if you are right everyone is going to be using Rust eventually. Every task does not need speed and safety. Therefore, "everyone" doesn't need Rust. But I could easily see a future where C++ is relegated to legacy language status. It has already had decades of garbage-collected languages chipping away at most of its general-purpose uses, but Rust seems capable and in a position to take away most of its remaining niches. It's kind of why the old C++ programmer that I am decided to learn Rust in the first place - seemed like a good idea at the time to skate where the puck is heading.
- fooker 9mo ago
  > But I could easily see a future where C++ is relegated to legacy language status. Yes, agreed. My prediction is that the replacement is a friendly language that makes Rust's ideas ergonomic to use.
  - adgjlsfhk1 9mo ago
    this seems somewhat unlikely to me. My guess is that we'll see a continued split where Rust takes the low level like OS kernels and cryptography that need time consistency and adversarial security guarantees, while most higher level programs (apps/databases etc) are written in fast garage collected languages (e.g C#/Julia).
    - fooker 9mo ago
      > this seems somewhat unlikely to me. Rust is literally the fast stab at making a memory safe systems language. Do you really think we are never going to be able to design a better one?

avadodin 9mo ago

C% agree. Rust is better than C++.

tialaramex 9mo ago

Some of this is just knowing from experience, by the time C++ programmers knew they wanted the destructive move assignment semantic at the turn of the century they already had large codebases which relied on C++ copy assignment, so, too bad. It took a significant extra effort to land C++ 11 move semantics, which are still less useful but also have worse ergonomics. Whereas Rust knew it wanted the destructive move so, that's just how everything works in Rust. But there are a bunch of unforced errors in C++ design beyond that. Default implicit conversion is a choice and a mistake. Multiple inheritance is a mistake, Stroustrup even says he did it because it was easy, which is exactly the same cause as Hoare's NULL. Choosing "All correct programs compile" (the other option was "No incorrect programs compile", you can't have both, see Henry Rice's PhD thesis) was a mistake. My favourite bad default in C++ is atomic memory ordering. The nasty trick here was that picking a default was the mistake, it's not that they picked the wrong one but that they picked a default at all. C++ programmers end up writing code which doesn't specify the ordering even though the ordering was their only important decision.

fooker 9mo ago
> Choosing "All correct programs compile" (the other option was "No incorrect programs compile", you can't have both … This is really the important distinction between C++ and Rust. In my opinion, it seems easier to complement the former to catch issues afterwards (like this article) than it is to design a language that does not require you to jump through hoops to get something correct to compile. I hope programming language design progresses to a state that makes my point invalid, but the “bro rust is easier than C++” gaslighting culture does not help.
- ahartmetz 9mo ago
  I'm quite experienced at C++ and not that experienced in Rust... but I believe that writing correct Rust is easier than writing correct C++. People get C++ to compile alright, but it often has problems at runtime. You need to know what you are doing in both, but C++ allows you to compile with certain classes of bugs anyway. Even experts still occasionally introduce bugs in C++ that Rust wouldn't allow.

_zagj 9mo ago

> In my experience (20+ years with C/C++, and about 4 years with Rust), Rust is significantly less complex than C++, while being similarly capable OK, what about if you have an existing code base of hundreds of thousands, or even millions, of lines of C or C++? Still think it's going to be better, and especially cheaper, to "rewrite it in Rust" instead of just porting it to Fil-C or something similar?

timschmidt 9mo ago
Oh I'm all for pragmatism. I think Fil-C is great in that regard. For shoring up legacy code and maybe even for new projects if you're a C/C++ shop and velocity is important and you can eat the performance and memory costs. I've also written some bindings for C/C++ in Rust and it couldn't have been simpler. bindgen is amazing. So with the experience I have today, I wouldn't hesitate to start rewriting portions of a C/C++ project in Rust where it made sense. And keep the thing building before, during, and after. I'm currently in process on a rewrite of the RepRap.org stack I helped write 20 years ago in C++ and avr-c++, Python, OpenSCAD, and other languages to idiomatic Rust in order to reduce the number of languages involved, support building a fast wasm user interface, build the interface and firmware in the same language and share types across the boundary, explore GPU compute, enable multithreading of interface and firmware, and explore async firmware architecture. And I'm enjoying it a lot. Compared to writing it the first time, I am spending zero time fighting build systems, able to reuse much more code from libraries much easier, and have been able to delve deeper into complex issues like advanced numerical representations, ensuring algorithmic determinism under all possible cases, and the implementations of vector math library which is the foundation of much of the code. Even egui, the UI toolkit I've been using, seems simpler and easier to work with than QT or GTK or anything I've worked with save FLTK which was dead simple. I've really enjoyed Rust for all that. I have the sense, after working with rust, that I am much less likely to get myself into trouble with it than with C++, and much more likely to know where that might happen. Past some point, my big C++ projects got big enough that it got difficult to hold a coherent picture of the whole thing at runtime in your head all at once, to understand it's behavior. That point seems to be farther out, for me, in Rust. The most challenging thing about the rewrite has been chasing down all the little bits of state hidden away in various C++ functions, and normalizing all that into one of a few architectures which work well with Rust's borrowing rules. But the process of doing so consists entirely of things which are best-practice anyway, and the resulting code is definitely easier to read and understand to my eye. These are just observations from my position, as a person with a big legacy C++ codebase, currently rewriting in Rust. And occasionally working in other languages, of course. I have lots of projects.