I would have thought Go is easy to hire people for. It's such a simple language and has such a well-designed standard library you can pick it up extremely quickly.

I think "anyone can learn it" is one of its main benefits. Compare that to Rust or Haskell for example...

There's a lot of languages that can make that claim, and lots of developers that would pick up a new C-like language in a week or so. The challenge is that companies that picked Go or $uncommon_language need to provide the space and training opportunity.

Go may be easy to learn, but mastering it is a thing on its own, just like the other languages.

Go's spec is much smaller than most mainstream languages. Seriously, it's a weekend read to understand the entire language specification (and it's actually readable)

Mastering a language is not the same as reading the entire spec, or even internalizing that spec. Scheme or Forth or Io are all probably smaller than Go. Perhaps even smalltalk is (the Smalltalk 80 spec is larger, but contains some of the library, tutorials, examples, and the entire spec for compiler and the VM).

If you really want an extreme example language with the tiniest spec, you can always take Brainfuck. The entire spec probably fits in a few paragraphs, but it's not easy to master.

My comment mentioned mainstream languages. To my knowledge, Brainfuck is not a mainstream language used at any small, medium, or large corporation.

The point about the spec was the language is small enough to master.

Scheme (Lisps in general) is different because it is homoionic. Forth is not mainstream, and neither is it's paradigm. And well, I never heard of Io so I will check it out, looks neat.

And your point was refuted. Brainfuck not being mainstream is irrelevant; either a short language spec correlates with speed and easiness of mastery or it doesn't. And the counter-evidence shows that it doesn't.

You can't just casually ignore inconvenient exceptions to your beliefs. I mean, you can, but it's not something that reflects positively.

The go board game has an extraordinarily simple rule set. On the other hand, it is an exceedingly difficult game to gain proficiency in.

A simple spec does not equate to a simple language. I would argue the opposite: a simple spec often means a large amount of hard work is punted on and left to the end-user.

Like it's numeric tower?

I think the issue is finding people that want to learn it. Systems programmers are turned off because of it's limitations and your average pythonista or rubyist isn't interested in mucking around in type definitions or even thinking about concurrency.

> Systems programmers are turned off because of it's limitations and your average pythonista or rubyist isn't interested in mucking around in type definitions or even thinking about concurrency

Systems programmers were the bulk of Go's early adopters, even before it hit its first stable release.

I can't speak for Ruby, but as for Python - I've been writing Go professionally for five years, and my first talk on Go was actually at the New York Python Meetup. They specifically asked me to speak about Go because they had significant interest from their members in learning or using Go. This was back when Go was still on its 1.0 release.

Soon after that, Python added type hinting and concurrency to address needs that Python programmers had. That was enough for some, but there clearly has been interest from Python programmers in Go's approach, and there continues to be; Python is one of the more common language backgrounds for new Go programmers that I see.

Furthermore, there's no shortage of experienced developers who already know Go. While the numbers are evening out a bit as more companies have begun to adopt Go, there are still more experienced Go programmers looking for jobs where they can write Go full-time than the other way around. (And that's not even looking at people who are inexperienced programmers or experienced programmers who don't know Go but might be interested in learning.)

Go may not be for everyone, and that's fine, but there's really no shortage of good programmers who can write Go. If a company is evaluating languages and considering Go, availability of talent is a selling point, if anything, not a concern.

My subjective impression (supported by informal surveys [1]) is that most Gophers come from a Python or Node.js background, doing mostly network code, DevOps automation or CLI tooling. Rubyists are less likely to fall in love with Go, given that the huge philosophical gap, though the pragmatist among them adapt go for what it excels at (performant microservices and statically linked binaries).

Still, most newcomers to Go seem to come from dynamic typing background, and it shows with all the buzz about Go being 'strongly-typed' and 'helping you to detect typing errors', which sounds crazy to anyone who played with C++ or C#, let alone an ML-family functional language.

And yes, Go also has a small but prominent contingent of C developers, and while some of them also do systems programming, this is generally not what they do in Go. This crowd seems to be mostly focused on tools and networking-oriented code, two areas where Go excels. The thorough standard library and top notch static linking support make go a hard to beat choice for this type of work, but its a less obvious choice for traditional systems programming, which usually still eschews garbage collection.

You'll rarely find Go being used in most of the traditional systems loads: drivers, kernels, high-spec graphic engines, emulators, JIT compilers, filesystems, browsers and definitely not in real-time programs. The one traditional systems realm where Go does see some activities is lightweight databases and key-value stores (BoltDB, TiDB), but databases performance is often dependent on concurrency no less than it depends on memory, and in fact Java has been long popular for NoSQL databases (HBase and Cassandra), and even way more niche languages like Erlang gave rise to popular NoSQL solutions (Riak, CouchDB).

[1] https://blog.golang.org/survey2016-results

Despite the obvious "Hey this has a GC!" Go is actually surprisingly good as a systems language. You can do pointery stuff, assembly if you need, etc. I've used it for user-space device drivers on Linux (you can easily use it for ioctls and other low level stuff).

I bet you could even write a kernel in Go. I think the only places where it really couldn't go (ha) are microcontrollers.

Edit: yep: https://github.com/jjyr/bootgo

I don't think your last point is entirely accurate. I've programmed in Python since the mid-90s and Ruby since 2005, and developers in both camps want concurrency. I think this is why Elixir has really taken off amongst Ruby developers. It is similar enough to Ruby that they don't feel lost, but it makes concurrency extremely easy; a lot more so than Go does, in my opinion.

My reasons for dismissing Go are mainly due to the way it handles memory. Concurrency is handled in Go using shared memory, as opposed to Elixir's private memory model, and Go's threads are not guaranteed to politely take turns the way Elixir's are. I also think Go's packaging system is quite flawed.

I also dislike Go's syntax, but that is just a matter of personal taste.

I checked out those blogs and none of them really go into any depth about scaling issues. Do you guys plan to share your learnings there, I for one would find that interesting.