161–170 of 614 posts
Hopefully generics will help make better libraries for Graphql. Existing libraries resorted to code generation a lot.
guess what generics is in a lot of languages? code generation! the files just aren't saved to disk.
IIRC on a podcast I seem to recall hearing that it was implemented this way for Go, at least for the prototype, and it seems likely to me that it is also done this way in production, but not with textual code.
Now Go has everything I need in a programming language!
err := h(cond(x) ? f(x) : g(x))
var temp T
if cond(x) {
temp = f(x)
} else {
temp = g(x)
}
err := h(temp)
Earlier quoted context omitted.
I would suggest that the core complaint is with the lack of ability to create abstractions, which leads to writing a lot of boilerplate. Which in turn makes Go code quite hard to read for anyone who thinks about programming from a top-down perspective doesn't for example want to have to decipher loop indexes to determine that the code is doing a .filter().map() operation.
I disagree, Go is easier to read than most modern languages, it's easier because it has a few keyword and did not add major features in the last 15 years. I can't say the same for Java / C#, Rust / C++ etc ...
Complexity can not generally be decomposed into smaller parts.
Now Go has everything I need in a programming language!
Not for me. There is no ?: ternary operator. Having to write 6 additional lines of code for each tiny conditional sucks. It's not frequent, I think I've only had a single case in a few years where I had difficulty working around, but when it happens - it's not fun. err := h(cond(x) ? f(x) : g(x)) vs var temp T if cond(x) { temp = f(x) } else { temp = g(x) } err := h(temp) Hopefully, this can be improved with generics…
Ken Thompson added ?: to B / C and then he took it from us in Go due to the wisdom he gathered in between.
Earlier quoted context omitted.
No one meaningfully "requires generics", people are just reluctant to set their ego aside and learn a different approach. Some use cases may benefit from generics, but even then "require" is too strong.
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 don't need to invest in a language whose community is so hostile. If you wanted to be persuasive or helpful, you could try explaining what the other approaches to work around lacking generics might be , rather than just insulting people for being…
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 than a use case) might require generics?
> If you wanted to be persuasive or helpful, you could try explaining what the other approaches to work around lacking generics might be, rather than just insulting people for being unable to figure out on their own how to avoid copy/paste spamming their codebase.
Because these are already well-understood and have been debated to death. Instead of .map().filter().flat_map().reduce() you use a simple for loop. Instead of `LinkedList` you use `type List struct { Item ItemType; Next List }`. The thing that we generally aren't* agreed on is whether those extra characters are actually the end of the world versus the benefits associated with simpler, more concrete, more standard code.
Anyway, I wasn't "insulting" anyone, I was describing Go critics' objections in roughly their own terms (i.e., 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").
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…
> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? I coded primarily in Go at work for several years, although that was several years ago. I understand that package management and now generics have changed in major ways since then. But at the risk of being out of date, here are some language-level complain…
Hopefully generics will help make better libraries for Graphql. Existing libraries resorted to code generation a lot.
> Existing libraries resorted to code generation a lot. guess what generics is in a lot of languages? code generation! the files just aren't saved to disk. IIRC on a podcast I seem to recall hearing that it was implemented this way for Go, at least for the prototype, and it seems likely to me that it is also done this way in production, but not with textual code.
As a developer now we dont have to bother about codegen.
Earlier quoted context omitted.
I see where you come from with those super smart one liners (guilty of it when I started programming). But sometimes, you can do something nicely in one line instead of three or four, and it makes it easier to parse.
I agree, but those one-liners win by only a little bit when they do win (e.g., it's only a little easier to read foos.map(...) than it is to read the equivalent for loop) but they lose by a lot when they lose (it's a lot harder to read .map(...).filter(...).flat_map(...).reduce(...) than the equivalent for loop). Generics tend to win by a lot in very specific, rare cases--so I appreciate that Go will have better supp…
I hope open source Go code in the wild remains easy to read and understand. Generics look cool, despite this possible downside.
Hopefully generics will help make better libraries for Graphql. Existing libraries resorted to code generation a lot.
> Existing libraries resorted to code generation a lot. guess what generics is in a lot of languages? code generation! the files just aren't saved to disk. IIRC on a podcast I seem to recall hearing that it was implemented this way for Go, at least for the prototype, and it seems likely to me that it is also done this way in production, but not with textual code.
In particular, a single expansion is shared for all pointer types.