> Assign copyright to the FSF which requires contacting all authors including those who are MIA.
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?
I think this is good news, if it all happens. There are some hurdles though. D have always had a nice look about it, a good reliable, predictable, open compiler is a huge step to greater acceptance.
once D is in GCC does that mean most of the rationale of Go(lang) is gone, in that both D and Go are supposed to be non-shitty C++.
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.
That's assuming you care about concurrency in a low-level systems programming language. If my problem space requires concurrency I'd use clojure or erlang.
I guess if you're interested in one language for everything then maybe Go is better.
Go is not meant to be a low level systems language... it is meant to be a systems language useful for implementing services... something for which you better be caring about concurrency for.
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.
I disagree. As far as I can tell, Go is a resolute step backwards from C++ in efficiency, modeling power, and generic programming. That's not necessarily bad; simplicity has its virtue, too. The larger problem is that Go fails to avail itself of the progress in programming languages theory and practice in the past 30 years.
And in 1981 there were already application servers, running in multiprocessor machines using Multics, UNIX and VMS, just to name a few operating systems.
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.
They are if you put the words "easily, efficient programming of" in front of them, which I think was what the parent comment was getting at.
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.
Point taken. Mine is that Go attempts to solve these new ideas with 1980s programming language technology. Touting it as a reimagining of C (or anything) would be insulting to C.
Dismissing Go as '1980s programming language technology' is unfair, patronising and misses the point.
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'.
I don't follow you on this. You could just as well say; since Go is already in GCC I don't need another compiler to write Go and I don't need to write any D, or C++ or...
Yeah I wasn't clear, I mean one of the big things putting me off using D more was having to download DMD, so I'd be more inclined to write Go, if this gets merged I won't be.
One thing to remember is that AFAIK no D2 compiler implements the whole language, and even DMD, which is the 'canonical' implementation seems to be well known for its copious bugs. This is not surprising given how huge and complex the language is.
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.
"was great", implying you are conceding it now has faults but are suggesting this is only because it does more than Go does.. I'll let that stand for the furtherance of this conversation but I do disagree with your assertion...
"current compiler is eminently usable", didn't you just concede half a sentence ago that it is now full of bugs?
Well we're not in court. I simply meant to say that it takes longer to write a compiler for a larger language, and that today the D compiler is of good quality.
You could as well say that now that gcc can compile C++, it can drop support for C (and no, C is not a subset of C++ anymore).
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.
* 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.