I actually enjoy working in modern C++ much more than I did in Java, which I did professionally for almost 10 years before this.
I like the idea of Rust, and followed it since the earliest days when Graydon proposed it. I like the syntax and the tooling. But every time I begin a project in it, the cognitive overhead of the memory safety features just throws me a loop. I have no doubt if I were to dig into a large and established code base using it it would click within a few days, but starting on my own... I lose focus quickly.
I do like Zig, though. It is a very nice C++ alternative.
What do you like about working in C++ more than Java?
Generally, I hear from people working in C++ that it's the only tool for their job, and only use it because no other tool measures up (in a despairing tone). If you don't mind my asking, what do you use it for?
I mean, like, you can interface with TensorFlow via Python but the big-kid parts of the implementation are in C++ / CUDA.
I feel great joy coding C++, more than any other language. C++ is built to be used. Every part of it was put in to solve real problems, and they do. I can write thousands of lines of code, and when it finally builds, the program works first time.
This makes things a lot easier on both developers and end users but does not in theory scale well with increasing adoption (end users have a bunch of huge binaries bundling the same subset of libraries which all get hit with zero-days at the same time but are updated piecemeal across the apps bundling them). The tooling and package management stories are a similar case - they haven't fragmented yet, but as adoption increases you start having to deal with shit like packages from obscure hardware vendors and commercial language tooling - including compilers, providing functionality either absent from or superior to what's available in in the de-facto-standard project templates. Examples from my experience would be things like the Intel C++ toolchain, MPI compiler wrappers on supercomputers, and vendor-provided toolchains targeting alternative devices like CUDA.
Perhaps their community will deal with these challenges in a super-elegant way, I'm not ruling it out. But I'll believe it when I see it.
It's irrelevant on Mac, Windows, Android, and iOS, where the operating system is a monolith that applications depend on. Technically, it might be made up of multiple libraries, but the OS is almost guaranteed to be present in full, and it's the only thing that can be guaranteed to be present, and it might use integration systems that applications cannot or rarely use (VDSO, NTDLL, syscalls obviously, but also stuff like the System calling convention).
Or you might just use IPC for all components, like Plan 9.
It's also irrelevant if you're using a bare metal machine with no filesystem, a system with a weird linking paradigm like webassembly, or if your app basically owns the entire computer.
I also think a large amount of C++ is tied to a native platform, packaging system (or source repository), and possibly a native build system. That means the tooling is fragmented, though not universally poor. It's just that the tooling is not always available.
In lieu of C++ we hear a lot about Rust these days, with focus on performance and reliability. But I suspect the rate of adoption is such because of the productivity aspect (it seems to me the language itself has non-trivial concepts and its fair share of syntax cruft from what I saw): having integrated tooling, dependency management, all being a de facto standard for the language. Same for Go, it's just very easy to start a project, add a library, compile a project... everything is included.
I guess it's probably not a priority for experienced C++ programmers as they are probably used to it, but I'm sure more people could build stuff in C++ without those barriers.