[SwellJoe]

So, it's previous analogs are Java and C#? That doesn't feel quite right, either, in that Google makes no money from Go; Java and C# are both direct moneymakers for their respective stewards. I haven't really seen Google pushing Go that hard; it feels like a skunkworks project that just happened to catch everybody's eye (including the company it came out of), rather than a grand plan to conquer the world of programming.

[im_down_w_otp]

It seems like everyone wants to believe they have Google-shaped problems, and thus should mimic Google in as many ways as they possibly can. Is some component of it that? Whether or not it's part of some grand plan?

This happens in hiring practices, in programming languages, in infrastructure tech, in data tech, etc.

It's extremely rare to encounter a data scale problem that actually requires a Hadoop-ish deployment, but they're all over the place. It's extremely rare to encounter an ops infrastructure that requires a scale and complexity where Kubernetes-ish tools make sense, but they're all over the place.

I admittedly don't fully understand the point of Go (as in existentially). I have used it, and will assuredly have to keep using it based on its increasing popularity. But it's not as good as Erlang for reliability or supporting production tools (services use cases). It's not as good as Rust or Haskell for implementation assurance (safety/security use cases). It's not as good for numerical processing as Julia or Fortran (scientific/performance use cases).

It feels a lot like the next generation of Java to me.

In that it's some shape of "good enough". And when "good enough" is combined with the cachet of aligning oneself with Google's ecosystem, it's basically unstoppable.

[SwellJoe]

There's a lot of Java at Google, so it wouldn't be surprising that Go would be Java-esque. But, I find it more like C. It has literally no accommodation for "enterprise" things. It's kind of its own thing that bubbled up out of a parallel timeline (which is kinda true, since it evolved out of the Plan 9 ecosystem and from Plan 9 developers), without much baggage from the couple of decades of commercialization of languages.

It's a pretty close to pure expression of a few language designer's vision, with very little in the way of corporate influence (that I can discern). And, I think that's the point of Go; it's the language its designers wanted for the tasks they wanted to work on (web scale services). It just happens that a lot of people want/need to work on the same sort of thing.

I agree that most people embracing massive scale are doing so way too early and probably aint gonna need it. But, that doesn't mean Go isn't a useful tool, anyway. I've watched a few videos, and read a few tutorials, and the brevity of Go for things like network servers is breathtaking. The cleverness of interfaces is...well, it really has to be seen to be understood. It's not OO, it's not functional. It's...something else. Contrary to the impression that maybe I've given in other comments, Go does have some features that aren't commonly seen elsewhere (or, if they are, they're bolted on). It has some fancy features, but only a few, and only in specific areas.

It seems like a very well thought out language, to me. Which might have been true of Java in its very early days...I'm not sure. I've never really been a Java developer, though I've read some Java code now and then.

So, Go might be merely "good enough" on some fronts, but I think it's great on a few specific fronts. And, it does it without requiring total buy-in on a new paradigm, which is probably its killer feature. It looks a little like Python or whatever in syntax, but acts a little like Erlang on a few specific details. Pretty good combination, and the community seems to agree.

[psiclops]

I post this pretty often when the conversation of design choices behind Go comes up. [0] There is definitely a heavy C and Plan 9 influence on it.

[0] https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

[im_down_w_otp]

I agree generally with this sentiment. It's probably the biggest reason I have such a hard time falling in love with Elixir. Because Erlang is simpler, despite them being largely interchangeable, and that simplicity is extremely appealing.

[notjack]

I wouldn't call it a grand plan, but it is one of Google's five officially supported server languages and as a result there's a lot of work being done to build tools and libraries for it. Code generation and relying on language-agnostic building and packaging systems (bazel) are both pretty common Google-isms, which show how the company's development culture influenced the priorities and direction of the language.

[brianyu8]

What are the other 4? Python, C++, Java, and what other language?

[psiclops]

Javascript

[notjack]

Not a server language (no NodeJS at google). The other is C.

[psiclops]

AFAIK (although I could be wrong about this) the typical 'five' languages used at Google are not specifically for servers. I have heard they are Javascript, Java, Python, Go, and C++

[coldtea]

>So, it's previous analogs are Java and C#? That doesn't feel quite right, either, in that Google makes no money from Go; Java and C# are both direct moneymakers for their respective stewards.

Well, Google doesn't put as much money into Go either (as MS and Sun put into Java and C#). Sun and C# had much bigger teams, much bigger budgets, and tons of marketing money spent on them, including actual ads everywhere. Just the team writing the C# documentation was probably bigger than the whole Google Go team.

But that's relative:

Unlike most OSS/community driven languages (e.g. Nim or Julia), Go has a big enough team that's paid to work on Go. That makes a difference.