6 ms·
Ah yep! I should’ve given a Go example. In Python we use decorators because it’s what’s in fashion, but in Go and TypeScript you just create a `NewTask()` e.g.
by mrkaye97 2mo ago
Ah yep! I should’ve given a Go example. In Python we use decorators because it’s what’s in fashion, but in Go and TypeScript you just create a `NewTask()` e.g. where you pass a function (as well as other args), and it returns something with e.g. a `Result` method. And that result method, which is generic, is the thing that’s really nice to have typed.
Agreed codegen works fine here too by the way, but it feels kind of clunky to me (it’s something I don’t love about Go, although I know it’s also an important part of the ecosystem and is popular).
- torginus 1mo agoI'm just saying that this Task[T] pattern is completely alien to Go. If you want to have one-off ansynchrony, then just write it synchronously and start your work on a goroutine. If you wanna do batch processing, use channels. For all intents and purposes, I would say 90% of IRL usage of generics is either this Task[T] pattern, collections or map() style array processing functions. Go had a solution for all 3 of these, that didn't involve generics. I'm in a fortunate position that I get to pick the language I work in for a lot of my work (from a reasonable selection). So if I want to write Go, I'll rather do it idiomatically, otherwise I'd pick something else. Which should be the case for everyone, and language designers should take heed. The 'we want the Java/Python/Go/JS audience' sentiment has ruined many a language, as they've turned themselves into the same mediocre language that has all the features everyone else has.