Go Programming Fundamentals · Go Basics

Getting Started with Go

Q: What does `go mod init ` do, and when do you run it?

## Summary It creates a `go.mod` file that names your module and will track its dependencies — you run it once, when starting a new Go project. ## Longer Answer It creates a `go.mod` file that names your module and will track its dependencies — you run it once, when starting a new Go project. go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview. ## Key Points - It creates a `go.mod` file that names your module and will track its dependencies — you run it once, when starting a new Go project - go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first - In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview - Use the answer to connect the concept back to a realistic production or interview scenario for 'What does `go mod init ` do, and when do you run it?' ## Comparison / Tradeoffs | Aspect | Notes | | --- | --- | | Core idea | It creates a `go.mod` file that names your module and will track its dependencies — you run it once, when starting a new Go project. | | Practical tradeoff | go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first. |

Q: Why does every executable Go program need a `package main` with a `func main()`?

## Summary `package main` marks the package as producing a standalone binary rather than an importable library, and `main()` is the fixed entry point the Go runtime calls to start execution. ## Longer Answer `package main` marks the package as producing a standalone binary rather than an importable library, and `main()` is the fixed entry point the Go runtime calls to start execution. This is Go's equivalent of `public static void main` in Java or `if __name__ == '__main__'` in Python — a single, unambiguous entry point. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview. ## Key Points - `package main` marks the package as producing a standalone binary rather than an importable library, and `main()` is the fixed entry point the Go runtime calls to start execution - This is Go's equivalent of `public static void main` in Java or `if __name__ == '__main__'` in Python — a single, unambiguous entry point - In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview - Use the answer to connect the concept back to a realistic production or interview scenario for 'Why does every executable Go program need a `package main` with a `func main()`?' ## Comparison / Tradeoffs | Aspect | Notes | | --- | --- | | Core idea | `package main` marks the package as producing a standalone binary rather than an importable library, and `main()` is the fixed entry point the Go runtime calls to start execution. | | Practical tradeoff | This is Go's equivalent of `public static void main` in Java or `if __name__ == '__main__'` in Python — a single, unambiguous entry point. |

Q: What's the difference between `go run main.go` and `go build`?

## Summary `go run` compiles and immediately executes the program without leaving a binary behind; `go build` compiles it into a standalone executable you can run later or ship. ## Longer Answer `go run` compiles and immediately executes the program without leaving a binary behind; `go build` compiles it into a standalone executable you can run later or ship. Reach for `go run` while iterating locally, and `go build` when you need a distributable binary. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview. ## Key Points - `go run` compiles and immediately executes the program without leaving a binary behind; `go build` compiles it into a standalone executable you can run later or ship - Reach for `go run` while iterating locally, and `go build` when you need a distributable binary - In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview - Use the answer to connect the concept back to a realistic production or interview scenario for 'What's the difference between `go run main.go` and `go build`?' ## Comparison / Tradeoffs | Aspect | Notes | | --- | --- | | Core idea | `go run` compiles and immediately executes the program without leaving a binary behind; `go build` compiles it into a standalone executable you can run later or ship. | | Practical tradeoff | Reach for `go run` while iterating locally, and `go build` when you need a distributable binary. |

Install Go, understand modules, and run your first program

Getting Started with Go

Go (Golang) is a compiled, statically typed language designed for simplicity, fast builds, and strong concurrency support. Once installed, go version confirms your setup, and go mod init <module-name> creates a go.mod file that tracks your module name and dependencies.

Your First Program

package main

import "fmt"

func main() {
    fmt.Println("Hello, Go!")
}

Every executable Go program starts in package main with a main() function as the entry point. Use go run main.go to compile and execute immediately, or go build to produce a standalone binary.

Key Tooling

go fmt formats code to the standard style automatically
go vet catches common mistakes before they become bugs
go mod tidy keeps dependencies in go.mod/go.sum accurate

Practice questions

What does `go mod init <module-name>` do, and when do you run it?

Answer

Summary

It creates a go.mod file that names your module and will track its dependencies — you run it once, when starting a new Go project.

Longer Answer

It creates a go.mod file that names your module and will track its dependencies — you run it once, when starting a new Go project. go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

It creates a go.mod file that names your module and will track its dependencies — you run it once, when starting a new Go project
go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
Use the answer to connect the concept back to a realistic production or interview scenario for 'What does go mod init <module-name> do, and when do you run it?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	It creates a `go.mod` file that names your module and will track its dependencies — you run it once, when starting a new Go project.
Practical tradeoff	go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first.

Why

Summary

go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first.

Longer Answer

go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
In an interview, relate 'What does go mod init <module-name> do, and when do you run it?' to implementation decisions, tradeoffs, and operational impact
Use the answer to connect the concept back to a realistic production or interview scenario for 'What does go mod init <module-name> do, and when do you run it?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	go.mod is the root of Go's dependency management — nothing else in the module system works without it existing first.
Practical tradeoff	In an interview, relate 'What does `go mod init <module-name>` do, and when do you run it?' to implementation decisions, tradeoffs, and operational impact.

Why does every executable Go program need a `package main` with a `func main()`?

Answer

Summary

package main marks the package as producing a standalone binary rather than an importable library, and main() is the fixed entry point the Go runtime calls to start execution.

Longer Answer

package main marks the package as producing a standalone binary rather than an importable library, and main() is the fixed entry point the Go runtime calls to start execution. This is Go's equivalent of public static void main in Java or if __name__ == '__main__' in Python — a single, unambiguous entry point. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

package main marks the package as producing a standalone binary rather than an importable library, and main() is the fixed entry point the Go runtime calls to start execution
This is Go's equivalent of public static void main in Java or if __name__ == '__main__' in Python — a single, unambiguous entry point
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
Use the answer to connect the concept back to a realistic production or interview scenario for 'Why does every executable Go program need a package main with a func main()?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	`package main` marks the package as producing a standalone binary rather than an importable library, and `main()` is the fixed entry point the Go runtime calls to start execution.
Practical tradeoff	This is Go's equivalent of `public static void main` in Java or `if __name__ == '__main__'` in Python — a single, unambiguous entry point.

Why

Summary

This is Go's equivalent of public static void main in Java or if __name__ == '__main__' in Python — a single, unambiguous entry point.

Longer Answer

This is Go's equivalent of public static void main in Java or if __name__ == '__main__' in Python — a single, unambiguous entry point. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

This is Go's equivalent of public static void main in Java or if __name__ == '__main__' in Python — a single, unambiguous entry point
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
In an interview, relate 'Why does every executable Go program need a package main with a func main()?' to implementation decisions, tradeoffs, and operational impact
Use the answer to connect the concept back to a realistic production or interview scenario for 'Why does every executable Go program need a package main with a func main()?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	This is Go's equivalent of `public static void main` in Java or `if __name__ == '__main__'` in Python — a single, unambiguous entry point.
Practical tradeoff	In an interview, relate 'Why does every executable Go program need a `package main` with a `func main()`?' to implementation decisions, tradeoffs, and operational impact.

What's the difference between `go run main.go` and `go build`?

Answer

Summary

go run compiles and immediately executes the program without leaving a binary behind; go build compiles it into a standalone executable you can run later or ship.

Longer Answer

go run compiles and immediately executes the program without leaving a binary behind; go build compiles it into a standalone executable you can run later or ship. Reach for go run while iterating locally, and go build when you need a distributable binary. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

go run compiles and immediately executes the program without leaving a binary behind; go build compiles it into a standalone executable you can run later or ship
Reach for go run while iterating locally, and go build when you need a distributable binary
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
Use the answer to connect the concept back to a realistic production or interview scenario for 'What's the difference between go run main.go and go build?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	`go run` compiles and immediately executes the program without leaving a binary behind; `go build` compiles it into a standalone executable you can run later or ship.
Practical tradeoff	Reach for `go run` while iterating locally, and `go build` when you need a distributable binary.

Why

Summary

Reach for go run while iterating locally, and go build when you need a distributable binary.

Longer Answer

Reach for go run while iterating locally, and go build when you need a distributable binary. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

Reach for go run while iterating locally, and go build when you need a distributable binary
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
In an interview, relate 'What's the difference between go run main.go and go build?' to implementation decisions, tradeoffs, and operational impact
Use the answer to connect the concept back to a realistic production or interview scenario for 'What's the difference between go run main.go and go build?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	Reach for `go run` while iterating locally, and `go build` when you need a distributable binary.
Practical tradeoff	In an interview, relate 'What's the difference between `go run main.go` and `go build`?' to implementation decisions, tradeoffs, and operational impact.

Open in the app to mark lessons complete, take notes and track your progress.