GoLang compilation recently took a big hit (2x to 10x slower for various apps) when the compiler was re-written from C to bootstrapped Go. Rob Pike was concerned, which I think is a good sign. With Go-1.7, it is almost as fast as 1.5 again.
D2 on the other hand, though still fast, is quite a bit slower than D1. Here is a bit on how templates and other things were sped up in the D compiler: * [http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941](http://forum.nim-lang.org///www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941) One huge advantage of Nim and D over C++ is that a template specialization is instantiated only once (aside from inlining). I agree that templates can be a helpful feature of C++, and that they can also be abused to cause terrible compilation times. I have seen 1/2 hour compilation for a fairly small amount of code using Boost.Python and Boost.Serialization, and I hope never again to work at a company with that little regard for build times. In particular, I hope to avoid Scala, and for now also Rust. I will also say that I see some merit in Go's avoidance of generics. They're great for the coder, but they can be annoying to the reader. Different organizations may have different goals. > I'm not a Go programmer, but one obvious advantage I see from reading the > docs is that, unlike in Java, one doesn't need to define the types... > > That advantage is not unique to Go. The object system of the OCaml language > provides the same ability. Yes, @bpr, they are similar. The important thing is that you don't need to depend on the same interface file, as you would in Java (and C++, unless you trick the compiler). For a large project, it's important to be able to compile and test your own code without even downloading your dependencies. With a short build-time, you can simply rebuild the entire project, so this advantage becomes less important. But "coding to the interface" (with dependency inversion) is still a very good (and "SOLID") practice that is easier in some languages than in others. So I do appreciate your ideas, @Krux02, and I will look more closely at your macro when I have time.
