Google Go on ARM

That almost universally prevalent idea has slowed down system building to a crawl right across the world of computing, and it's almost single-handedly reponsible for the problem you described.  (I'm referring to build time only here.)

Actually, C has the nice feature that compilations can be done in parallel,

using -j or --jobs, so having a multi-core machine can speed up compilation nicely.

I think in order to have Go's transitive compilation independence, your data structures

need to (implicitly) use a lot more indirection, so you pay a run-time performance penalty,

although I have not looked at Go closely.

That almost universally prevalent idea has slowed down system building to a crawl right across the world of computing, and it's almost single-handedly reponsible for the problem you described.  (I'm referring to build time only here.)

Actually, C has the nice feature that compilations can be done in parallel,

using -j or --jobs, so having a multi-core machine can speed up compilation nicely.

I think in order to have Go's transitive compilation independence, your data structures

need to (implicitly) use a lot more indirection, so you pay a run-time performance penalty,

although I have not looked at Go closely.

That's not a C feature, it's a feature of make:

make  -j [jobs]  --jobs[=jobs]

Make knows almost nothing at all about C, so if you've added the -j option to its compilation flags it'll merrily kick off concurrent builds for anything that the Makefile hasn't specifically ordered through sequential dependencies.  The most common candidate is to build concurrently all the .o files listed on the RHS of a target, but it does so without understanding why, ie. merely because its Makefile has been configured that way.

And what's worse, those many instances of the C compiler that have been kicked off by make will all process the same C header files repeatedly and independently, only slightly held back from total insanity by the magic #ifdef-#include-#endif incantations in the .h headers which are added manually by programmers, not a feature of the language system.

It's very different in Go.  The "go" build utility doesn't obey a configuration file at all, and instead it digs out the dependency information directly from the module being compiled.

That's not a C feature, it's a feature of make:

What I meant is that it's a feature of C that compilations can be done in any order or in parallel,

so you can use make's -j feature. 

coder27 wrote:

 

What I meant is that it's a feature of C that compilations can be done in any order or in parallel,

But that's not really a feature of C, it's a feature of the reentrancy of language compilers in all Unix-like systems and indeed in all sane operating systems everywhere.  I can't think off-hand of any current-day language compiler that can't compile two different sourcefiles concurrently on a multitasking system even in the same directory, and the only reason why they won't usually compile the same sourcefile concurrently twice over is because this would normally result in concurrent writing of the same output file which is likely to result in corruption.

Make -j makes good use of this general reentrancy of compilers (and it never attempts to compile one and the same file concurrently), but it's not a feature of the languages themselves.  Make just obeys its makefiles, and does exactly the same whatever the language.

The "go" build utility doesn't obey a configuration file at all, and instead it digs out the dependency information directly from the module being compiled.

That's a feature that languages like Ada have had for 30+ years.

But if module A depends on module B depends on module C,

and C declares a struct, and B declares a struct that uses C's struct,

and A declares a struct that uses B's struct, then the field offsets in

A's struct depend on the size of C's struct, so if C changes, you have

to recompile A even though A doesn't directly depend on C.

To avoid that transitive dependency, you have to access structs indirectly.

No, when compiling A then Go doesn't need to consider C.  C is a dependency for B, and therefore any change in C means that B is no longer up to date, so the "go" build tool will rebuild B first before it starts on A.  Then when compiling A it will examine only B, not C.

Maintaining a module dependency graph and propagating changes made at the leaves upwards is far less intensive than having to consider the full set of data structures in the program through deep traversal during compilation.  What's more, updating the modules is a once-only process until the next time that a leaf is changed,  The difference in traversal times is potentially orders of magnitude.  Go needs to open very few files while compiling a module.

coder27 wrote:

 

To avoid that transitive dependency, you have to access structs indirectly.

and you need a pile of metadata to do that - I guess that's what you meant when you talked about a run time performance penalty ?

When you're doing this sort of thing aren't you also effectively at least laying the groundwork for if not actually implementing reflection/intorspection and thereby straying into java/c# territory ?  I'm still not convinced that's a good thing, there's a price to be paid for this sort of thing, the only difference is whether you pay it up-front or at runtime.

No, when compiling A then Go doesn't need to consider C.  C is a dependency for B, and therefore any change in C means that B is no longer up to date, so the "go" build tool will rebuild B first before it starts on A.  Then when compiling A it will examine only B, not C.

You are describing how languages like Ada have managed dependencies for 30+ years.

Is that what you mean by revolutionary?

btw, Kuhn teaches that in order to have a scientific revolution you first need to have

a scientific paradigm, and I think he would consider computer science to be pre paradigm.

You don't see anyone suggesting to do scientific experiments in computer science where

for example you might implement a large project in two different programming languages to

see which works better, or teach two sections of an introductory programming class, using

two different languages, to see which section does better.

coder27 wrote:

To avoid that transitive dependency, you have to access structs indirectly.

and you need a pile of metadata to do that - I guess that's what you meant when you talked about a run time performance penalty ?

 

exactly.  Although I think I initially misunderstood what Morgaine was saying about Go not having transitive dependencies.

coder27 wrote:

 

... You don't see anyone suggesting to ... teach two sections of an introductory programming class, using

two different languages, to see which section does better.

I suspect the result will be that whichever has the better teacher who is more enthusiastic about the language being taught will do better.  For example, I'd do better teaching ASM than C++ because I love the simplicity and hands-on character of ASM versus the complexities of C++.  JMO/YMMV.

If you're hung up on the word "revolution" I'll withdraw it, since it's not essential to my point.

My point was to answer selsinork's correct observation that our computing systems have become bloated with so much unnecessary cruft that they behave like machines of yesteryear despite being far more capable on spec.  I offered Go as a very practical example of the removal of accumulated cruft, since it compiles extremely fast by combining an effective module system that eliminates deep traversals of dependencies and a language-aware build tool that uses knowledge of that module structure to reduce compilations to a minimum, without manual configuration.

The result isn't in dispute.  Anyone can experience it for themselves by compiling the entire Go compiler suite in a few seconds and the entire modules library in a small number of minutes.  The gcc equivalents (if an analogous set were to be constructed as fairly as possible) would take many hours to build.