3 ms·

No, they had tons of experience at Google scale and was a language born out of frustration as much as need. They needed a language that was: 1) comparable with

by devuo 10y ago

No, they had tons of experience at Google scale and was a language born out of frustration as much as need. They needed a language that was: 1) comparable with c++ in terms of speed 2) had extremely fast compilation times 3) easy to use, learn and familiar looking, for quick engineer buy in 4) easy to write concurrent & parallel work with 5) designed for tooling & network applications 6) batteries included Among many, many others. Neither is Go an hammer, nor is everything a nail. For the use cases Go was designed for, I am yet to use a language as pleasant to work with as Go.

kmonsen 10y ago
I feel these assumptions were true when Go design started, but the world has moved on. Even 'boring' languages such as Swift (Apple default) and Java8 has generics and functional programming now.
- greglindahl 10y ago
  Even Fortran added some support for generic programming in 2003, and functional programming before that. It's all about how general purpose you plan on being...
  - mmarx 10y ago
    Generic procedures were already introduced in Fortran 90, i.e. in 1991.
- Ericson2314 10y ago
  They weren't true then, but yes they continually become less true.
xyzzyz 10y ago
1) Any statically typed language nowadays is comparable with C++ in terms of speed, unless you fuck up the implementation really badly. 2) This is a complete non-issue -- with Google infrastructure, it's enough to not be significantly slower than C++, which is really a low bar. 3) Go is definitely easier to use than C++, I agree. That said, it also has enough of idiosyncrasies to make it familiar mostly to people used to writing Plan 9 C, starting from "nil" instead of "null", and ending with "dial" instead of "connect". 4) I never noticed how it is any easier to do it than in, say, Java. Most of the large Go programs I've seen tend to leak goroutines, for one thing. 5) Maybe it was designed for these, though I don't quite see the way it's better suited for network applications than, say, Java. 6) It's also a total non-issue at Google. I have a year of experience writing Go tooling and network applications at Google, and it definitely wasn't enough for me to see the light. The rest of my team had quite similar experience (except of one guy who was a Go fan already before joining the company), and we would often make fun of Go's inconsistencies, idiosyncrasies, and the whole NIH approach of the language authors and maintainers. Go is not bad language, it would have been great if it was 1989, and your only serious alternative was writing ANSI C. Unfortunately, it's been almost two decades since the 80s, and we figured out some things in the meantime. We now know how to do generics correctly, for one thing, and we already understood that null pointers have been a billion dollar mistake. The worst sin of Go though is that in the true "worse is better" spirit of Unix, it filled a gap for a better C++ by being only marginally better, taking away space for other, actually better contenders that don't happen have a billion dollar company backing them.
- int_19h 10y ago
  > is that in the true "worse is better" spirit of Unix, it filled a gap for a better C++ by being only marginally better, taking away space for other, actually better contenders that don't happen have a billion dollar company backing them. I think it ended up being 1) not sufficiently low-level, and 2) a bit too insular in its ecosystem, to really fill that niche. Which is what allowed Rust to seriously contend for it, and I think Rust is going to be the winner.
  - xyzzyz 10y ago
    That's certainly my hope.
kmicklas 10y ago
> Among many, many others. Neither is Go an hammer, nor is everything a nail. For the use cases Go was designed for, I am yet to use a language as pleasant to work with as Go. You need to learn more languages (and really learn them).

by devuo 10y ago

kmonsen 10y ago

I feel these assumptions were true when Go design started, but the world has moved on. Even 'boring' languages such as Swift (Apple default) and Java8 has generics and functional programming now.

greglindahl 10y ago
Even Fortran added some support for generic programming in 2003, and functional programming before that. It's all about how general purpose you plan on being...
- mmarx 10y ago
  Generic procedures were already introduced in Fortran 90, i.e. in 1991.
Ericson2314 10y ago
They weren't true then, but yes they continually become less true.

xyzzyz 10y ago

1) Any statically typed language nowadays is comparable with C++ in terms of speed, unless you fuck up the implementation really badly. 2) This is a complete non-issue -- with Google infrastructure, it's enough to not be significantly slower than C++, which is really a low bar. 3) Go is definitely easier to use than C++, I agree. That said, it also has enough of idiosyncrasies to make it familiar mostly to people used to writing Plan 9 C, starting from "nil" instead of "null", and ending with "dial" instead of "connect". 4) I never noticed how it is any easier to do it than in, say, Java. Most of the large Go programs I've seen tend to leak goroutines, for one thing. 5) Maybe it was designed for these, though I don't quite see the way it's better suited for network applications than, say, Java. 6) It's also a total non-issue at Google. I have a year of experience writing Go tooling and network applications at Google, and it definitely wasn't enough for me to see the light. The rest of my team had quite similar experience (except of one guy who was a Go fan already before joining the company), and we would often make fun of Go's inconsistencies, idiosyncrasies, and the whole NIH approach of the language authors and maintainers. Go is not bad language, it would have been great if it was 1989, and your only serious alternative was writing ANSI C. Unfortunately, it's been almost two decades since the 80s, and we figured out some things in the meantime. We now know how to do generics correctly, for one thing, and we already understood that null pointers have been a billion dollar mistake. The worst sin of Go though is that in the true "worse is better" spirit of Unix, it filled a gap for a better C++ by being only marginally better, taking away space for other, actually better contenders that don't happen have a billion dollar company backing them.

int_19h 10y ago
> is that in the true "worse is better" spirit of Unix, it filled a gap for a better C++ by being only marginally better, taking away space for other, actually better contenders that don't happen have a billion dollar company backing them. I think it ended up being 1) not sufficiently low-level, and 2) a bit too insular in its ecosystem, to really fill that niche. Which is what allowed Rust to seriously contend for it, and I think Rust is going to be the winner.
- xyzzyz 10y ago
  That's certainly my hope.

kmicklas 10y ago

> Among many, many others. Neither is Go an hammer, nor is everything a nail. For the use cases Go was designed for, I am yet to use a language as pleasant to work with as Go. You need to learn more languages (and really learn them).