5 ms·
I've been writing Go full-time, professionally for around 4 years now. Backend software, mostly distributed stuff, tools and services - the bread and butter of
by q3k 6y ago
I've been writing Go full-time, professionally for around 4 years now. Backend software, mostly distributed stuff, tools and services - the bread and butter of what Go's designed to be good at. On the side, I occasionally write some Rust, Haskell, and other 'good' languages.
I have kept a counter of many times I've told myself, over the past years, 'I wish Go had generics, this would really make my life easier right now'. It's currently at 5.
In my experience, the supposed issue of a lack of generics is _extremely_ overblown with regards to real world use. Sure, it would be nice to have them. I would've really liked them to exist a month ago when I was writing a generic container. But they're not going to make the language that much better for me, and there's always going to be more things PL people lust after (usually the next candidate would be GADTs, “Go does not have algebraic data types!” coming to HN comments very soon).
- rob74 6y ago> there's always going to be more things PL people lust after How about non-nullable types?
- q3k 6y agoSure, put that on the pile labeled “things that sometimes bother me, but I forget they're even an issue when I talk about Go with others”, next to generics.
- morelisp 6y agoAs a counterpoint: I also write Go in this same space. I like Go - I find most of its design goals align closely with my personal preferences (avoidance of syntactic noise, fast compile times, right-sized standard library, sufficient control over memory without having to worry about memory safety). If I kept a similar counter for the past 3 years, it would be at least five per day. Every time I `return x, err` and it's not a true tuple - and it almost never is - I wish I was returning an `Either<X, error>`. That's constant. Every time I use atomic.Value (often) or sync.Pool (less often) or sync.Map (almost never because I end up rolling my own stupid map+mutex). 90% of the time I want to say a pointer can't be null. 100% of the time I want to handle optional JSON or SQL fields. Fairly often, like > 30% of the time, when wrapping serdes or DTO conversions around data streams. I don't believe the level of generics required to support these use cases requires compromising the other goals of Go. The deficiency should have been obvious as soon as they introduced `sync.Map`.
- s-video 6y ago>Every time I `return x, err` and it's not a true tuple - and it almost never is - I wish I was returning an `Either<X, error>`. I can't imagine having this thought every single time. I don't want to sound harsh, but I don't know how else to ask this: can't you get over it?
- morelisp 6y agoTurning off my "how should I design this code well?" filter would probably remove the little satisfaction I still get from my day job. Coworkers and customers would likely not be too happy either.