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.
It'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.
Exactly. 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.
Go 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 ?
The 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.
I 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.
With generics, reading and reasoning about code becomes [even] more challenging.
Personally for me, at this juncture I'm finding that for new projects I might just as soon spring for Java or maybe even prefer it to Go. For the straightforward mvn-style dependency management, if nothing else.
It's all moot now, though. There's no going back, this puppy is cooked!