D vs Go in real life

[brad clawsie]

this has been a great thread and I've found a lot of the replies  
very insightful. I've been programming in Go at work for about a 
year or so now, so I have some opinions on Go that I believe are 
reasonably informed, while I am still a D novice but hope to 
continue learning.

First, let me say that it is obvious that, by design, D is a more 
powerful language than Go. Go's simplicity will either be an 
advantage or a deal-breaker based on who you ask.

On my vps instance last night I tried to create an initial D 
programming environment, with the following tools:

- dmd
- dub
- vibe.d
- ldc (not strictly necessary but I've heard so many good things 
about it)

First I tried installing dmd from source, which was fine but then 
I would get strange errors about referring to a file "object.d" 
when trying to build dub. Some poking around on the web resulted 
in the advice of installing the pre-built dmd binary that is in 
the release distribution. Now I was able to build dub, although 
it was strange to see two completely different build mechanisms 
for dmd and dub - dmd using a makefile and dub using a sh script 
wrapper. vibe.d was easier to install once dub worked. Over an 
hour just to get basic tools installed, although I feel HTTP 
serving is so common that it should be one of the accepted 
"batteries included" by default.

If this were Go, I would have installed the default build for my 
platform and had an http server in my standard sdk and everything 
else available by "go get", which has never failed to work 
flawlessly for me in a year of dealing with code from the web. 
This is one reason why there are already so many libraries for Go 
- it is trivial to expose your code to other developers via the 
supported toolchain.

This might not be a fair assessment given my shallow experience 
with D, but it seems much less polished relative to Go for 
setting up a development environment and working with code from 
the web.

Go's tools can be criticized as precluding operating system 
package managers, if people feel that criticism is valid, maybe a 
solution is something like the Haskell Platform, which was a 
reasonable response to the same criticism with haskell in years 
back - that setting up a development environment with basic 
consistent libraries was very painful. Haskell Platform does not 
seek to preclude operating system package managers.

Anyway, I hope this didn't seem too harsh. I still am playing 
with D and hopefully at some point in the future, package 
managers will address some of these needs.

brad