4 ms·

To quote Rob Pike: >The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably

To quote Rob Pike: >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. If Google, with its intensive algorithmic interviews, can't manage to hire people capable of understanding something like: func max(T: Comparable)(a, b T) { if a < b { return b } else { return a } } } And why we'd prefer that over having to rewrite the function for int8, int16, int32, int64, uint8, uint16..., then what hope is there for anybody else?

ailideex 7y ago
If this is too complex for them to understand I would be really worried with "good software" they are building. I agree hiring good people is hard, but structuring your process for people that cannot understand the concept of Go Contracts may not be the optimal solution to this problem - at least in my view it is not.
- pjmlp 7y ago
  > If this is too complex for them to understand I would be really worried with "good software" they are building. Go have a look at all the Android architecture issues, rebooted at every IO, build performance problems and constant regressions in Android Studio. Or since we are on a Go thread, how the Kubernetes code actually looks like (they did a talk about it at FOSDEM).
013a 7y ago
The funny thing is; your code has a syntax error (two, actually). Its dumb to nitpick, but its symbolic of the problem; even if you're so sure that you have no mistakes, that what you've written is well designed and will work well... you're probably wrong. Even the simplest blocks of code will have issues, and the language should do everything it can to help this. No one likes to be told that all they deserve is a blunt knife, but frankly, it's more true than it isn't. I'll gladly wield that blunt knife if it means I get to build awesome products that don't break at 2am. (Edit) I made a mistake in my analysis of your code; there's actually three errors. Everyone makes mistakes. Our tools shouldn't encourage us to make more.
- ailideex 7y ago
  Would the mistakes compile? In many cases having a simpler less powerful language increases the amount of code you have to write. In this case it would be one place to fix, if the function was implemented for n different types then a mistake would have to be fixed n times. If Go Contracts reduce duplication they help at eliminating an anitipattern.
- logicchains 7y ago
  Now imagine if I'd copy-pasted that code for every builtin int and float type; there'd be ~ 36 errors.
  - 013a 7y ago
    That's a fair point, but it harkens back to the argument we see a lot for generics; "we'd have to repeat that 5 times for int8, int16, int32, int64, and just int, not to mention floats!". I think there's a problem of complexity with that core argument. Why are you replicating this function 5 times? Why not just use `int`? Or just `float`? In other words, you're creating a solution that is (probably) too complex, and to manage that complexity you're asking for more language complexity. How about we attack the root of the issue: why is the solution so complex? Can we reduce that complexity? More often than not, we can. Developers tend to over-engineer things, and Go's type system is a forcing function toward simplicity. Every once in a while, we run into a problem that would benefit from generics. But its very rare. The cost of "having" generics in every situation, including many where you don't need them, far outweighs the cost of being forced to grab `interface{}` or `reflect` in the very few situations where you don't have them. The problem is: It's not as obvious that this cost is higher. That's the challenge the Go team has had over the past few years; convincing us, who hold a loaded gun pointed straight at our foot, to not pull the trigger and turn this language into Java2.
dgellow 7y ago
What's the source of this quote?
- dmoy 7y ago
  rob pike lang.next 2014 it's the talk that starts with sawzall
skybrian 7y ago
I don't think that's what Rob Pike was saying. It is more along the lines of, if you hire smart people who don't know C++ and then teach them C++, it is still a very long learning curve since the language has so many gotchas. (And you can make the same argument for Haskell.) You spend a lot of time on becoming a language expert rather than learning about the domain you're actually interested in. It's better to have a language that can be picked up easily and that you can be competent in without needing to be an expert. And this is something Go is known for. The example you gave seems reasonable for any Googler to understand (once the errors are fixed). The contracts proposal does make Go a bigger language, but it seems worth it.
munificent 7y ago
It makes me sad that people think the problem with C++ is that it's powerful, not that it was saddled with backwards compatibility with an ancient language and then has accrued over thirty years of its own baggage on top of that.

ailideex 7y ago

If this is too complex for them to understand I would be really worried with "good software" they are building. I agree hiring good people is hard, but structuring your process for people that cannot understand the concept of Go Contracts may not be the optimal solution to this problem - at least in my view it is not.

pjmlp 7y ago
> If this is too complex for them to understand I would be really worried with "good software" they are building. Go have a look at all the Android architecture issues, rebooted at every IO, build performance problems and constant regressions in Android Studio. Or since we are on a Go thread, how the Kubernetes code actually looks like (they did a talk about it at FOSDEM).

013a 7y ago

The funny thing is; your code has a syntax error (two, actually). Its dumb to nitpick, but its symbolic of the problem; even if you're so sure that you have no mistakes, that what you've written is well designed and will work well... you're probably wrong. Even the simplest blocks of code will have issues, and the language should do everything it can to help this. No one likes to be told that all they deserve is a blunt knife, but frankly, it's more true than it isn't. I'll gladly wield that blunt knife if it means I get to build awesome products that don't break at 2am. (Edit) I made a mistake in my analysis of your code; there's actually three errors. Everyone makes mistakes. Our tools shouldn't encourage us to make more.

ailideex 7y ago
Would the mistakes compile? In many cases having a simpler less powerful language increases the amount of code you have to write. In this case it would be one place to fix, if the function was implemented for n different types then a mistake would have to be fixed n times. If Go Contracts reduce duplication they help at eliminating an anitipattern.
logicchains 7y ago
Now imagine if I'd copy-pasted that code for every builtin int and float type; there'd be ~ 36 errors.
- 013a 7y ago
  That's a fair point, but it harkens back to the argument we see a lot for generics; "we'd have to repeat that 5 times for int8, int16, int32, int64, and just int, not to mention floats!". I think there's a problem of complexity with that core argument. Why are you replicating this function 5 times? Why not just use `int`? Or just `float`? In other words, you're creating a solution that is (probably) too complex, and to manage that complexity you're asking for more language complexity. How about we attack the root of the issue: why is the solution so complex? Can we reduce that complexity? More often than not, we can. Developers tend to over-engineer things, and Go's type system is a forcing function toward simplicity. Every once in a while, we run into a problem that would benefit from generics. But its very rare. The cost of "having" generics in every situation, including many where you don't need them, far outweighs the cost of being forced to grab `interface{}` or `reflect` in the very few situations where you don't have them. The problem is: It's not as obvious that this cost is higher. That's the challenge the Go team has had over the past few years; convincing us, who hold a loaded gun pointed straight at our foot, to not pull the trigger and turn this language into Java2.

dgellow 7y ago

What's the source of this quote?

dmoy 7y ago
rob pike lang.next 2014 it's the talk that starts with sawzall

skybrian 7y ago

I don't think that's what Rob Pike was saying. It is more along the lines of, if you hire smart people who don't know C++ and then teach them C++, it is still a very long learning curve since the language has so many gotchas. (And you can make the same argument for Haskell.) You spend a lot of time on becoming a language expert rather than learning about the domain you're actually interested in. It's better to have a language that can be picked up easily and that you can be competent in without needing to be an expert. And this is something Go is known for. The example you gave seems reasonable for any Googler to understand (once the errors are fixed). The contracts proposal does make Go a bigger language, but it seems worth it.

munificent 7y ago

It makes me sad that people think the problem with C++ is that it's powerful, not that it was saddled with backwards compatibility with an ancient language and then has accrued over thirty years of its own baggage on top of that.