* Assign copyright to the FSF which requires contacting all authors including those who are MIA.

* Update the code to the GCC coding conventions

* Submit for review patches to the GCC core that where shipped with GDC and get them accepted

* Finding a co-maintainer

* Promise to continue to maintain the code

* Implement naked functions attribute

* Convert the testsuite to Dejagnu

* Downgrade the zlib library used by GDC or upgrade the one in GCC

Those are all reasonable requirements from the GCC project, but impose some extra work for the GDC maintainers. Cheers to them for biting the bullet.

What for? GDC is distributed under the GPL. Isn't it kind of the whole point of the GPL, that this kind of thing can be done without having to ask for special permission?

Now I don't need to download another compiler to write D and I can use c libraries with it, I don't think Go has much over D in order to make me go to the effort of installing a Go compiler.

The concurrency constructs (Goroutines) in Go are different and quite unique (I think D offers a number of models, but mostly pushes you towards Actors).

Go has simplicity as a much higher priority than D does.

This thread might be useful: https://groups.google.com/forum/#!topic/golang-nuts/8k59Rgke...

They are both interesting languages, but you might as well say that because C++ and Ada are in GCC the rationale behind Go has gone.

I guess if you're interested in one language for everything then maybe Go is better.

Erlang really is the best language to point at and say "why do we need this new one", though doing that in the first place is stupid.

D is a rethinking of C++.

Go is a re-imagining of C++.

It's not just about classes; it's also about concurrency.

Although D2 did have some concurrency ideas, I think Go does a much better job at figuring out how to solve concurrency problems on modern hardware.

D took C++ and improved upon it.

Go went back to C and said, "what if C++ had never existed".

- Modern web servers - Modern multi-core CPUs

None of which existed in 1981

And in 1981 there were already application servers, running in multiprocessor machines using Multics, UNIX and VMS, just to name a few operating systems.

Personally I see Go as a better C, nothing more.

But still, at least, they weren't as common place as they are now.

Which is a good thing, right?

By placing the contract at the use of a type with an interface rather than at the declaration of a type you effectively introduce a form of duck typing to a static language.

You can write an interface for a type long after the type has been declared (or been declared by someone else). Interfaces can be defined and used without having to go back and change existing code. This is very lightweight.

To be even more pedantic than yourself, I would like to point out that everything that can be expressed is an idea. For us to have a word we must have a meme. A noun and the idea of a noun are inseperable. Even mathematics is language that conforms to this rule.

jus'sayin'…

Very little of substance has been invented in programming languages since Lisp was created in the 1950s. It has mostly been syntax.

C itself is an early 1970s language based on ideas from the 1960s. It has been the backbone of serious computing for nearly 40 years. It is 1970s programming technology that works.

One of the few 'new' things to arrive was Tony Hoare's CSP (in 1978). Go takes this idea and builds an effective implementation of it onto a C-like language with minimal noise.

Go then adds the a tiny amount of syntax to C to have a layer of Object Orientation. This is not a 'modern' 1980s style of OOP like C++ uses, rather it is the 1970s OOP of Alan Kay and Smalltalk.

So it it insulting to say that 'Go attempts to solve these new ideas with 1980s programming language technology'.

If anything, Go is 1970s technology.

Go has very little to do with OO Smalltalk style.

The only new language that has a very close to Smalltalk OO style is Ruby.

In any case D and Go are very different beasts

Go's compilers (like all code) also have bugs, but you rarely if ever run into them, even given their youth and the blinding rate of improvement, they are quite stable.

"current compiler is eminently usable", didn't you just concede half a sentence ago that it is now full of bugs?

Go aims for a very small and clean set of features that work well together and produce code that is easy to write and read, D seems to aim to include every C++ feature and a few more.