4 ms·

This is a pretty common complaint from people who have used C++ forever and don't want to give up their design patterns when learning a new language. "Not expre

by __jem 4y ago

This is a pretty common complaint from people who have used C++ forever and don't want to give up their design patterns when learning a new language. "Not expressive" is self-serving way to say alternatively "I can't write my OO soup" or "I don't care about safety in my C++ code", which are both evidenced in the OP's comment.

jonstewart 4y ago
I care about safety in my C++ code, thanks. What I'm saying is that all of the boogeyman stories about terrible C++ code generally don't apply to modern C++ if you work within its idioms -- memory corruption bugs are few and far between, and easy to find and fix. I've certainly seen truly awful C++ codebases, full of undefined behavior and stack and heap corruption. It's possible to write very bad unsafe C++ code; it's also possible to write safe C++ code without much difficulty. As far as design patterns: fair point that design patterns and idioms may be different in Rust but... what are they??? Fundamentally, in an application, some parts are going to read some data while another part owns it. How does that work in Rust? I haven't seen good answers yet. With procedural information processing utilities those concerns don't come into play as much, but I'd love to read about the architecture of well-functioning Rust GUI app.
- __jem 4y ago
  > What I'm saying is that all of the boogeyman stories about terrible C++ code generally don't apply to modern C++ if you work within its idioms -- memory corruption bugs are few and far between, and easy to find and fix. I think people are increasingly frustrated by this refrain, because there's empirical evidence that suggests otherwise. Now, it's entirely possible that you are starting greenfield projects with only super senior engineers in domains where a few safety critical bugs just don't matter, and in that case the learning curve required for memory safety just isn't worth it. That's a business decision you can make, and I wouldn't judge for a second. There are always trade-offs in engineering. However, "I don't write bugs" just isn't credible in 2023. I'm sorry if this seems uncharitable, and I appreciate that you're making a more qualified claim, but safety is not a "boogeyman." > I'd love to read about the architecture of well-functioning Rust GUI app. GUI is certainly a still developing area in Rust and has a long way to go. It's easily the weakest part of the ecosystem. That being said, it's still totally possible to build GUIs in Rust. The most common architectural pattern would be the Elm architecture, which avoids many of the issues of ownership that more traditional OO patterns introduce. I've also had a lot of success recently using immediate mode libraries, although obviously this won't work for every application.

by __jem 4y ago

jonstewart 4y ago

I care about safety in my C++ code, thanks. What I'm saying is that all of the boogeyman stories about terrible C++ code generally don't apply to modern C++ if you work within its idioms -- memory corruption bugs are few and far between, and easy to find and fix. I've certainly seen truly awful C++ codebases, full of undefined behavior and stack and heap corruption. It's possible to write very bad unsafe C++ code; it's also possible to write safe C++ code without much difficulty. As far as design patterns: fair point that design patterns and idioms may be different in Rust but... what are they??? Fundamentally, in an application, some parts are going to read some data while another part owns it. How does that work in Rust? I haven't seen good answers yet. With procedural information processing utilities those concerns don't come into play as much, but I'd love to read about the architecture of well-functioning Rust GUI app.

__jem 4y ago
> What I'm saying is that all of the boogeyman stories about terrible C++ code generally don't apply to modern C++ if you work within its idioms -- memory corruption bugs are few and far between, and easy to find and fix. I think people are increasingly frustrated by this refrain, because there's empirical evidence that suggests otherwise. Now, it's entirely possible that you are starting greenfield projects with only super senior engineers in domains where a few safety critical bugs just don't matter, and in that case the learning curve required for memory safety just isn't worth it. That's a business decision you can make, and I wouldn't judge for a second. There are always trade-offs in engineering. However, "I don't write bugs" just isn't credible in 2023. I'm sorry if this seems uncharitable, and I appreciate that you're making a more qualified claim, but safety is not a "boogeyman." > I'd love to read about the architecture of well-functioning Rust GUI app. GUI is certainly a still developing area in Rust and has a long way to go. It's easily the weakest part of the ecosystem. That being said, it's still totally possible to build GUIs in Rust. The most common architectural pattern would be the Elm architecture, which avoids many of the issues of ownership that more traditional OO patterns introduce. I've also had a lot of success recently using immediate mode libraries, although obviously this won't work for every application.