Go doesn’t need a VM. That’s key. You get good concurrency with an easy to deploy binary that can target the major chips.
In the case of Go, I can imagine many of its attributes are significant:
- Good concurrency model
- Familiar style for imperative C/Algol-family programmers
- Requires no VM
- Backed by major corporation
- Runs on all major OSs
- etc
Actually, I think I'm changing my mind. I'd put "corporate backing" higher on the list. Some languages have gotten a huge boost by being backed by a major corporation (classic example: Objective-C), and I'm having trouble thinking of a general-purpose programming language backed by a major company that did not become popular (Dart would be my best guess but even that seems to be doing alright).
I don't think Go success has anything to do with Google. Google engineers probably favors Java/Python.
I think the key thing to make Go adopt is because the Docker project and Hashi Corp.
The second most important thing is it is super easy to compile Go program and run it and adopt by DevOps teams
Anecdotally, I've heard from many people that Go only took off in China because chinese programmers like google and it was sold as a language by google.
> Google engineers probably favors Java/Python
That's irrelevant. The fact of the matter is that Go has a company backing it and providing a constant stream of well-paid developers and infrastructure. Most small languages can barely afford to have two poorly-paid fulltime developers.
I doubt go would exist if there weren't several people getting paid very large quantities of money working on it.
So the point of big company backing it doesn't add much value. Even Google didn't support Go for their Google Cloud Function.
Java is a victim of its own success: it has lived through style evolutions which have lead to fragmentation in the ecosystem. Some code uses mutable datastructures with for loops, others immutable datastructures with the stream API. Some code uses dependency injection, while some doesn't. As a result it takes more time to mentally calibrate to the style when pulling up a .java file. Another imperfection: GC pauses can cause request timeouts and are annoying to debug.
Python's not perfect either: aside from the obvious performance issues, use of the awkward retrofitted type system makes me wonder why a statically typed language isn't being used to begin with. The lack of good static analysis is especially annoying at Google where the tooling is quite good.
Just my 2c
The same can be said for C++, C#, etc. that have been around for a long enough time. Golang is relatively speaking still new. Look back at this again if golang adds generics and other features that will change how code in it is written.
> Another imperfection: GC pauses can cause request timeouts and are annoying to debug.
That's not an issue with Java, but how the GC is tuned. Golang provides only 1 gc that is tuned for latency. And even that is not hard real time. The JVM has several GCs you can choose from, including latency optimized ones.
Absolutely. I was surprised by the number of proposed changes in Go 2, especially regarding error handling. Curious whether old code will be migrated or left behind.
>That's not an issue with Java, but how the GC is tuned
Good point, I haven't done much GC tweaking personally but that sounds worth learning more about. However I think language might have something to do with it: In Java almost everything is a referenceable object, while in Go one can put values directly inside structs. So Go has less work to do. Without that advantage I doubt it would seem competitive with Java GCs.
With co-routines and static compilation.
I will absolutely agree though that Go makes this easy, which is quite a large benefit. But it's not in any way the opposite of a VM.