cargo-raze VS dmd

The same reason Bazel builds avoid using Cargo when building Rust software, so I'll describe why Bazel would do this:

- Bazel wants to cache remote resources, like each respective crate's source files.

- Bazel then wants to build each crate in a sandbox, and cache the build artifacts

This is an established practice, and Nix wants to drive the build for the same reasons.

See:

- https://github.com/bazelbuild/rules_rust

- https://github.com/google/cargo-raze

I can make much more sense of C++ code to ensure that two build systems produce the same effect than I can parse and learn two completely unconnected programming languages deeply enough to do the same. I can unit-test core routines. I can as easily extract core logic into shared (configuration) files etc. The benefit of a standard is not to discourage alternatives but rather to agree on definitive semantics and shared and common needs (that is: in this case needs for interfaces to the compiler/linker). The implementation and general availabilty is just one of the by-product. The ability to do introspection in common terms is maybe the most consequential other product, and this is critical for 'transpiling' to other build systems and writing automated adapters such as the one that bazel is recommend for cargo's dependency management.

Cargo is not that tightly coupled with Rust. You can absolutely use bare rustc, and in fact people do that with other build systems like Bazel.

Interesting, aren't the community-driven crates for these areas satisfactory enough? There's PROST and tonic, and quite well-used. I don't know about Bazel though, but I found this. Feel free to correct me on this subject, I admit I don't know that much about it.

There is a project to generate Bazel BUILD files from Cargo.toml.

Here's the pipeline spitting out the same error as on my macbook did.

https://github.com/dlang/dmd/actions/runs/8023469412/job/219...

Not completely on topic (if you read TFA) but my favorite Git commit is by compiler badass and HN frequenter, where he checks in an entire C compiler to the D language repo:

https://github.com/dlang/dmd/pull/12507

https://news.ycombinator.com/item?id=27102584

A new generated code alone is 4000 lines long [1]. The actual code added is just 2000 lines, and some are used to pay debts, I mean, to make a proper code generator (which can be alternatively written in a simpler scripting langauge). In any case it is never comparable to the entier C parser proper.

[1] https://github.com/dlang/dmd/pull/15307/files#diff-3677bcc89...

D is completely opensource already (https://github.com/dlang/dmd). The "open" of OpenD is just ADR saying that OpenD will be more open to new language features than D has historically been.

The reference compiler, DMD, is open source: https://github.com/dlang/dmd

But they don't accept just any Pull Request or features the community submits, understandably. There's a process called DIP for language improvements: https://github.com/dlang/DIPs/blob/master/DIPs/README.md

However, by some accounts, it's really hard to get anything through.

Given D already has so many feature, I find that to be a good thing , to be honest, by not everyone agrees, of course.