To view parent comment, click here.
To read all comments associated with this story, please click here.
C++ and dependency nightmares? Please elaborate on your statement there.
Where there's sloppy design, there's dependency nightmares: where there's proper design, there is not. This is not specific to C/Objective-C/C++, as all languages that allow forward declarations/references (and languages that don't are rare) allow for circular dependencies, which is when things balloon out of control and become dependency nightmares.
What do a lot of more recent languages have that C/C++ doesn't provide built-in? The import statement (or equivalent) where you don't have to go out of your way to define something to say it has already been included. That's all. Note, however, you can still ensure things aren't included more than once in the same compilation unit, with proper usage of the preprocessor.
Go does not use header files at all, and unit/package scope is controlled through simple syntactic rules (anything starting with an upper case letter is externally visible, otherwise it is private).
Hence why Go does not allow forward declarations (I guess it is one of those rare ones you speak of). You define things once and only once - there is never any need (or even support) to do otherwise. Since there is no type hierarchy the need for forward declarations doesn't exist.
I don't do much C++ development (I very briefly dabbled in it a few years ago) - my understanding of the nuts and bolts of compilation and dependency resolution are very limited.
I can say though, that in trying to write a reply to you here I did do some reading up on how whole header/preprocessor/etc. combination works in C++. Suffice to say that after reading for about an hour I still don't understand it. The "rules" in Go can be explained, pretty much in their entirety without omitting anything important, in a single sentence. Quite a contrast to me, just saying...





Member since:
2006-01-25
Regardless of the timing, I really don't think it's related.
My understanding, from listening to various talks on Go programming, was the developers behind Go wanted some very specific qualities in the language they used internally that were either not available or troublesome to deal with in most other languages:
1. The wanted something simple and fun, from both the standpoint of syntax and feature set. They liked Python, but wanted something akin to compiled Python with a more conventional syntax and static typing.
2. They wanted something that could do most of what C++ could do, without the dependency nightmares and slow compilation speeds.
3. They definitely wanted garbage collection, but they also wanted to allow the developer some control over it. In Java and most other languages the GC has a tendency to become a barrier to optimization efforts. They wanted automatic memory management, but they also wanted to retain programmer control of the granularity of the allocations and still have pointers.
4. They wanted to build concurrency features into the language without resorting directly to hardware threads. I.e. make concurrency simpler.
In my opinion it succeeds at all of these. It is still immature, and I have not myself done any serious development with it, but from toying with it I have to say I like it very much. I do see it as an attempt to replace Java, but more for technical reasons than anything else.