@dangoodin This is part of a broader pattern of people trying to find a rationalization to avoid change. (Note e.g. the sarcastic quotes around "package manager" — a thing that C/C++ are vastly worse for the lack of, btw.)
Change is scary, people spent decades learning C++, and they are afraid to have to go to all that effort again. I understand that fear, but I have much greater fear of not meeting my ethical duty to build safe products.
C++ also changes fast, and not enough, and in directions that aren't right for everyone. (The progression from C++11 to C++23 is fast and vast — and even harder to use, and new points of unsafety have been baked in!)
@fugueish@dangoodin The C++ community is at least working on the package manager problem, though of course being C++ efforts are split between two big efforts that the standards committee ignores.
Honestly, it seems like the standards committee/process is the greatest weakness of the language. Any substantial improvement never makes it out of endless bikeshedding in committee, and the way the standard is managed forces ignoring large parts of the ecosystem.
@dangoodin@fugueish Build systems and Package managers should not be part of a language! They make simple problems easy, but they make hard problems even worse. I have a complex project that we have spend over 1 billion dollars to write in C++ (over 15 years). Either you integrate with that mess including our build system (at least it is cmake), and package manager (a home brewed mess the less said about the better) or you don't apply. I can accept using C ABI for integration, but we still need to build your code, and shelling out to cargo is not a good answer. Likewise we already have a package manager that - bad as it is - works and won't be replaced with your half baked system that doesn't even pretend to do everything we need.
If you want to make a build system, make one. If you want to make a package manger make one. If you want to make a language, make one. However don't combine them into one, it just makes life difficult for someone else.
@dangoodin@danielleigh It is a deceptive siren song. It make the easy things easier. However it makes the hard things even worse, and all the special cases that build systems and package systems need to handle are more complex than most people give them credit for.
@dangoodin Rust has been pretty good for @suricata We do fix up smaller issues after new compiler releases, but there are generally real improvements.
Our biggest issues have been with the crate ecosystem. Too many of them quickly jump on new language features so it's easy to indirectly bump the minimum supported rust (compiler) version unintentionally. But generally we've been able to sort that out with the crate authors.
Add comment