People always assume people who like Rust and are a bit more hesitant about C++ are just hype driven haters. I'm mostly exposed to C++ through my hobbies in creative coding, graphics programming, etc., and I would like to be a better C++ developer and be more comfortable with those projects. But every time I have to set up a new project it feels like death by a thousand cuts, and the fun art project I was about to work on just becomes a painful chore. I never, ever feel this way with Rust, even though it's significantly more immature in this space.

Maybe I'm just one of those spoiled younger developers who expects great DX on all my tools, but it makes me really reluctant to invest more time into learning C++ when I could be contributing to open source Rust and improving the ecosystem. Getting better with C++ just feels like learning an endless series of sharp edges.

This was something that Microsoft did really well back in the Visual Studio days. That said Rust really raised the bar not just on tooling but the whole end-to-end experience and with cross-platform being table stakes now it really makes for a compelling choice.

Well, it is no surprise given their C++ investment, that Microsoft keeps briging more Rust like experience into Visual C++ then.

They are adopting Rust in some small spots like Azure Sphere, and Rust/WinRT, yet WinDev, XBox, Office, .NET (for the runtime), DirectX aren't getting rid of their C++ code anytime soon.

Rust experience is compeling if one doesn't need to rewrite the world, e.g. doing CUDA in C++ versus Rust.

Seconded. I can have fun using Rust, I can't have fun using C++, so Rust is what I've spent the past ~4 years getting more and more familiar with. Now I'm at a point where I could apply to Rust jobs, but certainly not C++ jobs

Considering this is a volunteer driven open source project with a high "for the heck of it" factor (Wikipefia: "Fish is considered an exotic shell since it does not rigorously adhere to POSIX shell standards"), I don't think the having fun argument is quite as bad as all the serious people say.

Yeah, but I was also making a further point: if everyone uses the enjoyable language in their spare time, and nobody wants to use the miserable one unless they have to, you get a gradual brain-drain. More and more people have more and more experience with the fun one, and over time it gets easier to hire for (or find contributors for)

Of course it's sticky- someone who's already an expert in the miserable language may not choose to totally re-skill themselves (and anyway, once you know something that well it tends to become less miserable). But the new generations will heavily favor the thing that's welcoming to them, not the thing that's prickly

> But every time I have to set up a new project it feels like death by a thousand cuts

Which part of the following example is hard:

program(mynewproject LANGUAGES CXX)

add_library(libfoo STATIC foo.cpp )

add_executable(bar bar.cpp main.cpp )

target_link_libraries(bar libfoo )

Edit: and this message was downvoted? Seriously?

You completely ignored dependencies, which in my experience everyone seems to handle differently (and definitely not in a declarative way).

Differently put: a phrase "metabuild system" has both a lexical sense and an idealized sense. The lexical sense would be something that generates an input to build systems. The idealized sense would be something that does everything else not possible or difficult in build systems. CMake was definitely far from that ideal [1]; it was often simpler to make a configure script in your favorite language (and, for god's sake, not in M4) than using CMake.

[1] Was using a present tense but edited after realizing that I don't know much about recent changes to CMake. Still enough to justify my (and others') criticism.

> You completely ignored dependencies

Not really. When people talk about setting up a new project, they talk about starting a hello world project and build up from there.

Anyway, I'll bite. What would it take to add a dependency? If it exports a cmake config file which exports targets, all it takes is this:

find_package(MyDependency),

target_link_libraries(bar MyDependency::targetA MyDependency::targetB ... MyDependency::targetZ )

If it doesn't and it is instead a system library then you can even pass the library instead.

add_library(bar systemlibrary )

If the library exports no cmake config and you have anything exotic you can put together your own cmake find modules, and proceed to follow step A.

Alternatively, you can even bolt on something like Conan and just follow step A all the time.

> Differently put: a phrase "metabuild system" has (...)

Sorry, but do you actually have any concrete example of any difficulty setting up a C++ project?

> When people talk about setting up a new project, they talk about starting a hello world project and build up from there.

The original reply said one dabbled C++ via "creative coding, graphics programming, etc.", which definitely needs dependencies from the beginning. Can you draw a nicely shaded triangle only with the C++ standard library?

> If the library exports no cmake config and you have anything exotic you can put together your own cmake find modules, and proceed to follow step A.

They are not exotic, libraries without cmake config are common. So, as I've said before, people had to come up with their own find modules and this requires lots of trial and error to get it right. Guaranteed, it might have been possible to collect those into some sort of registry (a la DefinitelyTyped for TypeScript .d.ts files), and probably something like Conan can provide that, but ideally that should have been built into CMake. And keep in mind that Cargo---something we were comparing against back in time---does all of them declaratively. (Arguably, from users' perspective, it can handle C/C++ dependencies better than CMake!)

> The original reply said one dabbled C++ via "creative coding, graphics programming, etc.", which definitely needs dependencies from the beginning. Can you draw a nicely shaded triangle only with the C++ standard library?

Taken straight from Qt's page on OpenGL support:

find_package(Qt6 REQUIRED COMPONENTS OpenGL) target_link_libraries(mytarget PRIVATE Qt6::OpenGL)

https://doc.qt.io/qt-6/qtopengl-index.html

Do you feel this is too hard to setup?

That's because Qt 6 wholeheartedly converted to CMake for you. (At least it is better than qmake.) In order to support this Qt has this large battery of CMake files [1]. Qt is of course a clear outlier, but you can't expect the same level of support from every other library you want. My points about "anything exotic" still stand.

[1] https://github.com/qt/qtbase/tree/dev/cmake

> That's because Qt 6 wholeheartedly converted to CMake for you.

It's not Qt6. The same goes for Qt5, which has been around for what, close to a decade?

And what's your point, exactly? That things are hard if you purposedly ignore all the examples that prove that things are patently easy and trivial? Because it seems evident to me that if you want to quickly setup a C++ project to try out stuff, a CMake project with single-digit lines of code that get you a window with an OpenGL context going is right what you'd be looking for.

But instead you complain that the choice of build system and framework made things easy? And that's why things are not hard

What exactly do you think is your point?

Yes! I spent 2 hours the other day trying to figure out why some OpenGL header had moved in between macOS versions, or had failed to install correctly with Xcode. OpenGL is indeed, not an exotic library, but this is the perfect example of why working on these projects is annoying. It's totally platform dependent, and while people who spend most of their time in C/C++ land are used to hunting down system libraries, "where does this random file that got installed with unrelated platform toolchain get installed" is painful.

I have no doubt that people who work on big commercial C++ project have sensible build systems and documentation that's not too hard. But it's incredibly common when working in this art/graphics space to need to try to get someone's bitrotted random project without docs or build system running. Common to have to do that AND have to do it on another platform.

OpenGL is particularly strange because the libraries can be provided by the graphics card vendor.

That said... Rust and OpenGL have quite an impedance mismatch, don't they?

There totally is an impedance mismatch. It's definitely not as bad as you might think, but this is exactly the reason that I theoretically want to use C++. Art code is the perfect example of code where (a). mutability is whatever / good and (b). safety literally does not matter. Its the ultimate domain of hacking something together to make something pretty on the screen, not serious software engineering.

In Rust, using a library is as simple as “cargo add library”, and this is always the case. It’s even the case for most popular C/C++ libraries which tend to have Rust wrappers available that seamlessly integrate them with cargo.

In modern C++ if one isn't using either vcpkg nor conan, they shouldn't complain about having an hard time to find libraries.

The options are there to be used.

> do you actually have any concrete example of any difficulty setting up a C++ project?

Take a look: https://stackoverflow.com/questions/75270938/thread-pool-wit...

I spent the better part of a day trying to work out how to get VS Code to see library functions in the auto complete feature. Eventually I got it so it could ctrl click to go-to-definition but it still underlined the functions as undefined and auto complete wouldn't show them. I wasn't willing to go any further and waste more of my free time to solve this. I'd never experienced such an unintuitive process.

Had this same experience several times in various projects and in all sorts of IDEs, major pain. If it’s helpful, I recently came across the 10x c++ editor project, which has the best c++ code completion experience I’ve seen by a huge margin. Some rough edges UI wise, but it’s still in beta

As someone who works in C++, the build systems are definitely the worst part. QMake is abandoned. Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?

Options that are barely supported, severely limited in features, are only reasonable for tiny side projects, etc.

Bazel is supported by Google and is quite good. I’d certainly take it over CMake.

Interesting. My friend, who works at well known gaming company you've probably heard of, recently spent several months of his life fighting back against a group of people that came in from an acquisition that were trying to convert the company's well-working CMake system over to Bazel. He described it in pretty poor terms and described how it constantly caused the build system to fail. He eventually succeeded in convincing management to keep the CMake system rather than converting it to Bazel at the objection of the more senior devs from the acquisition.

It’s a somewhat steep learning curve, but in my experience once you have your Bazel rules set up properly, it’s incredibly powerful, enabling lots of time savings from caching, as well as helping enforce reproducible outputs.

I feel like Bazel is much more convincing _after it's working_, cuz you really do get much faster builds. But the work has to be done, and there's a lot of unlearning to do.

If your project doesn't take long to compile or test anyways.... I can see getting annoyed.

> I feel like Bazel is much more convincing _after it's working_, cuz you really do get much faster builds.

I have to call bullshit on this claim.

CMake is at its hear a build system generator. It offers a high-level abstraction to define software projects, and it uses that abstraction to generate the actual build system. It can generate makefiles, but also Ninja, Xcode, visual studio, and even msbuild projects.

What actually does the build is not CMake, but make, msbuild, ninja, Xcode, or visual studio. Not CMake.

You run CMake once to generate the build project, and when you actually want to build the project you only call ninja or make etc.

To top that off, some of these build systems support build cache systems such as sccache or ccache. Plugging in one of these tools can easily drop build times to a fraction of the time. Literally. I had C++ projects which used CMake whose build time of a complete rebuild dropped to 15% of it's original time.

I haven’t been able to get Bazel to work passively for small, non-toy Go projects—I’m sure it’s something I’m doing wrong, but Bazel is a complex beast to operate. It’s far more complicated to use than Cargo.

use bazel if you're compiling large C++ or Java projects. If you're using rust, use cargo.

Nothing beats a language's own dedicated packaging system (yes, even python's mess is better than bazel+python) but C++ and Java have bad build systems, so bazel is better for them

Granted, but the context of the thread was that C++ build tools are low quality compared to other ecosystems, and you mentioned that Bazel was supported and "quite good" implying that it was comparable with other language ecosystems (perhaps that's not what you intended to communicate?). I believe that it's better than CMake, but the original point (C++ lacks good build tooling compared to other languages) still stands IMHO.

> but C++ and Java have bad build systems, so bazel is better for them

What is wrong with Maven or Gradle?

I've had great experience with migrating C/C++ projects at work to use Bazel, at least in the sense that a couple of hours' work yields me a fast, correct, reproducible build and has usually sped up incremental build times by orders of magnitude.

But in a corporate environment where repositories are often authenticated, the fact that dependency fetch issues are reported as Java exceptions (having the wrong password in your netrc file shows up as "IOException occurred during fetch of ... Code 401") is a deal breaker for a C/C++ development staff unfamiliar with Java.

They happily take their ten minute incremental builds and "it works on my machine" issues in return for a build process they can understand, and as much as I want them to be wrong (I use Bazel all the time at home), I can't blame them for wanting tooling they understand.

Yeah, Bazel’s ergonomics can leave a lot to be desired, but to me the results are worth those issues. In general, changes to Bazel rules are much less common compared to code changes, so at least it’s only a small subset of time where you might see such issues.

For this sort of thing, what I tend to do is write doctor scripts that check this kind of stuff "out of band". Can be tricky, but like "have credential stored in a file, then have an out of band script that checks that the credentials can reach a server" can save a lot of headaches. "Did you run the doctor script?"

Aside from tooling (which is much better in Rust), C++ just isn't a very expressive language and has a high impedance with cognition. I've worked in C++ for well over a decade, and now that I've used Rust for a couple years, I just don't ever want to go back. It solves too many pain points of C++ to ignore.

> C++ just isn't a very expressive language

Compared to what? Modern C++ is by far the most expressive systems language. That is its primary selling point. It isn’t pretty but it is uniquely powerful. One of the reasons C++ isn’t disappearing any time soon is that it elegantly and efficiently handles some software design problems that Rust struggles with. Rust and C++ are optimized for different types of software.

As is implied, the type of software someone is writing has a large impact on whether or not they need the expressiveness of C++.

Can you elaborate on how Rust and C++ differ in the kinds of software they’re optimized for? And what makes C++ more elegant for purpose?

> Modern C++ is by far the most expressive systems language.

If you want to iterate over a range of integers, you need to manually explain to the computer how to do it. In 2023. Also, you need to Write Everything Twice because of the ancient header system.

No you don't. That is what ranges and modules are for.

Ranges: kind of, there is the very awkwardly named std::ranges::iota_view, but it doesn't support random access and who knows if the compiler can optimize iteration over it into a simple loop.

Modules are not supported by most compilers (in g++ you have to enable them as an experimental feature with -fmodules-ts, and if you want to import the standard library as modules, you need to pre-compile them into your project directory with some arcane commands).

Ranges: they are there, naming is a matter of taste.

Modules: GCC and clang will eventually get there, I am already enjoying them on VC++

    #define RANGE(type, name, last) type name = 0, last__ = (last); name != last__; name++

    for (RANGE(i32, i, foo->count))
        ...

That solves the problem even in C. But why care much, typing a few plain loops isn't among the hard problems to solve.

Compared to Rust.

Once you you've worked enough with proper enums and matches, that's the first thing you'll be lacking in C++ (and no, std::variant is a horrible mess without proper syntax support and doesn't even get close).

If anything, C++ is too expressive...

There is a difference between what you can do at all, and what you can do without hard thinking. C++ makes a lot of things possible, but fewer things easily possible. I program mostly in C++ and I don't hate it, FWIW...

Agreed, but I would probably still be programming in C++ if the tooling weren’t so bad, irrespective of the expressiveness. That said, I’m glad Rust is expressive, but more glad that it picked a coherent set of language features—it feels much less cobbled together than C++ if only for the benefit of hindsight.

Not very expressive? Are we talking about ARM C++ here?

C++ has lots of problems, lack of expressiveness isn't one of them.

> C++ just isn't a very expressive language and has a high impedance with cognition.

I feel that you are the very first person ever making such a statement. Can you provide what's your single best example showing C++'s inexpressiveness and "high impedance with cognition"?

Sum types. And/or proper error handling (also related to sum types).

cmake is fine. just learn modern cmake. most of the complaints are from pre-3.11.

> Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?

I've been working with C++ for a few years and did some work porting legacy apps to CMake. I've saw awful CMake legacy projects but since CMake 3.0 and the introduction of it's declarative way of setting up targets CMake is actually quite nice to work with.

What exactly does CMake do that you feel is "an ancient horrible mess"? Can you provide any specific example?

Premake is left. We use it across our entire C++ codebase, which is reasonably large.

> Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?

There is build2[1], which tries to approximate Cargo's experience for C/C++ projects while providing more depth, especially in the build system (unfortunately the "build by convention" ship has sailed for C/C++ so there needs to be some flexibility).

As some indication of the project's "seriousness" (there are a lot of toy build systems out there), it builds Boost and Qt (both 5 and 6 but only classic for now).

[1] https://build2.org

> What's left?

Rather marginalized but https://waf.io/

Bazel! It's a modern horrible mess that feels like a miracle if it works at all. Nicer than CMake or Autotools or handcrafted Makefiles though.

I would give up my firstborn to never have to deal with CMake again.

Initially coming mostly from the Java ecosystem with its mature (not perfect) build and dependency story, it took me days to understand that none of that exists in C++.

All of it seems to be based on copying dependencies around or installing them on a system level. Plus mostly template/text driven make files.

I'm still not sure if this is really how C++ is developed.

Four years ago, when I last looked, I wasn't able to find a good resource for people with my background to learn C++ the ecosystem (not the language).

That turned me to Rust. All of this text to give strong support for your first paragraph.