9 ms·
i actually don't think the Go version is bad. I can very clearly see what is happening and I can also do something with the error
by bresc 10y ago
i actually don't think the Go version is bad. I can very clearly see what is happening and I can also do something with the error
- vvanders 10y agoNothing keeping you from using the same approach(or even some of the really nice mapping functions), it just lets you get rid of the boilerplate that you see there when you want to.
- zalmoxes 10y agoThe difference is that if I thought the Go style is easier to read/debug I couldn't prevent you from writing it in the complex one-liner way. The go way is a little more verbose/uglier but we are both going to do it in the same way as will the 30 other developers working on the project.
- Etzos 10y agoI don't think it's fair to say that the option Rust gives you is more complex. It's a syntactic convenience which reduces the chance of a someone typing a mistake in the longer form. Regardless of how simple the language, there is always more than one way to do things. Rust is just giving you the choice to eliminate a lot of boilerplate if you so desire. In reality most Go users will opt to use the style mentioned above instead of something more verbose/complex and most Rust users will likely opt for the new ? operator.
- cpuguy83 10y agoThe only thing bad about Go's version (other than the usual repetitive code complaints) is it's easy to ignore (ie forget) to handle an error. And really much of the error handling in Go is by convention (ie, `if err != nil { return nil, err }`) rather than actual language semantics. Honestly it would be nice to be able to always return the error (without special macros or symbols) if there is one unless I've explicitly setup a handler block.
- brandur 10y agoI've also found (the hard way) that it's possible to mistype a conditional as `err == nil` when it should be `err != nil`. It's a really dumb mistake, but will waste time as you track it down (without the compiler's help).
- stouset 10y agoNot to mention forgetting to `return` nil, err. If you just type `nil, err`, you don't handle the error and nothing complains. Oops.
- iand 10y agoEr... https://play.golang.org/p/QyQVFfPIhx https://play.golang.org/p/QyQVFfPIhx
- stouset 10y agoIs this a recent change? I've with 100% been bitten by this before, repeatedly, and the go compiler did nothing to warn about it.
- masklinn 10y agoMaybe for a side-effecting function which would only return an error? edit: nope, fails with "err evaluated but not used".
- stouset 10y agoI'm genuinely stumped. If they've fixed this, that's fantastic because I have absolutely shipped code with this bug to a production environment.
- iand 10y agoI've been working with Go for 4 years and I've not encountered it. Perhaps there was an edge case where it was allowed, but I don't recall it.
- jhomedall 10y agoYou only have to learn what '?' does once. You have to write (and more importantly, read) the Go boilerplate every time.
- PopsiclePete 10y agoSame here. I value the readability more over the "oh no it's 20 extra key-strokes" drawback.
- stouset 10y agoWhat? In the Rust one, there's no code to read. How is this somehow less readable than the Go version, where there's dozens of lines of code to read that have nothing to do with the task you're trying to accomplish, that are all completely identical?
- cpuguy83 10y agoProbably from the perspective of someone who doesn't know either language, go is easier to infer what is happening. Ultimately once you are actually writing code it doesn't matter.