Hacker News Reader

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

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.

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.

D files don't #include .c files.

Unfortunately, these restrictions make it hard to implement F# style Type Providers. Though honestly the filesystem one is not nearly as annoying as the inability to reinterpret-cast.

That's fine with me. I don't want to make the cross site scripting mistake.

Which happen to be currently broken on modern .NET runtimes because it wasn't done on a clean way apparently.

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

But it's still not run automatically at build time, you have to go out of your way to run `go generate`, which isn't gonna happen if you, as is customary, fetch and build third-party code with `go get`.

> which isn't gonna happen if you, as is customary, fetch and build third-party code with `go get`.

Except that the convention is to check in the files generated by go generate, so in practice, it's not actually a problem.

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

You can get the same effect if you really need it with a pre-build command with dub (the package manager/build tool, and with other build tools such as reggae), but compilation is supposed to not change the state of the system other than produce build artefacts, you can read files at compile time with `import("filename")`, but you can't write to files, or open sockets etc.

Things like mixing in a data file is incredibly useful and not something I would want to use a rebuild step for at all.

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

Not strictly.

It is usually pickier about what is deems valid (which is usually corner cases that DMD really ought to reject). They share the same frontend so there is very little difference.

It has some of its own bugs, though nothing too major.

It generally has way less bugs both due to its release cycle being based off of DMD stable and thus it lags one cycle behind (~six weeks), so new features aren't available immediately, and having all the backend and optimisation handled by LLVM, though we occasionally hit LLVM bugs that clang for some reason does not seem to trigger.

(I develop both DMD and LDC (the LLVM based D compiler))

> Things like mixing in a data file is incredibly useful and not something I would want to use a rebuild step for at all.

It’s not directly part of the const function, but rust has compiler built-ins to import files as values as compile time, which makes it easy to declare global static variables that contain that data.

This is different from being able to walk a directory and read random files.

https://doc.rust-lang.org/std/macro.include_str.html

https://doc.rust-lang.org/std/macro.include_bytes.html

> They share the same frontend so there is very little difference.

That’s excellent.

> This is different from being able to walk a directory and read random files.

D doesn't allow you to do that either. You have to specify what files you are importing via a compiler switch: https://dlang.org/spec/expression.html#import_expressions

Yes. That's another barrier I put in to prevent a carefully crafted source code from being a malware vector.

> Is it compatible with 100% of the code that the current DMD release is compatible with?

For practical purposes: yes. We use DMD for development and LDC for release builds, and it works really well in tandem.