7 ms·

Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to

Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables, well that's just a different language, and we'll just end up on the hedonistic treadmill towards another Java. No thank you.

pjmlp 8y ago
Languages are products as well, either they grow to fulfil the needs of their customers or their fade away.
- ilovecaching 8y ago
  What if the need is for a small language without generics?
  - pjmlp 8y ago
    If there was such a need, the languages without them would still have a major market, which isn't the case. Naturally those of us coding since the early days have experience with programming languages without generics support, yet a large majority eventually adopted generics. Even C has minimal generics support since C11.
  - bluejekyll 8y ago
    In what context would “need” a language to not have generics? I can understand not “wanting” generics to keep it simpler, but I can’t see that as a “need”. Personally, in any typed language, I want generics, not having them feels very limiting.
bdamm 8y ago
Isn't the premise of Go that a team sufficiently large enough will eventually act as a collective idiot in terms of code maintenance? I'm looking forward to some real research on the question of whether Go's design choices have had real world results in improving productivity with supersize code bases.
- diegs 8y ago
  Anecdotally (n = 10 or so) every Go codebase I've worked on has devolved into a trash fire, so no. Turns out collective idiots can write horrible systems in any language.
- EricBurnett 8y ago
  (Disclaimer: at Google) My team has ~200k lines of Go code and I'm exceedingly happy with the state of the codebase. Having previously maintained a C++ codebase of similar size, I can say that the pace of changes is higher, the effort necessary for large scale refactorings is lower, and our ability to reason about the system is similar. A few examples: - Refactorings are simpler due to the use of consumer-side interfaces. Say you want to inject an in-memory cache above a backing store. To do that you probably have to change the constructor and provide an implementation matching the 2-4 relevant methods. That's it. - Tracing code is slightly worse, due to having to track callers through said duck-typed interfaces, but on the flip side multi-threaded code is sufficiently simpler to reason about that I call it a wash. Having previously had to do threading in the form of "control flow" state machines, and then fibers (which were better but not perfect, and still aren't widely available), Go constructs are great. Locks where appropriate, channels where appropriate, overall very fast and clean code. - Performance is good, and reliable. Not as good by cycle-count as C++ - and e.g. the comparable RPC libraries are definitely less mature than Google's very-well-kicked C++ libraries - but on the other hand it scales almost linearly. We started a system at ~5 cores/task under AutoPilot, and then when we next got around to adding more tasks it was peaking at ~60 cores/task at essentially the same per-core throughput. I've never managed to write a C++ server that can accidentally scale concurrency by >10x without hitting _some_ bottleneck. - We use Go for ~everything. Server code, definitely Go. Client tools, also Go. Simple scripts, bash until they need their first 'if' or flag or loop, then Go too. - I'd prefer real generics to interface{}, but the number of places it comes up is minimal enough that it's no more than a minor annoyance. I can't speak to the issues of package management - we dropped compatibility with Go's native package structure fairly early on and went all in with blaze/Bazel (http://bazel.io http://bazel.io) to coordinate builds and dependencies and whatnot, and haven't had reason to try modules yet.
bsaul 8y ago
I really don't know why you got downvoted. The fact that go was meant to force "average" programmers produce maintainable code is an extremely important push for the language. I do think that generics are needed if go wants to become more useful in contexts others than network middleware or data plumbing, but i'm also pretty sure that adding them will help cripple a lot of codebase in a very short term.
- cloverich 8y ago
  Is there a definitive source for the "average" programmers target? I'd always considered it a tongue-in-cheek response to architecture astronauts who sneer at Go's simplicity.
  - pjmlp 8y ago
    “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” -- Rob Pike From https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... And there are other hints on https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
    - Felz 8y ago
      What a remarkably condescending philosophy! Do people really think that poorly of their coworkers? Of themselves?
      - privateSFacct 8y ago
        It's worked pretty well for go. I'm a relative expert in some domains, but I just find the fancy languages tiresome. I even find so called experts who find it condescending to use a straightforward language tiresome. Seriously - these so called experts never actually deliver any actual product. They just loop around writing line noise that is unreadable. If you code with others, look into the idea of write-only languages. I think you'll find some of the ideas behind go make some more sense if you understand what they are working to avoid. I don't hate generics, but don't think they are critical to go's success.
the_clarence 8y ago
If Go implement generics I’m out
joobus 8y ago
I feel the same way. By the time Go2 releases, I hope Rust has solidified its async/await syntax, and Rocket can build on stable.
- bluejekyll 8y ago
  As I understand it, async/await is not going to be too far behind the initial 2018 Edition (which is coming to stable soon).
  - abreis 8y ago
    Latest estimate is 'in 2 release cycles' (iirc), or 12 weeks.
jeffrallen 8y ago
> when your team members are idiots Just remember, they probably think the same thing.

pjmlp 8y ago

Languages are products as well, either they grow to fulfil the needs of their customers or their fade away.

ilovecaching 8y ago
What if the need is for a small language without generics?
- pjmlp 8y ago
  If there was such a need, the languages without them would still have a major market, which isn't the case. Naturally those of us coding since the early days have experience with programming languages without generics support, yet a large majority eventually adopted generics. Even C has minimal generics support since C11.
- bluejekyll 8y ago
  In what context would “need” a language to not have generics? I can understand not “wanting” generics to keep it simpler, but I can’t see that as a “need”. Personally, in any typed language, I want generics, not having them feels very limiting.

bdamm 8y ago

Isn't the premise of Go that a team sufficiently large enough will eventually act as a collective idiot in terms of code maintenance? I'm looking forward to some real research on the question of whether Go's design choices have had real world results in improving productivity with supersize code bases.

diegs 8y ago
Anecdotally (n = 10 or so) every Go codebase I've worked on has devolved into a trash fire, so no. Turns out collective idiots can write horrible systems in any language.
EricBurnett 8y ago
(Disclaimer: at Google) My team has ~200k lines of Go code and I'm exceedingly happy with the state of the codebase. Having previously maintained a C++ codebase of similar size, I can say that the pace of changes is higher, the effort necessary for large scale refactorings is lower, and our ability to reason about the system is similar. A few examples: - Refactorings are simpler due to the use of consumer-side interfaces. Say you want to inject an in-memory cache above a backing store. To do that you probably have to change the constructor and provide an implementation matching the 2-4 relevant methods. That's it. - Tracing code is slightly worse, due to having to track callers through said duck-typed interfaces, but on the flip side multi-threaded code is sufficiently simpler to reason about that I call it a wash. Having previously had to do threading in the form of "control flow" state machines, and then fibers (which were better but not perfect, and still aren't widely available), Go constructs are great. Locks where appropriate, channels where appropriate, overall very fast and clean code. - Performance is good, and reliable. Not as good by cycle-count as C++ - and e.g. the comparable RPC libraries are definitely less mature than Google's very-well-kicked C++ libraries - but on the other hand it scales almost linearly. We started a system at ~5 cores/task under AutoPilot, and then when we next got around to adding more tasks it was peaking at ~60 cores/task at essentially the same per-core throughput. I've never managed to write a C++ server that can accidentally scale concurrency by >10x without hitting _some_ bottleneck. - We use Go for ~everything. Server code, definitely Go. Client tools, also Go. Simple scripts, bash until they need their first 'if' or flag or loop, then Go too. - I'd prefer real generics to interface{}, but the number of places it comes up is minimal enough that it's no more than a minor annoyance. I can't speak to the issues of package management - we dropped compatibility with Go's native package structure fairly early on and went all in with blaze/Bazel (http://bazel.io http://bazel.io) to coordinate builds and dependencies and whatnot, and haven't had reason to try modules yet.

bsaul 8y ago

I really don't know why you got downvoted. The fact that go was meant to force "average" programmers produce maintainable code is an extremely important push for the language. I do think that generics are needed if go wants to become more useful in contexts others than network middleware or data plumbing, but i'm also pretty sure that adding them will help cripple a lot of codebase in a very short term.

cloverich 8y ago
Is there a definitive source for the "average" programmers target? I'd always considered it a tongue-in-cheek response to architecture astronauts who sneer at Go's simplicity.
- pjmlp 8y ago
  “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” -- Rob Pike From https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... And there are other hints on https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
  - Felz 8y ago
    What a remarkably condescending philosophy! Do people really think that poorly of their coworkers? Of themselves?
    - privateSFacct 8y ago
      It's worked pretty well for go. I'm a relative expert in some domains, but I just find the fancy languages tiresome. I even find so called experts who find it condescending to use a straightforward language tiresome. Seriously - these so called experts never actually deliver any actual product. They just loop around writing line noise that is unreadable. If you code with others, look into the idea of write-only languages. I think you'll find some of the ideas behind go make some more sense if you understand what they are working to avoid. I don't hate generics, but don't think they are critical to go's success.

the_clarence 8y ago

If Go implement generics I’m out

joobus 8y ago

I feel the same way. By the time Go2 releases, I hope Rust has solidified its async/await syntax, and Rocket can build on stable.

bluejekyll 8y ago
As I understand it, async/await is not going to be too far behind the initial 2018 Edition (which is coming to stable soon).
- abreis 8y ago
  Latest estimate is 'in 2 release cycles' (iirc), or 12 weeks.

jeffrallen 8y ago

> when your team members are idiots Just remember, they probably think the same thing.