7 ms·
> Go gives you less choice, and thus projects are more similar, and thus I suspect legacy Go code adds will be easier to maintain. Side note, Go gives you less
by adkadskhj 5y ago
> Go gives you less choice, and thus projects are more similar, and thus I suspect legacy Go code adds will be easier to maintain.
Side note, Go gives you less tools - but not often less choice. Eg if you need to iterate and map, you still need to iterate and map. Go didn't change your application needs simply because it inhibited your ability to execute. Instead, you do what you need despite Go. Which often amounts to repeated functions, loops of loops, functions in loops to use defers, etcetc - you reinvent wheels. Go didn't reduce the application complexity, it just gave you less tools to solve it.
While some argue less tools is easier. I argue less tools often results in poor, messy abstractions. Those are traits that fight maintenance more than ease it, in my mind.
By the end of my Go tour, i was tired and wanted off the simplicity ride. The language was a burden, to me.
- deleted 5y ago[deleted]
- amscanne 5y agoUltimately you’re expressing an anti-simplicity sentiment, which is well aligned with the parent post. Clever abstractions may appear to reduce the “burden”, but they are often fashionable and add cognitive overhead. Go does indeed often force you to do things the “dumb” way (see your own examples) but the thesis is that this is easier to understand and maintain over time.
- BiteCode_dev 5y agoI'm sure somebody said something like that when all those kids started to the clever abstractions that were functions instead of doing things manually in assembly. Simplicity!
- carlhjerpe 5y agoSome developers don't want to use the ternary operator because it's "too complex". I believe there's a middle ground to be found where further abstractions add complexity rather than reduce it. Where that middle ground is, I don't know.
- wtetzner 5y agoThat’s a strange definition of complexity. I can see people avoiding the ternary operator because the syntax is hard to read, but it’s no more complex than `if`.
- throwaway894345 5y agoThis is just vapid snark. Of course some abstraction is helpful, but there's also a point at which abstraction impedes understanding. Ergo, we're debating where the "sweet spot" is. Note also that we can say "Go is the sweet spot for most applications" while also acknowledging that it makes certain kinds of programming difficult (e.g., writing a compiler). It's okay to recognize tradeoffs; there's no need to oversimplify or otherwise engage dogmatically.
- wtetzner 5y ago> Ultimately you’re expressing an anti-simplicity sentiment I disagree. First, making a language simple doesn’t make programs simpler, and often does the opposite. I’m also not sure I buy the idea that Go is actually simple. It lacks a lot of features, but that’s not the same as being simple. I mean, it supports runtime reflection, which seems more complicated than features like traits or generics. And code using reflection is never simple.
- pjmlp 5y agoExactly, people advocate that there are those shipping stuff in Go, naturally there is the case. Anyone that had to work with Assembly in production was happy to have any kind of high level language to start with.