Why modules first
Your service starts as a module. A module is the unit Go uses to track your packages, dependencies, and Go version.
For this track, your final repo must be easy for a recruiter to clone and run. A clean go.mod file is the first proof that your project is a real Go project, not loose files.
Remember this
Start every Go service inside a module, before writing handlers or adding packages. The go.mod file is the project’s dependency record.
Create the project
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
mkdir go-fast-service
cd go-fast-service
go mod init github.com/YOUR_USERNAME/go-fast-serviceFirst runnable file
Keep the first file boring. The goal is to prove the module runs. HTTP routes, types, errors, and concurrency come later in this track.
This program prints one line and exits. That is enough to check your Go install, folder, and module setup.
package main
import "fmt"
func main() {
fmt.Println("go-fast-service is running")
}Run and build
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 4 done
go run .
go build
./go-fast-servicePick a stable module path
If your repo will be public, choose the final repo path now, like github.com/yourname/go-fast-service. It makes imports clear later when your project grows into multiple packages.
If you are just testing locally, a temporary path works. But change it before submitting your HackIndia project.
Do not skip go.mod
Beginners sometimes write main.go first and only fix modules after adding dependencies. That causes messy imports and confusing setup steps.
Also remember that go run is not the same as shipping. It compiles and runs during development, but it does not leave you with the final executable. Use go build for that.
Do this now
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done