Go: statically typed or dynamically typed next?

21 Tem 16:14

Go’s static typing is one of those things that initially felt like a speed bump but now I can’t live without. When I first jumped from Python to Go, the compiler yelling at me for “unused variables” or “wrong types” was annoying—until I realized how much faster debugging gets when errors are caught at compile time rather than runtime. Most days I appreciate the explicitness, especially in larger projects where tracking down runtime type mismatches used to eat hours. The only time it irks me is when I’m prototyping a small utility where dynamic typing would save me from writing boilerplate, but even then the payoff in maintainability kicks in fast. Nil handling in Go is a love-hate deal. It’s simple and predictable, but yeah, the lack of a real nullable type (and those “nil pointer dereference” panics) forces you to be disciplined—something you can skip in languages like JavaScript where null is just another value. I’ve grown to prefer Go’s approach over time because it keeps the codebase honest, even if it means writing a few extra checks.