3 ms·
> it’s purely a count of newline characters per my original point It's not simply that. Compare in golang: var res int if <some condition> { r
by gher-shyu3i 5y ago
> it’s purely a count of newline characters per my original point
It's not simply that. Compare in golang:
var res int
if <some condition> {
res = foo()
} else {
res = bar()
}
to what other languages offer like
let res = if <some condition> { foo() } else { bar() };
The golang version is both more verbose, and more error prone.
These things add up. Let alone how it takes dozens of lines of code in golang to implement what essentially is a sequence of map/filter/groupBy. The logic in languages that support the latter immediately stands out, whereas in golang you have to read it line by line to figure out what's going on.
What's ironic is that even with the proposal to add some of those to golang, they're still going to be vastly inferior to the implementations we have in Java/C#/Scala/etc. because they don't compose in golang, and are still going to be very awkward to read.
- throwaway894345 5y agoI definitely like the ternary version, but to my original point I think people make too big a deal about it. With respect to map/filter/groupBy, I rarely find that solutions are clearer when expressed as chains of iterator combinators like these rather than a single for loop, especially when you're dealing with multiple collections and dealing with errors (short-circuiting). I'm writing a lot of Rust lately, and I definitely find myself dealing with this a lot in practice.