[constantcrying]

If you ever used Rust I am sure you already are aware of one major reason for the discrepancy, which surprisingly has nothing to do with the language. The tooling around rust is just so much better.

CMake, include conflicts, dependency management, etc. either don't exist or are all much less painful in rust. There is just so much annoying stuff that you do not have to deal with when using it.

There isn't really much revolutionary that rust the language does. Explicitly having to describe the behavior of memory takes getting used to, but lifts some weight of your shoulders. Other than that it has a somewhat better, and less verbose, syntax than C++. But that really is it.

[pptr]

A lot of this tooling is available for C++ development at Google.

Includes are added automatically when you use code completion. There is also a simple IDE command to add all the include dependencies to your build file.

I don't know how well rust is integrated with Googles internal tooling.

The golang integration is incredible, though. You don't need to touch includes or build dependencies at all. They are fully automated.

[constantcrying]

>A lot of this tooling is available for C++ development at Google.

No, it isn't. Google even has their own build system, because obviously CMake is so bad, but it it is made for insanely large systems not ease of entry for medium/small projects.

C++ slowly is adopting the language features that allow for such integrated tooling, but it isn't there yet. But right now the tooling can't exists simply because of what C++ is. The problems you can't easily solve in C++ are things like "how do I integrate this already existing library into our build chain", that is a legitimately hard question and millions of lines of code have been written trying to solve that problem.

There is no equivalent to cargo for C++, there is build2, there is conan there is vspkg and the VS build system. ALL of them suck and have their own gigantic problems which will raise their head and suddenly you are struggling with include and build problems.

Google hasn't fixed C++, nobody has.

[pptr]

All libraries you would need are already in Google's monorepo. There is no need for a package manager.

There are a few external libraries in the monorepo. Maybe it's a trickier task to add those. Most Googlers don't need to do that, though.

[constantcrying]

Mono repos don't make it so that suddenly you don't have to manage dependencies for a project. They certainly don't fix CMake.

[blub]

CMake is something you set up once and then mostly add source files which is a one liner. A platform like Android would have an SDK with all dependencies pre-installed, anything else would be nuts.

Have no idea what “include conflicts” are supposed to be. The compiler receives a series of paths and searches for files by name.

[constantcrying]

You can't be serious.

>A platform like Android would have an SDK with all dependencies pre-installed, anything else would be nuts.

Android is usually Java, but you still have to manage dependencies yourself. There is no SDK which includes "all" dependencies, that would be absurd. You are going to create your own dependencies.

For CMake, it is so bad that there are many high effort attempts to replace it, by Google, Microsoft and some others, just to not have to deal with it.

[ttfkam]

Android APPLICATION development is typically in Kotlin (and of course Java), but Android OS doesn't contain a large percentage of Java. That's C/C++ land and now increasingly Rust.

[singhrac]

I think this is an incredibly kind take for CMake... what about projects that automatically generate bindings (like swig), or attempt to find system-installed header files (like CUDA)? Look at, for example, pytorch (huge amounts of autogenerated code via ATen, at least a few years ago). In my experience C++ projects rarely live in a vacuum and projects build up cruft very easily.