4 ms·
I spent 4 months in '21 rewriting a golang backend to properly use channels for concurrency. The previous developers did misuse it and left a steaming pile for
by alophawen 5y ago
I spent 4 months in '21 rewriting a golang backend to properly use channels for concurrency.
The previous developers did misuse it and left a steaming pile for me to find.
However contracting pays well, so I don't care.
You might want to reflect on your reasons for jumping ship because your tooling gained a new feature. Sound's rather irrational to me.
- metadat 5y agoIt's more about the direction and trajectory, Go used to be fun for me but the appeal has waned. Sounds like it's just me.
- alex_sf 5y agoIt's less that it gained a new feature, and more (the fear at least) that it made a change for the worse. Avoiding updating to a new version of OSX that stabs you in the face is a reasonable thing to do, despite it being a new feature.
- baby 5y agoExactly. I work with rust and ocaml all day long, but reading a Golang codebase in contrast has always been such a pleasure because it’s just so easy to read. I hope generics don’t change that. There was really nothing like Golang out there.
- lenkite 5y agoGo already had generic structures anyways. Go maps supported generics. Or did you always use map[interface{}]interface{} everywhere for the purity of your anti-generics position ?
- alex_sf 5y agoThe built-in types that supported generics were limited to the essentials; slices, arrays, maps, etc. Those basic building blocks were obviously sufficient to allow Go to reach the level of success it has. It's not an argument to allow for unlimited generics.
- alophawen 5y agoI think this line of reasoning is detrimental for yourself: - noone is forcing you to use generics in your go programs. - if you are running outdated OS because you don't like some UX change, you might as well consider changing OS.