> 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

> 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.