A few notes on choosing between Go and D for a quick project

[yawniek via Digitalmars-d]

On Friday, 13 March 2015 at 13:18:03 UTC, Dicebot wrote:
> In my opinion it is better to focus on tempting users with D 
> strong bits than oversell it by trying it compete in topics it 
> has inherent disadvantage. There is not point in try to compete 
> with Go on topic of simplicity - they have crippled the 
> language tremendeously to get that simplicity. Simple D has no 
> value - I would simply prefer Go instead of it as it has head 
> start advantage in toolchain.
>
> Instead it is better to focus on explaining users that they 
> don't want what they think they want, akin to that Bjarne 
> quote. And don't be afraid to admit to certain users that D is 
> not a best choice for them. It doesn't mean that such valuable 
> feedback should be ignore - there is indeed a lot that can be 
> improved in the learning curve. But trying to fight for user 
> who makes choice with "trendy" and "simplicity" in mind is a 
> battle lost from the very beginning.

this.
imo D's feature set is awesome and still it is reasonably easy to 
get a start with just a simple subset
of D.
one thing Go did really well was focusing on getting a complete 
set of basic libraries.
a foundation with support of most protocols.

i did two small projects for work within the last month, one in D 
(a multithreaded crawler that hammered a json API) and a uploader 
that can upload to S3 or Openstack Swift in Go.

So here goes my personal list:

D:
+ speed
+ the language itself and its features. i love how you can write 
pretty dense code with
UFCS, lambdas and ranges.
- stdlib. lots of missing pieces (e.g. email parsing, native http 
client)
- iv'e also spent a lot of time fighting with external libraries, 
reading their code (especially vibe-d as i used its http client 
and concurrency features). sometimes it was the missing 
documentation, sometimes just the complexity.
- debugging and tracing (osx/linux, and to be fair, i haven't 
tried with Go)

Go
+ libraries, yes the hipster factor also produces a lot of crap. 
but still, i needed to get stuff done yesterday. 
documentation/apis are often straight forward, i rarely had to 
look into the sources.
+ support: documentation, build tools, formatting. "it just 
works" (just today i discovered the awesome dfmt. this should 
come with dmd...).
there is also sites that just explain a couple of concepts, e.g. 
http://www.golangpatterns.info . very helpful
- the language itself. the code just looks ugly and shoehorned 
around their simple concepts
- error handling...

something that would have helped me would be a nice guide on how 
to setup a whole development chain:
- list of utilities needed (e.g. dmd, vim, DCD, dfmt...) and 
their configuration
- build tools (dub),
- debugging, tracing
- code organization best practices.

in general the current "D crowd" seems mostly game and language 
people.
Distributed systems, databases and high performance web services 
is something i
think D would really shine. Not sure on how to better serve this 
market though.