- Go (Golang) is a compiled language built by Google, and it's quietly become the backend favourite at Indian startups and fintech companies.
- You install it once, then run any file with a single
go runcommand — no separate compile step to remember. - Every Go project has a
go.modfile that tracks your module name and dependencies, similar topackage.jsonin Node. - Slices and maps are Go's everyday data tools — think of them as flexible lists and key-value stores.
- Functions can return a value AND an error together, and checking that error is basically a Go ritual.
- You don't need exceptions or try-catch here — Go just asks you to check
if err != nilevery single time.
What is Go, in one line, and why does everyone suddenly want it?
Go (people call it Golang too) is a language Google built because C++ was getting painful at their scale. It compiles down to one single binary, runs fast, and doesn't need a runtime installed on the server. That last part is why backend teams here love it. You build once, you ship one file, and it just runs — no JVM, no Node version mismatch drama in production.
Companies building payment systems, ride-hailing backends and API gateways in India keep reaching for Go because it handles thousands of requests at once without new a sweat, and the code stays readable six months later.
How do you install Go and run your first program?
Head to the official Go site, download the installer for your OS, and confirm it worked.
go versionNow make a folder, create a file called main.go, and type this in.
package main
import "fmt"
func main() {
fmt.Println("Hello, TamilTech!")
}Save it, open a terminal in that folder, and run:
go run main.goThat's it. No separate build step, no makefile. go run compiles and executes in one shot, which is perfect while you're still learning and testing small snippets.
How do packages, modules and go.mod fit together?
Every Go file starts with a package name. package main means this file can be run directly — it needs a func main() inside it.
Once your project grows past one file, Go wants a module to track everything. You set this up once per project:
go mod init github.com/yourname/helloThis creates a go.mod file that looks roughly like this:
module github.com/yourname/hello
go 1.23Think of go.mod as the ID card of your project. When you later add a third-party library with go get, that same file records which version you're using, so the same code builds the same way on your teammate's laptop and on the server.
How do variables, slices and maps actually work in Go?
Go is statically typed, but it lets you skip writing the type most of the time using :=.
package main
import "fmt"
func main() {
name := "Chennai"
var age int = 25
fruits := []string{"mango", "banana"}
fruits = append(fruits, "guava")
prices := map[string]int{"mango": 60, "banana": 40}
prices["guava"] = 50
fmt.Println(name, age, fruits, prices)
}A slice is basically your everyday list — it can grow with append, and you loop over it with range. A map is your key-value store, same idea as a dictionary in Python or an object in JavaScript, except Go enforces that keys and values stick to one type.
If you're coming from JavaScript, the one habit to drop is treating everything as loosely typed. Go will stop you at compile time if you try to put a number into a string slice, and honestly, that catches a lot of bugs before they ever reach production.
How do functions with multiple returns and the error-handling idiom work?
This is the part that surprises beginners the most. Go functions can return more than one value, and the second one is usually an error.
package main
import (
"errors"
"fmt"
)
func divide(a, b float64) (float64, error) {
if b == 0 {
return 0, errors.New("cannot divide by zero")
}
return a / b, nil
}
func main() {
result, err := divide(10, 0)
if err != nil {
fmt.Println("Error:", err)
return
}
fmt.Println("Result:", result)
}There's no try-catch here. Go just hands you the error as a normal value, and the convention is you check it right away with if err != nil. It looks repetitive at first, but once you're reading someone else's Go code, you'll thank this pattern — you can see exactly where things can fail, line by line, without hunting for a hidden catch block three files away.
Which mistakes get beginners into trouble?
Ignoring the error return is the big one. People write result, _ := someFunc() just to make the code compile, and then wonder why things break silently in production later. Always ask what that underscore is hiding.
Forgetting that Go is picky about unused variables and unused imports is another classic. The compiler simply refuses to build if you import fmt and never use it — annoying on day one, genuinely useful by week two.
Mixing up := and = trips up almost everyone coming from Python or JS. Use := only when you're declaring a new variable; reuse = when you're just assigning to one that already exists.
And one more — treating slices like arrays with fixed size. A slice backed by an array can behave unexpectedly when you pass it between functions and both sides modify it. Read up on slice capacity once you're past the basics.
Where is Go actually used at Indian companies, and does it come up in interviews?
Fintech and payments backends in India lean on Go heavily because it handles concurrent requests cleanly using goroutines — lightweight threads that don't eat memory the way OS threads do. Several Bengaluru and Chennai-based startups building UPI-adjacent services, logistics APIs and internal microservices list Go as a core requirement in backend job postings.
In interviews, expect questions around goroutines and channels for concurrency, why Go doesn't have exceptions, how error handling works, and basic questions on slices versus arrays. If you can explain why a function returns (value, error) instead of throwing, you're already ahead of a lot of candidates.
What should you practice now?
Write a small program that takes a slice of numbers, loops through it, and returns the sum along with an error if the slice is empty. Then add a map that stores each number's square, and print both. Keep the error-checking habit from the start — it's the one thing that separates Go code that looks fine from Go code that's actually production-ready.




Comments (0)
Be the first to comment!