The other strength that Go has over D is that Go, being used by Googlers, is much more likely to have better networking support. Two examples come to mind: HTTP2 support (Go was used for either the first or second implementation of that and has standard library support), and TLS cryptography, where Go has it's own suite written by experts, where a good portion of the non Microsoft ecosystem relies on OpenSSL. For web/app servers, CLI tools, and networking stuff, I think Go has a strong set of options. Go also has a nice cross platform story for that subset of programs (networking and CLI tools).

That set of good internet sensibilities is what attracted me to Go in the first place, and why I still like working in it in my spare time. If D has a similarly strong story in that area, I'd love to know about it.

In other words, it's because Go has the backing of a huge software company, while D doesn't.

That is part of what allows Go to have those advantages, but it is those advantages that give Go an edge, not the corporate backing directly, in my opinion.

There is Vibe.d but I don't know if is as good as Go stdlib.

I can only give my own biased opinion: Go's only advantage is it's commercial adoption e.g. builtin in support in AppEngine and co. I am not referring to it's ecosystem: While gofix and friends are very good, D has similar tools available + the usual bells and whistles for IDEs.

By chance, I found (while looking for a rob pike quote) this article critiquing Go's design: It uses D to demonstrate it's arguments. http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

The first code comparison in that article compares Go error handling with doing a `catch Exception` in D. I don't find that a fair comparison; `catch Exception` for a block of code that can fail in different ways at different points is a bad practice.

It depends. If you don't care about the specific error and just want to notify the failure up the stack or recovering is perfectly fine. A lot of Go code with the same intent just do a lot of "if err!=nil return err" which is the same but writing for every function call.

Simplicity and consistency is the biggest strength of Go. D is a complicated language with a ton of features. That makes it harder to learn, and it makes it more likely that you'll encounter "cleverness" in other people's code.

As a tiny nit, it's interesting to compare D's `out` keyword to Go's multiple return values. An `out` keyword seems like a prime example of "thinking in blub."

I find that kind of ironic. I know there's a lot of people that love Go and it's a solid language, but I personally see it as the ultimate blub language.

That's fair. Go was designed from the start to be pragmatic rather than innovative. It is a refinement, rather than an enhancement, of its predecessors. And I definitely appreciate that when working with other people's code: it's unsurprising. Still, there is a gradient to "blub-ness". I think Go does a marvelous job of walking the line between discarding old conventions (like 'out' parameters) while remaining at the low level of abstraction conducive to writing fast code (e.g. unboxed types).

I haven't actually used Go, but one of its big strengths seems to be that you get a binary with no dependencies (beyond libc I believe) at the end of it. You can just deploy it through a file copy and have it just work.

So can you with D.

With D, in addition, you can link against C shared libraries (dynamic linking) AND you can write standalone libraries in D that even C can link against (see Mir/betterC).

AFAIK, you can do neither of these in Go.

Well, Go will require compilation just like C++. The strength is its build tooling seems better integrated with the language implementation. C++ has make and friends but honestly, I prefer Go's. This is all history. Go is designed from the ground up with pitfalls of other languages in mind. Rust is obviously even better at this, with Golang as a case study.

For production you want to omit things like debug from binary so your binary is smaller. You have to play with the build flags. I can get a simple TCP server in Go in just a dozen lines but the binary is around 5MB before optimization.

[1]: https://blog.filippo.io/shrink-your-go-binaries-with-this-on...

Golang: Easy concurrency using go-routines, a (comparatively) good minimal latency GC, an excellent comprehensive and stable standard library and few bugs.

Dlang: Traditional concurrency (thread based), great generics implementation, nice algorithm/container libraries and C++ interop

Actually the standard libraries containers (In D) are fairly poor/ignored. Also concurrency in D is not traditional in the way you seem to imply: Immutability and message passing are the recommended way to do it, Fibers are also in the standard library.

Actually, D suports "fibers" where you have a "Task". Then you can switch the task handler to another implementation and have Go-like M:N coroutines. The default handlers in the stdlib are only thread based or single-thread coroutines but Vibe.d for example supports Go-like coroutines.

Still, Go is really hard to beat on that front because it makes it super easy and has the really brilliant feature of making almost everything that waits for IO interruptable inside a function when you call "go function()" without having to mark operations with "async".

This is sort of what I'm wondering. Are the compile times as good as Go? Is the GC as good as Go, or do you end up having to do manual management to get similar performance to Go? What is the build tool ecosystem like (I found Go's to be the one part of Go that was not easy to pick up quickly)?

D can be arbitrarily slow due to its meta programming features. The comparable feature for Go would be some code generation integrated into the build process. This difference makes it hard to compare.

For simple (non-meta-programming) code. Dmd and Go are in the same league with respect to compilation speed.

Btw compilation speed is the main reason for me to put off Rust and C++ and Scala. I cannot stand slow compilers anymore after using D for a while.

D compile times are great for the reference compiler and ok for the other two. The GC is a bit of a mess, but still works well enough for most things thrown at it. D allows "manual management" C or C++ style (#include <memory>).

D's goto build system is called dub, it also handles packages hosted on dlang.org: I know no defects or problems with it, it's pretty good.

I've dabbled in D occasionally and the compile times are really fast. They're fast enough that they even have a version (rdmd) that basically acts like a scripting language.

See https://dlang.org/rdmd.html

This is awesome, thanks for the link. This is where I'll start when I have a good project to try out D.