Re:Go as an alternative to Node.js for Very Fast Servers
by gsg on Saturday February 23, 2013 @05:30AM
(#5269250)
Compilation units can rely on each other through forward declarations, so the dependency graph is not acyclic. Header exclusion does form a DAG within a compilation unit, I guess.
Re:Go as an alternative to Node.js for Very Fast Servers
by danieldk on Saturday February 23, 2013 @06:21AM
(#5269358)
A forward declaration is not really a compile time dependency.
If you are forward declaring a function, you are just promising that it is present during linking. So, during compilation it is not an edge in the graph.
If you are forward declaring a data type such as a class, a full definition needs to be visible at its first use or you are using the type as a pointer:
class A;
class B {
A *d_a;
[...]
};
Could you give an example where C++ dependencies are not a DAG during compilation?
Re:Go as an alternative to Node.js for Very Fast Servers
by gsg on Sunday February 24, 2013 @03:02AM
(#5273357)
Yes, but it is still a dependency. By which I mean the software won't run if you don't supply the necessary thing at resolution time (which is possibly quite late: well into runtime, if you are on a system with lazy linking). Go (and some other languages, like OCaml) enforces that such dependencies form a DAG: C++ does not.
I don't think this has much to do with compilation speed though.
In C++ header dependencies are also a DAG, since include guards prevent cycles (and multiple includes). What makes Go faster are a few things: (1) C++ headers contain templates, which are slot to compile; (2) Go only looks at direct imports and uses the compiled form of those imports, rather than recursing over their imports (again); (3) Go is simpler to parse; and (4) there is no overloading, so symbol/method resolving is simpler.
I also think that the advantage is often overstated. C++ is a nightmare in this respect, C programs and libraries often compile very fast (on my current machines, running configure often takes much more time than the actual compilation), the same applies to e.g. Java code.
That's really helpful when refactoring,
And annoying for testing, the printf example has been beaten to death. (Yes, I know that you can add a line such as var use = fmt.Println).
But for those of us who don't trust our human brains as much and want to be absolutely sure that these silly errors don't slip through
It's always surprising how Go fans can sell a feature that any strong statically typed language always had (easy refactoring by letting the type system work) can sell as something unique and new ;).