271–280 of 614 posts
Honestly I think this will make the overall programming experience worse.
Earlier quoted context omitted.
I’m glad you brought this up because I agree Rob pikes quote about go being simple for average programmers has been very provocative, because it’s been interpreted as “Google devs are too stupid for a good language like Haskell, so if you use go it’s because you’re stupid too”. I’m partial to a different interpretation, that’s more like “go doesn’t require as much thinking as Haskell, so you can use your thinking for…
> I’m partial to a different interpretation, that’s more like “go doesn’t require as much thinking as Haskell, so you can use your thinking for the problem you’re trying to solve instead of the language”. I think you're being too charitable here. Rob Pike is a very smart and articulate guy. If he had wanted to say "go doesn’t require as much thinking as Haskell, so you can use your thinking for the problem you’re try…
Now time to update interface{} usage and shift to any . $ gofmt -r 'interface{} -> any' -l **/*.go Replace -l with -w to write.
Earlier quoted context omitted.
For json marshalling, I would defer to the underlying type's marshalling if it's present, and return `null` otherwise.
I think this is appropriate in some cases but not others. For example how does the JSON value distinguish between `Some(null)` and `None`?
Earlier quoted context omitted.
> I don't mean to disparage the wonderful work of the lo developers but, > this is in many ways what I feared generics would bring. What is, anything in particular about that "lo" library? Just the way it uses generics, or moreso that it's yet another library to learn to be effective? Can't argue with the latter, but as far as the former goes, I think that looks quite reasonable. It's very explicit, there's no magic…
Efficient map/filter/reduce chaining basically requires JIT to fuse the operations and/or a GC prepared to deal with huge amounts garbage. In Go, filter(h, map(g, filter(f, a))) will be immensely slower than the equivalent for loop.
Also I would not be surprised to see JIT-like behavior from go tooling, first party or otherwise, if that sort of approach takes off.
In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional
Optionals without do notation will be a bad time.
I've used optionals in many languages, and this is the first I've heard of it. What else do you really need except map and... flatMap (aka `then` aka `and_then` aka `>>=` aka `bind`).
This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…
This comment has the tone of being genuinely inquisitive, yet it mostly comes up with negative and depraved reasons for as to why someone one might dislike $lang. - Rational reasons (frustrations with the language design) are briefly acknowledged but then some reason left by the wayside - It is suggested that people don't have principled objections to $lang; they will "latch onto" something else if $misfeature is fix…
Earlier quoted context omitted.
> Honestly, one of the biggest things that drives me away from Go isn't the lack of features, it's this condescending attitude that comes from so many people who espouse Go. I could say the same about many of Go's critics, but I don't because that wouldn't be constructive. Rather than taking undue offense at my comment, why not articulate a counterexample to prove that there are valid reasons why a person (rather tha…
> simpler, more concrete, more standard code. All three of these things are subjective. > in so many conversations I've had with Go critics esp over generics, the conversation eventually terminates at some variation of "Go forces me to think about programming differently than I'm used to" At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.
Not really. They aren’t formally defined, but there’s pretty wide consensus even among Go detractors about these qualities.
> At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.
Not when there are plenty of people willing to think differently and reap the benefits.
This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…
people hate Go because Go is unapologetically designed from the framing of programmers being members of a labor class having differing levels of expertise. It's not the design itself; it's the design goals themselves that people are opposed to. This Rob Pike quote gets bandied around in these discussions: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, f…