5 ms·

I have this opinion. I much prefer C++ to Go and Rust. There need to be languages that don’t hold your hand - you can argue instead that C++ is an incorrect lan

I have this opinion. I much prefer C++ to Go and Rust. There need to be languages that don’t hold your hand - you can argue instead that C++ is an incorrect language choice for many projects and I’d agree with you though Once you understand lifetimes well C++ is a joy to write. 99% of all the complaints about C++ are 1. lack of automatic bounds checking, which is trivial to implement yourself 2. memory management problems because people have a poor mental model of how it works, which can be learned.

Ygg2 4y ago
> Once you understand lifetimes well C++ is a joy to write. Well, so is Rust. You even have usable macros and templates that are't cancer to write.
LeFantome 4y ago
You did not claim that C++ had no problems, just that you prefer it. No fight from me. You should be able to like what you want. While not a shot at your choice, a C++ dev that I follow a bit is the creator of SerenityOS. Many times and in many of his YouTube videos he has sung the praises of C++ and called it his favourite language. Presently, he is writing his own language, Jakt, to replace it. I find that interesting.
colinsane 4y ago
> 99% of all the complaints about C++ are … 2. memory management problems because people have a poor mental model of how it works, which can be learned. or memory management problems because Qt uses a different string type than glib uses a different string type than std, each with different ownership semantics, and by the way some of these claim to be thread-safe while others don’t say clearly one way or the other in the docs, except actually Qt’s copy-on-write implementation claims to be thread safe but assumes that the compiler inlines the mutation operators so if you forward-declare `struct QString` instead of #include <QString> then the operations might not be thread-safe… i think the CoW problem might have been with Qt’s set type, not its string type, but you get the idea. it’s not just the language: it’s the library ecosystem too. it’s that any time i dive into contributing to a new C++ project i have to learn potentially a new memory model, one which is likely assumed instead of documented. RAII presented an opportunity to normalize all this stuff; i’m not sure how significantly it’s unified things: i suspect it’s effective primarily in greenfield projects.
- account42 4y ago
  > Qt uses a different string type than glib uses a different string type than std That is true for any language, even C, so your complaint is with those libraries not the language - and glib isn't even a C++ library at all while Qt is an ancient library that cares more about source-compatibility with its earlier versions than modern C++ (or even any version of C++ with a std::string). > except actually Qt’s copy-on-write implementation claims to be thread safe but assumes that the compiler inlines the mutation operators so if you forward-declare `struct QString` instead of #include <QString> then the operations might not be thread-safe… That doesn't make any sense. How is inlining going to affect thread safety? And (only) forward declaring a type won't let you do any mutations since at that point it's just an opaque name withoutout any known members. > it’s not just the language: it’s the library ecosystem too. And a new language won't fix that - especially when your idea of the library ecosystem for C++ already includes C libraries.
  - colinsane 4y ago
    > glib isn't even a C++ library glibmm i’m sorry that i’m fuzzy on my Qt CoW issue. it was 8 years ago or so, i could probably dig up the ticket about it but the point was that thread-safety is just a thing you’re guessing at whenever you’re using C++. other languages have radically reduced that guesswork. >> it’s not just the language: it’s the library ecosystem too. > And a new language won't fix that - especially when your idea of the library ecosystem for C++ already includes C libraries. that doesn’t match my experience. taking the C++ codebases i’ve contributed to, more use a non-std string type than do. e.g. LMMS uses QString, Stepmania uses its “rage” rstring type. neither of these are small projects, both have download counts in the multi-millions. new languages do address these problems. when i see a project in Rust (or Go, Typescript, …) that i’m thinking of contributing to, i can be fairly confident it’s using the standard String type and that i can come up-to-speed on its memory model instantly — when i see that same project written in C++ i don’t know if it’ll take 10 minutes or 10 hours to understand its memory model, and believe me that uncertainty does impact which projects i choose to contribute to today.
imtringued 4y ago
>memory management problems because people have a poor mental model of how it works, which can be learned. But that has to be learned for each CPP file separately.

Ygg2 4y ago

> Once you understand lifetimes well C++ is a joy to write. Well, so is Rust. You even have usable macros and templates that are't cancer to write.

LeFantome 4y ago

You did not claim that C++ had no problems, just that you prefer it. No fight from me. You should be able to like what you want. While not a shot at your choice, a C++ dev that I follow a bit is the creator of SerenityOS. Many times and in many of his YouTube videos he has sung the praises of C++ and called it his favourite language. Presently, he is writing his own language, Jakt, to replace it. I find that interesting.

colinsane 4y ago

> 99% of all the complaints about C++ are … 2. memory management problems because people have a poor mental model of how it works, which can be learned. or memory management problems because Qt uses a different string type than glib uses a different string type than std, each with different ownership semantics, and by the way some of these claim to be thread-safe while others don’t say clearly one way or the other in the docs, except actually Qt’s copy-on-write implementation claims to be thread safe but assumes that the compiler inlines the mutation operators so if you forward-declare `struct QString` instead of #include <QString> then the operations might not be thread-safe… i think the CoW problem might have been with Qt’s set type, not its string type, but you get the idea. it’s not just the language: it’s the library ecosystem too. it’s that any time i dive into contributing to a new C++ project i have to learn potentially a new memory model, one which is likely assumed instead of documented. RAII presented an opportunity to normalize all this stuff; i’m not sure how significantly it’s unified things: i suspect it’s effective primarily in greenfield projects.

account42 4y ago
> Qt uses a different string type than glib uses a different string type than std That is true for any language, even C, so your complaint is with those libraries not the language - and glib isn't even a C++ library at all while Qt is an ancient library that cares more about source-compatibility with its earlier versions than modern C++ (or even any version of C++ with a std::string). > except actually Qt’s copy-on-write implementation claims to be thread safe but assumes that the compiler inlines the mutation operators so if you forward-declare `struct QString` instead of #include <QString> then the operations might not be thread-safe… That doesn't make any sense. How is inlining going to affect thread safety? And (only) forward declaring a type won't let you do any mutations since at that point it's just an opaque name withoutout any known members. > it’s not just the language: it’s the library ecosystem too. And a new language won't fix that - especially when your idea of the library ecosystem for C++ already includes C libraries.
- colinsane 4y ago
  > glib isn't even a C++ library glibmm i’m sorry that i’m fuzzy on my Qt CoW issue. it was 8 years ago or so, i could probably dig up the ticket about it but the point was that thread-safety is just a thing you’re guessing at whenever you’re using C++. other languages have radically reduced that guesswork. >> it’s not just the language: it’s the library ecosystem too. > And a new language won't fix that - especially when your idea of the library ecosystem for C++ already includes C libraries. that doesn’t match my experience. taking the C++ codebases i’ve contributed to, more use a non-std string type than do. e.g. LMMS uses QString, Stepmania uses its “rage” rstring type. neither of these are small projects, both have download counts in the multi-millions. new languages do address these problems. when i see a project in Rust (or Go, Typescript, …) that i’m thinking of contributing to, i can be fairly confident it’s using the standard String type and that i can come up-to-speed on its memory model instantly — when i see that same project written in C++ i don’t know if it’ll take 10 minutes or 10 hours to understand its memory model, and believe me that uncertainty does impact which projects i choose to contribute to today.

imtringued 4y ago

>memory management problems because people have a poor mental model of how it works, which can be learned. But that has to be learned for each CPP file separately.