|
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 |