Definitely seems like Go has led the way here. Not that there wasn't a lot of pain before, but Go's lightning compilation seems to be an impetus for the "let's finally do this" change.

I have to think that this is a minor repartee between Apple and Google language groups. Google did something clever that breaks with tradition, and now Apple is doing something similarly clever yet backwards-compatible.

I like this dynamic. I certainly appreciate this move as a OS X/iOS programmer, since getting a functional version of Go on iOS is a pipe dream for strategy tax reasons.

I don't intend to downplay the importance of Go (it's definitely helped people realize how nice fast compiles can be when you don't have to fight the language to get it), but Clang (whose leaders are making the proposal here) has had an explicit focus on fast compile times since the very beginning:

http://clang.llvm.org/features.html#performance

Note that "Fast compiles and Low Memory Use" is listed more prominently than any other feature (in primary position, with more text and pretty graphics).

Object Pascal did the exact same thing 20 years ago, and it was a language much more influential than Go at its time. So, I don't think Apple programmers had even to look at Go to design this feature.

Yeah. Compile times there were ridiculously fast, bordering on interactive. Go follows the same path.

Java has very fast compilation as well, due in no small part to tossing the preprocessor and having fast binary imports.

Part of the advantage of Pascal at the time is that it was created explicitly to allow for fast parsing. C and especially C++ are much harder to parse.

The main advantage was still the possibility of having binary modules, without parsing the same imports multiple times during "make world" compilation.

Just as input, the ISO Pascal eventually got the changes that were available in Turbo Pascal and Mac Pascal (known as ISO Extended Pascal), but by then most people considered Turbo Pascal the _de facto_ standard.

If I remember correctly, it's a single pass parser, which is why you generally write get to your code upside down.

Also due to the java compiler doing very little work (it's a really dumb compiler)

It does all the same work as a C++ compiler, except optimization phase. Yet any C++ compiler with optimization turned off is still order of magnitude slower. The key differences are:

- Java has a much simpler grammar to parse. - Everything is compiled at most once. - Encapsulation is stronger: private class members are not exposed in public class ABI and external code doesn't depend on them (this also extremely improves recompilation times - no need to compile half of the project because you changed a private method).

> Definitely seems like Go has led the way here. Not that there wasn't a lot of pain before, but Go's lightning compilation seems to be an impetus for the "let's finally do this" change.

Except that this is pure marketing. Languages with modules were already compiling as fast as Go does, back in the 80's.

Modula-2, Turbo Pascal, just to name two of many.

Yes, the idea of using modules is nothing new. It's old-school and well-proven. Many people have argued about adding pascal-like module support to C at some point or another at the coffee machine. But having enough (political) momentum to actually change C(++), and overcome extreme inertia and calcification is new. LLVM is the greatest thing to happen to compilers in a long time, it really opened up compiler development like GCC somehow never did (see http://www.drdobbs.com/architecture-and-design/the-design-of... for a likely explanation). And having a giant like Apple behind it helps, of course.

Oh yes, I am all for having modules in C and C++.

I was just calling the attention that some Go devotees seem to think their compile times are something new.

Golang should get a kickass debugger before C++ gets modules and steals their thunder.

Genuinely curious: what are you looking for in a "kickass debugger" for Golang that isn't already provided by GDB's golang support?

The ability to recompile code in the debugger and continue execution?

And some would argue generics...

Don't forget generics

I found the Go module (aka package) system subtle to understand, but it seems to work well. The subtlety being that what you name when you write "import" is not a module, but a directory on the filesystem (under a known root). Actual module names that act as the namespace for a module's public identifiers do not have to be the same as (or derived from) the import path; that is just the convention. For example, importing "utils" could conceivably bring in bobsfunkystuff.SomeFunc with there being no such module as utils and hence utils.SomeFunc.

It's also my understanding that there are no "submodules" in Go. If you want what's in the import path "foo/bar", importing "foo" is unrelated. In fact, there might not be anything in "foo", making it an invalid import path, despite "foo/bar" being a valid one.

And then there's the stuff with being able to directly import code from github, code.google.com, etc, but that dovetails in to the same mechanism after downloading.