5 ms·

>Arbitrary compile time computation should be separated from the body of the program. If you need to download files or read the file tree at compile time, that

>Arbitrary compile time computation should be separated from the body of the program. If you need to download files or read the file tree at compile time, that should happen in a build script. Rust provides build.rs for that. This is an area we'll have to agree to strongly disagree. For me having support directly in the language is a huge improvement in ergonomics, compared to having to run a separate script. Compare e.g. generics in Go1 (which can only be done with separate build scripts at compile time) vs in any other language that has built-in generics. Also consider F# type providers, which guarantee at compile time the correctness of code querying a database (generate the schema/structs by querying the database at compile time). Certainly the same thing could be achieved by running a separate script as part of the build process, but I've never seen a language actually implement that, probably because it'd be much more painful. >The fast compile times are a double edged sword, since those binaries are noticeably slower than Rust binaries, from what I’ve seen. Note that D also has an LLVM-based compiler backend that is slower to compile but produces much faster code, which can be used for release builds.

coder543 7y ago
A major difference is that the Go compiler will not run build scripts when you build the code. You have to manually run codegen scripts, which is error prone since people are not good at remembering to do manual steps. Rust will automatically run the build script before building your code. It just allows you to logically separate build time I/O from runtime I/O, which I find is nice for reproducibility of builds and maintainability of code. The build script is still written in Rust, and you can import Rust code from wherever into that build script. The plan is to support arbitrary non-I/O computation in constant functions anywhere in Rust, since those are just pure functions. As far as your comment about databases, you should look at Diesel. It handles this very nicely in Rust, so... that’s not a problem at all. > Note that D also has an LLVM-based compiler backend that is slower to compile but produces much faster code, which can be used for release builds. Is it compatible with 100% of the code that the current DMD release is compatible with? That’s all I ask for in alternate compiler implementations... but it seems like a lot, sometimes.
- logicchains 7y ago
  >A major difference is that the Go compiler will not run build scripts when you build the code. Go actually has a built-in "Go generate" command that will look for magic "//go:generate <command>" comments in the code and automatically run code generation based on them, although I'm not sure how ergonomic it is. >It just allows you to logically separate build time I/O from runtime I/O, which I find is nice for reproducibility of builds and maintainability of code. This is a reasonable argument. For what it's worth, compile-time IO in D is more limited than in e.g. Haskell, as it seems the only compile-time IO D supports is reading files (or at least I can't find any documentation suggesting otherwise). Most of the power of its compile-time code execution comes from non-IO code (e.g. generating an optimal lookup table for a dictionary of values known at compile time, hard-coded in the code, or automatically generating fast JSON serialisation/deserialisation code for a struct without need for macros). While Rust also plans to support this, full support could be years away, while D supports it now. >As far as your comment about databases, you should look at Diesel. It handles this very nicely in Rust, so... that’s not a problem at all. Definitely shows it's possible to get the benefit of type providers without language support for them, hats off to the Diesel team! >Is it compatible with 100% of the code that the current DMD release is compatible with? That’s all I ask for in alternate compiler implementations... but it seems like a lot, sometimes. It's eventually compatible, sometimes lagging a few versions behind. Using LDC for release builds is somewhat comparable to only using stable Rust for release builds, except D has a slower pace of new feature additions than Rust since it already has so many features.
  - WalterBright 7y ago
    D deliberately restricts what compile time code can do that involves the operating system, restricting it to simply reading files from the current directory and down. This is to prevent the use of the D compiler as a malware target by sending it specially crafted source code to compile.
    - duckqlz 7y ago
      couldn't you just link to a c file in the same dir then use that to read up the file tree. I would be interested to know how D would prevent this.

coder543 7y ago

A major difference is that the Go compiler will not run build scripts when you build the code. You have to manually run codegen scripts, which is error prone since people are not good at remembering to do manual steps. Rust will automatically run the build script before building your code. It just allows you to logically separate build time I/O from runtime I/O, which I find is nice for reproducibility of builds and maintainability of code. The build script is still written in Rust, and you can import Rust code from wherever into that build script. The plan is to support arbitrary non-I/O computation in constant functions anywhere in Rust, since those are just pure functions. As far as your comment about databases, you should look at Diesel. It handles this very nicely in Rust, so... that’s not a problem at all. > Note that D also has an LLVM-based compiler backend that is slower to compile but produces much faster code, which can be used for release builds. Is it compatible with 100% of the code that the current DMD release is compatible with? That’s all I ask for in alternate compiler implementations... but it seems like a lot, sometimes.

logicchains 7y ago
>A major difference is that the Go compiler will not run build scripts when you build the code. Go actually has a built-in "Go generate" command that will look for magic "//go:generate <command>" comments in the code and automatically run code generation based on them, although I'm not sure how ergonomic it is. >It just allows you to logically separate build time I/O from runtime I/O, which I find is nice for reproducibility of builds and maintainability of code. This is a reasonable argument. For what it's worth, compile-time IO in D is more limited than in e.g. Haskell, as it seems the only compile-time IO D supports is reading files (or at least I can't find any documentation suggesting otherwise). Most of the power of its compile-time code execution comes from non-IO code (e.g. generating an optimal lookup table for a dictionary of values known at compile time, hard-coded in the code, or automatically generating fast JSON serialisation/deserialisation code for a struct without need for macros). While Rust also plans to support this, full support could be years away, while D supports it now. >As far as your comment about databases, you should look at Diesel. It handles this very nicely in Rust, so... that’s not a problem at all. Definitely shows it's possible to get the benefit of type providers without language support for them, hats off to the Diesel team! >Is it compatible with 100% of the code that the current DMD release is compatible with? That’s all I ask for in alternate compiler implementations... but it seems like a lot, sometimes. It's eventually compatible, sometimes lagging a few versions behind. Using LDC for release builds is somewhat comparable to only using stable Rust for release builds, except D has a slower pace of new feature additions than Rust since it already has so many features.
- WalterBright 7y ago
  D deliberately restricts what compile time code can do that involves the operating system, restricting it to simply reading files from the current directory and down. This is to prevent the use of the D compiler as a malware target by sending it specially crafted source code to compile.
  - duckqlz 7y ago
    couldn't you just link to a c file in the same dir then use that to read up the file tree. I would be interested to know how D would prevent this.