3 ms·
>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
by 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 agoD 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 agocouldn'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.
- WalterBright 7y agoD files don't #include .c files.
- floatboth 7y agoUnfortunately, 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.
- WalterBright 7y agoThat's fine with me. I don't want to make the cross site scripting mistake.
- pjmlp 7y agoWhich happen to be currently broken on modern .NET runtimes because it wasn't done on a clean way apparently.
- ben0x539 7y ago> 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`.
- nordsieck 7y ago> 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.