5 ms·

One thing I cannot stand about C++ is the fractured nature of everything. Compilers, build tools, package management, etc... It feels like you need to be a wiza

One thing I cannot stand about C++ is the fractured nature of everything. Compilers, build tools, package management, etc... It feels like you need to be a wizard just to get a project compiling and start writing some code.

fsckboy 2y ago
you DO need to be a wizard to launch a large C++ project. Yes, languages that are beginner friendly are ... friendlier. Yes, languages that stick to one or a small number of programming paradigms are friendlier. But if you want the "flexible efficiency and raw power of C" and "something higher level than C", C++ is your baby. Maybe it would be better if we all used Java, Rust, and Go, but C++ sings its siren von Neumann song to the wizards, and there will always be wizard musicologists who steer their projects toward those rocks and, when they have just enough wax in their ears, they sail right past the rocks and come out the other side of the straits leading the rest of the fleet. You can choose to follow them or not, for there's no shame in coming in 4th.
- pjmlp 2y ago
  So much for the theory, then there is the hard reality how standard library is implemented, the variantions across implementations, and how the ongoing ABI drama is preventing any performance improvements to it.
- lenkite 2y ago
  Even the wizards are moving to Rust/Zig since C++ stdlib performance is becoming terrible thanks to the ABI-frozen till heat-death of the universe decision. Even wizards don't want to build a stdlib of their own from scratch. Feel the committee was smoking weed that day in la-la land. You can ignore all the safety stuff from Sean Baxter, but saying no to performance on the altar of permanent, un-specified ABI backward compatibility - when such was never mentioned as a design goal of C++ - means its "Goodbye C++" for a long, long list of orgs and "wizards". The ABI was NEVER specified formally by the C++ standard - so why bother sacrificing the world for its immortal existence ? C++ is NO longer the choice of language for greenfield native projects and the committee takes the full blame.
  - physicsguy 2y ago
    ABI compatibility is one of those things that is necessary with such a long history, especially with commercial libraries that don't really have an equivalent in the newer languages. The issue with C++ that doesn't exist with it's competitors is that there is a long tail of software people use commercially that isn't source available that's incredibly important in certain use cases. I worked in a previous role on C++ CAD/simulation software that required vendored things like solid modelling kernels and it was incredibly painful. Occasionally one of the vendors would just not do the work and you'd end up having to spend half a year ripping out the dependency that worked perfectly well. The team working on the software were generally in favour of moving up through to modern standards, while I was there we did 03 -> 17 for e.g. but that didn't finish til 4 years after the C++17 standard came out for all sorts of reasons. When VS2017 came out everyone breathed a sigh of relief because suddenly we didn't have to wait to upgrade the compiler.
  - asyx 2y ago
    Really looking forward to zig 1.0. I feel like C++ has become a language where professionals are fine with the historical grime but for hobbyist and people that need C++ occasionally there is just no motivation in the community to make this language more ergonomic.
- panstromek 2y ago
  So here's the thing. Almost none of the problems I have with C++ are related to "flexible efficiency and raw power of C". You could easily have language that is even more flexible and powerful, but much easier to use. Or not even use, just install. C++ was always by far the most inefficient langauge to work with for me, because there's just so much chore and nonsense that you have to get through to get anything done, and almost none of it has any reasonable purpose, there's no efficency tradeoff. I'm pretty sure that the insane build situation or UB in uninitialized variables or unspecified argument evaluation order never really benefited anybody, they are just bad decisions in the language, and that's all.
  - bluGill 2y ago
    > UB in uninitialized variables You will be happy to learn the uninitialized variables are not UB as of C++26.
    - quotemstr 2y ago
      They're just initialized to some unspecified value and cause almost-as-hard-to-diagnose faults.
      - bluGill 2y ago
        the unspecified value is supposed to be something really obviously wrong (in particular sanitizers will look for it.) and so be easier to diagnose with tools. Unlike 0 which is really hard to diagnose because often it is the right value and so when it isn't you won't realize what you did wrong.
- chrsig 2y ago
  > but C++ sings its siren von Neumann song to the wizards, and there will always be wizard musicologists who steer their projects toward those rocks and, when they have just enough wax in their ears, they sail right past the rocks and come out the other side of the straits leading the rest of the fleet. beautiful, in equal parts true, sad, and endearing. but also remember the vasa.
diath 2y ago
The worst part is when you want to bring along people that are not as much of a wizard as you are. I've been prototyping some multiplayer, online video game with MMO-like sharding for a while now, mostly the backend and core stuff for the project and wanted to get two of my friends on the project to develop the gameplay logic which is largely done through a dynamic scripting language, but some features (that, say, I did not foresee needed yet), require source changes to expose the APIs to the scripting language, now, these guys are capable of doing these changes but the onboarding process for a single potential co-developer is such a pain, I basically have to explain to them how to download a compiler, a package manager like vcpkg (which wasn't even that much usable for these types of things pre-versioning, and is still not working properly - i.e. trying to pin LuaJIT version to 2.0.5 for VM bytecode compatibility will attempt to build LuaJIT with cl.exe on Linux), a build system like CMake, and so on, then guide them through all the steps to get the compiler, the build system, and the libraries working, and then hope that in the end they will actually work and not force you to spend an entire day over a remote desktop software trying to get them to become productive.
- cyclopeanutopia 2y ago
  Can't you just put that into a docker container?
  - diath 2y ago
    This is more of a workaround than a solution; see my other comment in this thread.
- tom_ 2y ago
  Include more of your dependencies in the repo and build them aa part of the ordinary build process. Now a package manager does not need to get involved.
  - diath 2y ago
    Manually copy-pasting source trees around sounds like such an outdated idea from decades ago on how to approach dependency management in a modern programming language. Not to mention that you then have to hook them up to the build system that you are using and not all of them will work out of the box with the one you are using for your project, sure, if you are using CMake and your dependency uses CMake, you can add a subproject, how do you deal with it when they're mixed-and-matched aside from rewriting the builds for every dependency you're pulling in; or without manually writing glue shell scripts to build them independently and put them into a directory? How do you then ensure the said shell script works across different platforms? There are way too many issues with that approach that are solved in other languages through a standardized project management tool.

fsckboy 2y ago

you DO need to be a wizard to launch a large C++ project. Yes, languages that are beginner friendly are ... friendlier. Yes, languages that stick to one or a small number of programming paradigms are friendlier. But if you want the "flexible efficiency and raw power of C" and "something higher level than C", C++ is your baby. Maybe it would be better if we all used Java, Rust, and Go, but C++ sings its siren von Neumann song to the wizards, and there will always be wizard musicologists who steer their projects toward those rocks and, when they have just enough wax in their ears, they sail right past the rocks and come out the other side of the straits leading the rest of the fleet. You can choose to follow them or not, for there's no shame in coming in 4th.

pjmlp 2y ago
So much for the theory, then there is the hard reality how standard library is implemented, the variantions across implementations, and how the ongoing ABI drama is preventing any performance improvements to it.
lenkite 2y ago
Even the wizards are moving to Rust/Zig since C++ stdlib performance is becoming terrible thanks to the ABI-frozen till heat-death of the universe decision. Even wizards don't want to build a stdlib of their own from scratch. Feel the committee was smoking weed that day in la-la land. You can ignore all the safety stuff from Sean Baxter, but saying no to performance on the altar of permanent, un-specified ABI backward compatibility - when such was never mentioned as a design goal of C++ - means its "Goodbye C++" for a long, long list of orgs and "wizards". The ABI was NEVER specified formally by the C++ standard - so why bother sacrificing the world for its immortal existence ? C++ is NO longer the choice of language for greenfield native projects and the committee takes the full blame.
- physicsguy 2y ago
  ABI compatibility is one of those things that is necessary with such a long history, especially with commercial libraries that don't really have an equivalent in the newer languages. The issue with C++ that doesn't exist with it's competitors is that there is a long tail of software people use commercially that isn't source available that's incredibly important in certain use cases. I worked in a previous role on C++ CAD/simulation software that required vendored things like solid modelling kernels and it was incredibly painful. Occasionally one of the vendors would just not do the work and you'd end up having to spend half a year ripping out the dependency that worked perfectly well. The team working on the software were generally in favour of moving up through to modern standards, while I was there we did 03 -> 17 for e.g. but that didn't finish til 4 years after the C++17 standard came out for all sorts of reasons. When VS2017 came out everyone breathed a sigh of relief because suddenly we didn't have to wait to upgrade the compiler.
- asyx 2y ago
  Really looking forward to zig 1.0. I feel like C++ has become a language where professionals are fine with the historical grime but for hobbyist and people that need C++ occasionally there is just no motivation in the community to make this language more ergonomic.
panstromek 2y ago
So here's the thing. Almost none of the problems I have with C++ are related to "flexible efficiency and raw power of C". You could easily have language that is even more flexible and powerful, but much easier to use. Or not even use, just install. C++ was always by far the most inefficient langauge to work with for me, because there's just so much chore and nonsense that you have to get through to get anything done, and almost none of it has any reasonable purpose, there's no efficency tradeoff. I'm pretty sure that the insane build situation or UB in uninitialized variables or unspecified argument evaluation order never really benefited anybody, they are just bad decisions in the language, and that's all.
- bluGill 2y ago
  > UB in uninitialized variables You will be happy to learn the uninitialized variables are not UB as of C++26.
  - quotemstr 2y ago
    They're just initialized to some unspecified value and cause almost-as-hard-to-diagnose faults.
    - bluGill 2y ago
      the unspecified value is supposed to be something really obviously wrong (in particular sanitizers will look for it.) and so be easier to diagnose with tools. Unlike 0 which is really hard to diagnose because often it is the right value and so when it isn't you won't realize what you did wrong.
chrsig 2y ago
> but C++ sings its siren von Neumann song to the wizards, and there will always be wizard musicologists who steer their projects toward those rocks and, when they have just enough wax in their ears, they sail right past the rocks and come out the other side of the straits leading the rest of the fleet. beautiful, in equal parts true, sad, and endearing. but also remember the vasa.

diath 2y ago

The worst part is when you want to bring along people that are not as much of a wizard as you are. I've been prototyping some multiplayer, online video game with MMO-like sharding for a while now, mostly the backend and core stuff for the project and wanted to get two of my friends on the project to develop the gameplay logic which is largely done through a dynamic scripting language, but some features (that, say, I did not foresee needed yet), require source changes to expose the APIs to the scripting language, now, these guys are capable of doing these changes but the onboarding process for a single potential co-developer is such a pain, I basically have to explain to them how to download a compiler, a package manager like vcpkg (which wasn't even that much usable for these types of things pre-versioning, and is still not working properly - i.e. trying to pin LuaJIT version to 2.0.5 for VM bytecode compatibility will attempt to build LuaJIT with cl.exe on Linux), a build system like CMake, and so on, then guide them through all the steps to get the compiler, the build system, and the libraries working, and then hope that in the end they will actually work and not force you to spend an entire day over a remote desktop software trying to get them to become productive.

cyclopeanutopia 2y ago
Can't you just put that into a docker container?
- diath 2y ago
  This is more of a workaround than a solution; see my other comment in this thread.
tom_ 2y ago
Include more of your dependencies in the repo and build them aa part of the ordinary build process. Now a package manager does not need to get involved.
- diath 2y ago
  Manually copy-pasting source trees around sounds like such an outdated idea from decades ago on how to approach dependency management in a modern programming language. Not to mention that you then have to hook them up to the build system that you are using and not all of them will work out of the box with the one you are using for your project, sure, if you are using CMake and your dependency uses CMake, you can add a subproject, how do you deal with it when they're mixed-and-matched aside from rewriting the builds for every dependency you're pulling in; or without manually writing glue shell scripts to build them independently and put them into a directory? How do you then ensure the said shell script works across different platforms? There are way too many issues with that approach that are solved in other languages through a standardized project management tool.