Why aren't first-party, language-specific, dependency-managing build tools ubiquitous?

Question

I've only seen this with C# (MSBuild as of 2017, usually invoked through dotnet CLI), Rust (Cargo, technically a "build system" rather than a "build tool"), and Go (go CLI as of v1.11). Swift, D, and Nim also have this according to ChatGPT. NodeJS has NPM, Deno has its own thing, the web has... the web.

A tool that is made and supported by the language creators and tightly integrates package management and build artifact creation seems like an important part of making a language toolchain good.

Did C, C++, and all JVM languages (AFAIK) just miss the boat? Maybe there are some key tradeoffs that make other kinds of build tools worth it? Perhaps this kind of tooling is a product of more recent wisdom?

Answer 1

I believe this is mostly historical. C/C++/Java are pretty old. When the language is designed, there really isn't a rule of thumb in the area.

Other old languages suffer from the same problem of not having a good first-party tool chain. For example: OCaml, Common Lisp.

Answer 2

Taking C++ as an example, people just didn't think of it / didn't think it would be important to be usable in that way at the beginning. It was a weird concept at the time that one would download a library from the internet. A big part of the original success of C++ was that you just needed a C compiler, a linker, and a text editor, and that it gave you the flexibility to allow you to organize your project and allow it to be configured in most any way you wanted. And as for why a language might not now have it, for C++, that flexibility that allowed people to do things in many different ways meant that people went and did things in many different ways (project layouts, configuration interfaces, buildsystems), which makes it hard to build something that unifies them all with some sort of common interface. There's a Cpp.chat video where this is touched on: Episode #78 - The C++ and Rust round table at t=50:50-57:28. There is current work being done towards better package management tooling (see SG15).