Google's Go Language Surges In Popularity (infoworld.com)

2016 saw a big spike in the popularity of Go, attributed to the rising importance of Docker and Kubernetes. An anonymous Slashdot reader quotes InfoWorld: Ranked 65th a year ago in the Tiobe Index of language popularity, it has climbed to 16th this month and is on track to become Tiobe's Programming Language of the Year, a designation awarded to the language with the biggest jump in the index...which gauges popularity based on a formula assessing searches on languages in popular search engines...

Elsewhere in the index, Java again came in first place, with an 18.799 rating while C, still in second place, nonetheless continued its precipitous drop, to 9.835% (it had been 16.185% a year ago). In third was C++ (5.797%) followed by C# (4.367%), Python (3.775%), JavaScript (2.751%), PHP (2.741%), Visual Basic .Net (2.66%), and Perl (2.495%).
The article also cites an alternate set of rankings. "In the PyPL index, the top 10 were: Java, with a share of 23.4%, followed by Python (13.6%), PHP (9.9%), C# (8.8%), JavaScript (7.6%), C++ (6.9%), C (6.9%), Objective-C (4.5%), R (3.3%), and Swift (3.1%)."

Comments

But what is it used for?

[Anonymous Coward]

I looked for use cases a while back and couldn't find anything except crawlers.

I hate how easily programmers jump on a bandwagon.

Re:But what is it used for?

[Lisandro]

It fills nicely the niche between low and high-level languages. You get C-like semantics, modern data structures, memory management and high performance with fast compiled binaries.

Also, it is one of the few languages out there where concurrency is not an afterthought.

Re:But what is it used for?

[Tough Love]

You get C-like semantics, modern data structures...

Modern data structures without classes or generics? This is where I checked out on Go after initially being interested.

memory management and high performance with fast compiled binaries....

And no way to avoid the memory management, a crippling problem shared with Java that makes it a bad choice for many applications (e.g., low latency financial transactions). Face it, Go is a bland language with really only one thing going for it: promoted by Google. Much like C# is promoted by Microsoft, which didn't overcome the mind share issues of that platform either.

It's just not clear what problem Go solves better than any alternative. If you want highest performance and lots of big team software engineering support, you go with C++. If you need managed memory and access to the copious supply of 2 year diploma programmers and don't mind throwing a bit more hardware at your problem you go with Java. If you need to churn out web2 sites as fast as possible then Node or Python. It's just not clear where the demand for Go is supposed to come from. From where I sit, Go is just another pretender to the Java throne, not any less bland than the incumbent and decades late to the party.

Re:But what is it used for?

[OrangeTide]

I'm a long time C programmer, and I like Go a little better than C for concurrent programs. It's not quite as ground breaking as something like Erlang, but it's quite a bit easier to throw something together to run reasonably well on a cluster than say Java. I wouldn't want to write a kernel in Go, but it's pretty hard to displace C in that niche.

Re:But what is it used for?

[dottrap]

Go was created by Rob Pike and Ken Thompson to solve real problems Google was having with its massive C++ code base.

The domain they work in is huge scalability, server backends.

You are right, it is a boring language, and that's just how they like it because Google is trying to solve their very specific problems without creating nightmares of new ones.

Go is designed to address many of the scale complexity problems they faced with C++, in both human terms and machine terms. In human terms, C++ is a very complex language. In machine terms, the joke was that Go was invented while waiting for a C++ compile job. (Google's build times are frequently measured in hours.)

Go also addressed scaling problems for other languages. Java, C#, Python, Ruby, NodeJS, etc. consume a lot more resources to spin up their virtual machines. At Google scale, this adds up to needing a lot more hardware, and a lot more power to run the data center, and a lot more cooling needed.

And since most of Google's server requests have no dependencies with each other, they could build directly into the language mechanisms to support concurrency. (And they make it a point to distinguish between concurrency and parallelism in computer science terms.)

In the end, Go is a fairly simple language that people from scripting languages can pick up reasonably, while getting pretty decent native performance, and also getting concurrency features which are optimized for their domain.

Re: But what is it used for?

[Lisandro]

Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall.

Oh, but it does - though i wouldn't call it "magic". Don't take my word for it: write a small program spawning, let say, 100000 goroutines. See how many system threads are launched.

From the documentation itself: "They're called goroutines because the existing terms—threads, coroutines, processes, and so on—convey inaccurate connotations. A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space. It is lightweight, costing little more than the allocation of stack space. And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management."

You're mixing up concurrency with parallelism. Rob Pike had a couple of very interesting talks on the matter.

Re:Syntax

[doktor-hladnjak]

As somebody who started writing it about 75% of the time at my job starting earlier this year, I found it weird at first because it's pretty different from other popular languages. But once you get used to writing it, it really does become transparent and second nature.

Re:Syntax

[ooloorie]

I'm also not too fond of its semantics, and find the libraries somewhat limited. But other than syntax, semantics, and libraries, it looks like a great lanaguage!

I bet half the people who said "C" actually

[melted]

I bet half the people who said "C" actually meant C++. There's really no reason to use C except in projects that are already in C, since C++ is an almost exact superset of C. So you can write everything in a procedural style, but still use STL and strings, and other minimal conveniences.

Re:I bet half the people who said "C" actually

[lgw]

2K ram - check
  8k flash - check

  STL - yeah sure

Depends on the compiler, of course, but the STL isn't some runtime library, it's a set of templates, which means only bits you use get compiled. Strings and vectors tend to be reasonably lightweight.

Unless of course, you're the guy who says "I'm not going to bounds-check my array access, I only have 2K!" leading to the world's biggest botnet of Internet-enabled toilets.

Re:I bet half the people who said "C" actually

[BESTouff]

Forcing projects to C avoids possible bugs and unreadable code from cowboy programmers on your team using some of the more esoteric features of C++.

This ! I've been working in several embedded systems companies, and we always have avoided C++ precisely because of this.

It also is a requirement for embedded systems, which includes everything for an arduino and their bigger cousins.

(OTOH not really this, I'm seeing more high-level languages, even JS, everywhere)

Re:Another attempt to start anew...

[OrangeTide]

Rob Pike is hardly a kid.

Go was never about making a beautiful language. It has been about making different compromises than the ones C had to make 45 years ago. All practical languages are a set of compromises.

The lack of shared libraries are an intentional feature of Go. Generally in a cluster environment they cause more problems than they solve. There isn't anything fundamentally special about Go that would prevent it from having dlopen, it just doesn't have it today because the people who are interested in Go aren't interested in dynamic linking.

The executable size issue is slowly improving. There is an open bug to track it, and while the bug is very old, it still gets regular updates. And only the things that are needed are included in the executable, not "everything". If you make a HelloWorld app, then the big bloat in your app will be the garbage collector. But once you go beyond writing extremely trivial programs the size of your executable doesn't increase at a rapid rate. You should settle on a Go program of any significance being about 2MB to 10MB (where you link almost everything), then slowly going up from there. Another way to put it, is that your executable will be about 0.1% to 0.5% of your system RAM, the kernel will demand page it so if there really are unused parts they won't use precious RAM.