tags:

views:

564

answers:

2

It would be interesting to contrast these two new languages by several aspects:

  • What are their design influences?
  • Where do they intersect in their goals / where do they rival?
  • Where are they distinct?
  • For which tasks is one or the other better suited?
  • What is your outlook on these languages? That is, which niche will D resp. Go fill?

As far as I know they are not direct competitors. Still it would be interesting to compare both languages especially since

  1. Ther are hardly any comparisons to find
  2. There are some subtle side blows from Andrei Alexandrescu against Go.

BTW, maybe some idiomatic code samples would be appropriate.

+8  A: 

This mail thread can answer a lot of your questions. It also includes a lengthy discussion between Andrei Alexandrescu & Ian Lance Taylor (part of the Go team).

EDIT: It's not a very good thread until about the 24th or so message.

However I will summarize my take (though personally, I think comparing Go to D is apples to oranges)

Go and D have very different design influences. D is (obviously) strongly influenced by C++. Go takes more from C, Limbo, Newsqueak (all 3 of which were at least in part created by people working on Go), and some others. Use each language and they start to seem miles apart.

They have very different goals as well. Where D is meant as a (++C)++ (from what I've read), Go was written to specifically meet the needs/wants of it's core design team (i.e. simple concurrency for server software, etc).

They are distinct from each other in 1000+ areas.

They're both turing complete :B, but they do have different design goals. It is currently difficult/impossible? to write an OS in Go (and the language wasn't designed to do so), whereas there is already an exokernel project in D. OTOH Andrei Alexandrescu has said himself that D's networking libraries fall behind Go's. And If you want to do CSP, Go wins hands down over D.

Personally D is too fat for my tastes, and Go lets me write concurrent programs the way they work in my head (a bunch of coroutines talking to each other). But that's just personal sentiment.

cthom06
For concurrency, have you looked at std.concurrency in the D2 standard lib? This is D's flagship concurrency model, and is message passing-based, though as a systems programming language it still lets you use unchecked shared state if you want to.
dsimcha
The mail thread was very interesting thanks for the link!
Eugen
@dsimcha I haven't actually looked @ std.concurrency, but I have heard of it. If I understand correctly it uses the actor model, which is similar to CSP, but not quite the same. Like I said I use Go, not D, so my answer was a little biased. That's why I wanted this to be CW, so people can add/edit.
cthom06
+8  A: 

D and Go are both interesting languages with very different philosophies.

Go seems to aim for simple as possible while being fast, flexible, and featureful enough. D seems to aim for fast, flexible, and featureful as possible while being simple enough.

An illustrative example might be the access of globals in multiple threads. (In my limited understanding) In D, you can declare your data immutable, which means the compiler can verify that it is safe for concurrent reading. If it isn't immutable, it is by default thread-local, so multiple threads can't access it and there is a bit of overhead associated with writing to it, but it is safe. If you actually want to access a global in multiple threads, there is a "shared" storage class you can assign it, making it explicit that you intend to access it across multiple threads.

By contrast, global variables in Go have no protections. If you want to access them safely across multiple threads, that's your problem. Go provides the easy means to make your code threadsafe, but it doesn't require you to write threadsafe code via static analysis and type qualifiers.

The Go designers seem to believe in "small government" language design; the language isn't responsible for forcing you to write correct code or doing static analysis or supporting unit testing or allowing arbitrary computation at compile time. They're old school Unix guys, where the philosophy is "Write programs that do one thing and do it well. Write programs to work together". Parsing Go is not too difficult, and Go comes with a complete Go parsing library, so writing additional tools isn't terribly difficult.

The D designer(s) seem to be more "big government" in the language design. The language is designed to take care of as much as possible, to be useful for every purpose. It can be safe, it can be unsafe. It can be garbage collected, or you can manage memory manually. It has built-in unit testing, lazy evaluation, static analysis, macros, and anything else you could want. It looks like it does a pretty decent job of doing everything.

Go doesn't yet have generics, so it can be awkward to write your own general purpose data structures.

One big advantage that Go has is that it has Google paying for it, so it has a team working (I assume) full time to improve it's libraries and tools. If Google is using Go internally to any significant extent, then you can be pretty sure that Go will exist and be well-supported for some time.

Both languages have the benefit of skillful and experienced team members, which is a big deal.

Anyway, both are under active development and making rapid advances, so I don't know that I'd use either for a serious project right now, but I'm watching with interest.

Kyle C