On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:
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.
So when you say you would install Go using the default build,
did you mean as a binary, or do you mean some sort of default
build configuration (from source) for your platform?
If as binary then this comparison is a bit unfair here.
For me (OpenSuse) all I need to do is:
sudo zypper in dmd
I've used the pre-built binaries on various Windows & Linux
OSs with no troubles.
If you want to build from source you might want to have a look at
DVM:
https://bitbucket.org/doob/dvm/wiki/Home
(I don't have any experience with it personally, so I can't say
how trouble free your experience would be).
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.
Well D is a volunteer effort while Go is being backed by the
worlds biggest web company! That sort of accounts for that I
suppose. There has been recognition in the community that this
needs to improve, but progress is only so fast with the limited
resources.
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
Hope you enjoy your experience with D.
