It’s always puzzled me that so many languages have their own build systems and package managers. Why aren’t programming language-agnostic build systems like Bazel and Buck more popular? It seems so strange that every new programming language essentially has to reinvent the wheel multiple times, inventing a new build system, package manager, formatter, linter, etc. I wonder if we’ll ever see something like LLVM for these technologies.
Because there are differences that go beyond just the language syntax. The build processes are very different for C++ vs. C#, vs. F#, etc.
C++: invoke compiler for all compilation units, invoke linker to combine object files into executable
C#: invoke compiler once with all source files listed
F#: same as C# AFAIK, except file order matters!
C++ I have worked only a little with it, more so with C, but AFAIK order of files does kind-of matter, so at least declarations need to be present in each file upfront before use.
C# has a multi-pass compiler so that it can compile and link the components from multiple files, without need of placeholder declarations, regardless of the order the symbols appear in the files.
F# has a single pass compiler, which keeps the compiler implementation simpler, but the file, and symbol definition order does matter that way. This is totally intentional, this is supposed to make the codebase more straightforward, with which I personally agree with. This avoids the need for declarations and centralization of them, the includes all the baggage that comes with that approach, and all the complexity C# has. I have rarely found a limiting factor, though there are some cases when it can be a bit inconvenient, for me the application setup/composition (~DI, but I prefer more static approach in F#) needed some cumbersome refactoring in some cases (have only vague memories by now, and yes, I know co-recursive types exists)
I really like F#, but rarely have to opportunity to work in it.
Firstly a strong desire to self-host: write the build system in the language itself.
Secondly, often very differently shaped requirements. The dotnet SDK tries to keep its build specification (.csproj) files editable by Visual Studio, which is why most of the stuff in them is just XML properties.
You probably could build C#/F# with Bazel but that's not what Microsoft chose, and you kind of need to stay aligned with them and the large amount of MSBuild files in the SDK.