`main.go` is not mandatory — it’s just a common convention. what *is* required for an executable go program is a `main` package containing a `func main()` entry point, regardless of the filename.
In Go, the build and execution system doesn’t enforce any specific filename — only structural and naming requirements at the package and function level. As long as your source file declares package main and defines a func main() with no arguments and no return values, go run, go build, or go install will treat it as an executable program.
For example, this file named api-server.go is perfectly valid:
package main
import (
"fmt"
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello from Go API!")
})
fmt.Println("API server starting on :8080")
http.ListenAndServe(":8080", nil)
}You can run it directly with:
go run api-server.go
✅ Works without main.go.
✅ No need to rename — Go tools scan all .go files in the directory (or specified paths) for the main package and main() function.
⚠️ Important: If you have multiple main packages in the same directory (e.g., server.go and cli.go, both with package main), go run . will fail with “multiple main packages”. Use go run server.go explicitly to avoid ambiguity.
Also note: For larger projects, especially web APIs, you’ll often separate concerns — e.g., main.go for bootstrapping, handlers/, models/, routes/ in other packages. While main.go remains idiomatic for clarity and tooling expectations (e.g., IDEs, CI linters), it’s purely a convention — not a language or toolchain requirement.
In summary: choose filenames that reflect intent (api.go, cmd/server.go, main.go) — but remember, Go only cares about package main + func main().
