0

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?

starball
  • 20,030
  • 7
  • 43
  • 238
Roscurrvious
  • 1

2 Answers2

0

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.

lyhokia
  • 79
  • 5
0

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).

starball
  • 20,030
  • 7
  • 43
  • 238
  • Thank you for that link, that helps put things in perspective for C++. It sounds like the flexibility and power to write a program without a dependency on any specific thing (build system, IDE, etc.) was once a strength (maybe because it used to be really hard to agree on/distribute freely and across platforms?) which has ultimately turned into a weakness due to fragmentation. It's interesting to think about the relationship between the rise of the software-maker's internet (package sharing, open source, etc.) and the desirable characteristics of software dependencies. – Roscurrvious Jul 26 '23 at 06:02