liveBook · Manning

Build time

As explained in Go in Action, Second Edition

Compilation speed is the time or rate required to transform source code into executable or intermediate output.

Build time is the time required to transform source code into executable or intermediate output. In large codebases, punishing build times destroy momentum, so Go treats compilation speed as a core engineering and productivity goal. section 1.0 section 1.1

Go keeps compilation fast through structural constraints:

  • Disallows circular imports, keeping the package dependency graph directed and processable in a defined order. section 1.2
  • Requires every import to be used, preventing builds from processing unused dependencies. section 1.2
  • Uses selective type inference, reducing annotation without giving up static type guarantees. section 1.2

Compilation as a feedback loop

Fast compilation lets developers trigger a build on every file save. The compiler becomes a continuous collaborator rather than a final gate checked only after a long development session. section 1.2

How Go in Action, Second Edition covers it

How deep it goes
Explains import-graph and type-system constraints that accelerate builds, but stops short of compiler implementation details.
Examples
Uses enormous codebases, file-save builds, and near-instant compiler feedback as concrete examples.
What you can do after
Evaluate/understand how Go's compiler constraints turn builds into a continuous development feedback loop.
How it connects
Connects build time with type safety, package dependencies, type inference, and rapid development cycles.

Also explained in

Compare how 2 books explain build time →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Go in Action, Second Edition. The section links point to the parts of the book it draws on.