4 ms·

I used to love Go and its simplicity. It's still my least disliked backend language. But after more than a decade of using it nearly full time (but not exclusiv

I used to love Go and its simplicity. It's still my least disliked backend language. But after more than a decade of using it nearly full time (but not exclusively), I've fallen out of love with it. I want sum types. I want non-nullable types. I want enums (preferably, based on sum types). I'm okay with the explicit error handling, but would be fine with Rust style error handling too. Having these features would change the language so much that you'd probably want to re-implement the stdlib, so it probably won't happen. Surprisingly though, while I absolutely love Go's concurrency model, being able to kick off new goroutines with a dedicated "go" keyword and special channel operators have not been a big deal at all. It's usually abstracted away by some library, or you set it up once in your application and never touch it again.

tankenmate 2y ago
In my opinion your comments on Go concurrency misses a point, the fact that you do it once "and never touch it again" is a very very strong selling point, it probably means it was very well designed; not a weakness but a strength.
- lordofgibbons 2y ago
  I didn't mean it's a weakness. I mean it's not as amazing of a selling point as it was made out to be when the language first came out. If you're using something only rarely and not touching it again, there isn't much of a difference between go.New(func(){}) from some "go" package, and go func(){}. To reiterate, I'm not against the "go" keyword. It's whatever ¯\_(ツ)_/¯
praptak 2y ago
> But after more than a decade of using it nearly full time (but not exclusively), I've fallen out of love with it. I believe this is true for anyone and any language. Spend a few years in a language on stuff that you have to do (which is the main differentiator between work and hobby projects) and two things happen: the benefits are taken for granted while the warts are magnified fivefold. The corollary to this is the quote "I won't use something until you tell me why it sucks" (can't find source). If you use something long enough you know the ways it sucks. This makes your criticism more valuable than enthusiastic praise from a hobbyist.

tankenmate 2y ago

In my opinion your comments on Go concurrency misses a point, the fact that you do it once "and never touch it again" is a very very strong selling point, it probably means it was very well designed; not a weakness but a strength.

lordofgibbons 2y ago
I didn't mean it's a weakness. I mean it's not as amazing of a selling point as it was made out to be when the language first came out. If you're using something only rarely and not touching it again, there isn't much of a difference between go.New(func(){}) from some "go" package, and go func(){}. To reiterate, I'm not against the "go" keyword. It's whatever ¯\_(ツ)_/¯

praptak 2y ago

> But after more than a decade of using it nearly full time (but not exclusively), I've fallen out of love with it. I believe this is true for anyone and any language. Spend a few years in a language on stuff that you have to do (which is the main differentiator between work and hobby projects) and two things happen: the benefits are taken for granted while the warts are magnified fivefold. The corollary to this is the quote "I won't use something until you tell me why it sucks" (can't find source). If you use something long enough you know the ways it sucks. This makes your criticism more valuable than enthusiastic praise from a hobbyist.