4 ms·
Same for me. I tried really hard to enjoy Go, but it became an incredibly frustrating experience. The language itself was frustrating to me in many of the ways
by nevir 11y ago
Same for me. I tried really hard to enjoy Go, but it became an incredibly frustrating experience.
The language itself was frustrating to me in many of the ways outlined in the article.
The community was similarly frustrating.
One anecdote that really stuck with me was when enquiring about explicit language support for the error handling pattern. E.g.:
f, err := os.Open("foo.bar")
if err != nil {
log.Fatal(err)
}
It is something you perform extremely frequently, and it takes up an incredible number of lines of code. The response from the Go team was (paraphrased) "We don't see the value in making this pattern more terse when you can just write a macro for your editor to automate it".
- vardump 11y agoWell, as a mainly C++ programmer, I'd trade exceptions for that any day. Much easier to understand what is going on, no need to find out if something in the call graph of the method I call throws or not. Also error handling code is where the error occurs, not some completely different place. Properly handled exceptions aren't any less code anyways. Unless you can just drop everything on the floor.
- nulltype 11y agoI think you mean you'd trade exceptions for that.
- vardump 11y agoFixed.
- acjohnson55 11y agoAs a Scala coder, I'd say you can have it both ways by encoding the result as type that can have success or failure cases. No fancy control flow needed, just pattern matching.
- nevir 11y agoYeah, and you can implement that in C++ very easily, too. Googlers might recognize StatusOrReturn, and similar macros.
- masklinn 11y agoYou don't get pattern-matching though, and I expect the implementation would be somewhat gnarly without native tagged unions. At least now that C++ has lambda expressions you can get all the nice HoF so the usage side of the equation has become less troublesome. Still, a far cry from data Result a b = Err a | Ok b
- gendoikari 11y agoAnd this is a clever response if you understand their point: messing with the language it's rarely the correct answer. Do you want to remove some code? How about a function? How about hiding boring details behind more elegant objects? How about using a macro in the editor? And so on... The answer is not (from their perspective) "put some shit in the language". The problem with Go is that is very idiomatic. If you want to work with Go you need to learn its way, and somehow you need to accept the trade-offs behind its design. If you do not see any advantages in any way, probably it's not the right tool for you, and that's ok. No problem at all.
- fenollp 11y agoThis is exactly the pattern that Erlang handles the best: 1. Expect you call to os.Open to not fail 2. Then do stuff with it 2bis. Or the running process will crash, the error logged, bad state won't mess up the flow and a dev can always hot-patch it