i spent most of my career in java and typescript where abstraction is basically a competitive sport. every problem gets an interface, a factory, a strategy pattern, maybe a decorator if you're feeling fancy. half the codebase is plumbing for the other half. you read it and you can feel the cleverness in every file
started writing go for a side project last year and the language just kept saying no. no inheritance, no magic, no generics for most of its life, no clever metaprogramming tricks, no DI containers wired through annotations. just structs, interfaces, functions. at first it felt limiting in a frustrating way, like trying to write with one hand
then about a month in something flipped. i stopped trying to do the clever java thing and started doing the boring go thing, and the code got way easier to read. and not just my code, every other go codebase i've looked at since has been faster to navigate than equivalent java or typescript projects. theres usually one way to do something, you find it, you move on
the part i didnt expect is that this changed how i write typescript at work. im still doing typescript daily and i still use the language's features, but i reach for abstractions way less now. used to be id see a function thats called twice and start thinking about extraction, interfaces, generic constraints. now i let it stay duplicated for a while and most of the time it never actually needs to be abstracted, the duplication was fine
(also the readable-6-months-later thing isnt a small benefit, its enormous. i opened a go service i wrote in march and i was up to speed in like 20 minutes. that has not been my experience with my own typescript code)
i still think typescript is the right call for most of what i build. type system, ecosystem, frontend interop, all of that matters. but go changed how i think about complexity in a way that stuck. sometimes the best tool is the one that wont let you be clever, even if you only use it occasionally
