Go Programming

‣

Origin and Philosophy:

Go was developed at Google by Robert Griesemer, Rob Pike, and Ken Thompson and was first released in 2009.

It was designed to be statically typed, efficient, and easy to read and write.

Syntax:

Go has a C-like syntax but is designed to be simpler and more readable.

Semicolons are generally not required at the end of statements.

Curly braces {} define blocks of code, and indentation is not significant.

Running Code in Go

Move to the directory :

→ 1st way: go run main.go

→ 2nd way: go run .

→ 3rd way: build binary file → go build . → ./folder name

🤖

Variable

🛤️

Array, Slice & String

🤔

Condition, Loop, Switch

⌨️

INPUT & OUTPUT

📏

Math Package & Memory

Map

Package Naming Conventions

✈️

Concurrency connectivity and High performance Apps

🌐

Context in Go

🗄️

Working with Files and the Web

Design Pattern

Question 1: Common Mistakes in Go

🚫 Common Mistake Sample Code Folder Structure

rest-api/ ├── go.mod ├── main.go └── handlers/ └── user.go

Trying to import your own code like this in main.go:


import "rest-api/handlers"

...without setting up a Go module (go.mod) — Go thinks you're trying to import from GOROOT, which causes this error:


cannot find package "rest-api/handlers" in GOROOT

🔥 Fix: Use go mod init so Go treats your project like a real module.

Terminology and Gobasics

Command	Purpose
`go mod init`	Start a new Go module (creates `go.mod`)
`go get`	Install or upgrade a dependency
`go mod tidy`	Clean up dependencies (add missing, remove unused)
`go.sum`	Ensures module security & integrity (auto-managed)
`go.mod`	Your module definition (modern system)
`GOPATH`	Your workspace for Go projects (old system)
`GOROOT`	Location where Go is installed

Question 2: 📦 What is `GOPATH`?

GOPATH is another environment variable that was used before Go modules (go.mod) became the standard in Go 1.11+.

🔙 Before (Old System - Pre Go 1.11):

All your Go code had to live inside one workspace folder (GOPATH).

You had folders like:


$GOPATH/
├── bin/     → compiled binaries
├── pkg/     → compiled packages
└── src/     → all your Go code here

To use or import any package, it must be under $GOPATH/src.

Example structure:


$GOPATH/src/github.com/abhishek/rest-api/main.go

✅ Now (Modern System - Go Modules):

Since Go 1.11, we use Go modules, and you can write Go projects anywhere on your machine — not just inside GOPATH.

Now you do:


go mod init rest-api

✅ This:

Lets you place your code outside GOPATH

Supports versioning, dependencies, and cleaner project structure

Works better with Git, Docker, CI/CD, etc.

🛠️ So is `GOPATH` dead?

Not completely — it’s still used by:

go install → stores binaries in $GOPATH/bin

Some very old tools or legacy projects

But for everyday development, especially new projects, you don’t need to worry about it.

🔄 Comparison Table

Feature	GOPATH	Go Modules (`go.mod`)
Introduced	Before Go 1.11	Go 1.11+
Folder restriction	Must be inside `$GOPATH`	Can be anywhere
Dependency mgmt	Manual (`go get` only)	Automatic via `go.mod`/`go.sum`
Versioning	❌ No	✅ Yes
Recommended now?	❌ No	✅ Yes

Question 3: GOPATH vs GOROOT:

Feature	GOROOT	GOPATH
What it is	Where Go itself is installed	Where your own Go projects, binaries, and dependencies live
Who sets it	Usually set automatically when you install Go (you rarely touch it)	You set it (or use the default) to organize your Go workspace
Example	`/usr/local/go` or `C:\Go`	`$HOME/go` or any custom folder you prefer
Contains	Standard library, compiler, Go tools	Your code (`src/`), compiled binaries (`bin/`), and downloaded packages (`pkg/`)
When to modify	Only if you manually build Go from source	Often — especially when you work with multiple projects
Default (if unset)	Installer sets it	`$HOME/go` by default since Go 1.8