[jksmith]

What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success.

Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far?

The reason why golang appears to have such wide adoption in such a short period of time is that it really does seem to contribute to helping devs get their shit done. Massive amounts of working code are being written in golang, and that's good for the software industry as a whole.

Currently I run a massive project written in the standard issue kitchen sink corporate language (C#). It's got generics, functional extensions, all kinds of shit to make the most discriminating programmer happy. Well guess what, IMO C# for all it's features still doesn't serve the business of software dev as well as golang because it doesn't pull off what golang is brilliant at (easy to code for wide range of skill levels, easy to mentor, easy to test, easy to hire for). The result is difficulty finding productive devs, and a code base that is not up to my preferred quality standards.

This may be hard to swallow, but it might really be the case that you can get more quality work done with more devs if toolchain simplicity is emphasized over language features. If the evidence continues to bear this out for golang, then it's time for me to shed some language biases just so I can remain competitive.

[snom380]

Is it really the case that languages with more features cause more project failures? Has the success rate of Java (the prototypical blub language) decreased after they've introduced new features like generics?

My experience has often been that whatever feature is lacking in the language tends to be made up for by huge code bases that are impossible to navigate, or using frameworks that abuse whatever dynamic features you have in the language horribly with added complexity in tooling and debugging.

[njharman]

What we keep missing is that golang is not nearly as widely adopted as the blog traffic level would lead one to believe.

[majewsky]

As usual, this depends on the industry. I'm in the cloud infrastructure business (OpenStack, Docker, Kubernetes etc.) and Go is literally everywhere.

[sheepmullet]

The grass is always greener....

> easy to hire for

There are 100x as many experienced C# enterprise developers. And that is being conservative.

[tptacek]

C#, Java, and Go serve basically the same demographic and have most of the same strengths. Both Java and C# have larger ecosystems but more intellectual baggage. People without long-standing affinities to Java or C#, but who have the systems programming problems these Java-likes solve, are likely to appreciate Go, because it's simpler to pick up and use.

I think if you're proficient in one Java-like, you're single-digit weeks from being proficient in any of them, so if you're choosing your first, choose whichever one is easiest for you to go with. For a lot of Unix people coming to Java-like from Python or Ruby, that easiest choice is going to be Go: it's fully unixy but doesn't have the heavyweight runtime.

[sheepmullet]

> C#, Java, and Go serve basically the same demographic and have most of the same strengths.

Agreed. Which is why switching your org from C# to Go is going to do nothing (at best) for productivity or project completion rates.

Edit: Likewise if you are having trouble hiring C# developers it is very unlikely you will have an easier time hiring Go developers (although for a few geographic locations it might be true).

[hiram112]

Neither Java nor C# are really adequate for 'systems' programming problems, assuming the term is being used colloquially - OS level problems using system API calls, process, threads, etc.

Both Java and C# are really more suited to enterprise services. It is difficult at best to communicate with the underlying OS behind the VM. you really need to be using C / C++ to reach the kernel on Unix. Probably the same on Windows, though I'm guessing .Net provides some sort of integration.

[_ak]

And I teach them Go in a week, or even less. I had programmers going from absolute no Go experience to deploying working, idiomatic Go code to production in 2 days.

[xiaoma]

Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a much steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.

[karma_vaccum123]

Wikipedia says Elixir first appeared in 2012, while Go first appeared in November 2009. Go is not that much older than Elixir...so I don't buy your analysis. By time Go was four years old, it had much greater adoption than Elixir does today.

[olalonde]

What leads you to believe Elixir is on a much steeper adoption curve? I'm a bit surprised by that statement because I've seen a lot of open source projects written in Go (Docker, IPFS, Kubernetes, etc.) but none in Elixir.

[mattdeboard]

> What leads you to believe...

Marketing.

[geodel]

Go 1.0 is released in March 2012 so it is not even half decade old.

[icedchai]

You know Go existed before 1.0, right?

[mappu]

The question was about adoption curves, and i think version number is a signalling factor in adoption.

Pre-1.0 version number would certainly hamper adoption in my $DAYJOB.

[xiaoma]

By that logic, Elixir is not even two years old!

Edit: karma_vaccum123 has greatly edited the gp comment but for the record, Google has been using golang since 2007.

[karma_vaccum123]

Find me one reference for Go in "use" at Google in 2007. The wikipedia page does not make this claim, it is only stated that this is when Go itself was being created.

[cjrd]

How did you determine the adoption curve?

[_ak]

Go has only been published in November 2009. Less than 7 years is now what I would call "nearly a decade".

[danmux]

Yes I think golang hits a sweet spot here, and I do truly think it is the 'other things' that win in whole lifecycle practice.