That's a good point. Modern programming languages are all pretty big and complex and whenever someone tries to nail down "this is why it's good/popular" there always seem to be other significant factors that got missed. After all, if it were just one factor that leads to programming language popularity, we could design the Next Big Language by just following that recipe!
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 like Go because everything is super simple. From dependency management to unit testing to performance profiling to its build/deploy story, everything just works. I don't need to learn a new configuration language and project configuration format and complex dependency management system just to build my project. I don't need to pick a unit test framework and test runner. I don't need to figure out how to wire said framework / test runner into my build tooling. I don't need to figure out how to ship my app along with its dependencies or make sure that my deployment target has the right version of a VM installed. I don't even need to worry about learning a new IDE. I could keep going, but it's things like this that matter to me even more than the language itself.
I consider Go as a Modula-2 successor. It shares most traits I liked a lot with Modula-2. I prefer the C-style syntax to the more long-winded one though.
The familiarity is no surprise though, considering that Robert Griesemer is a student of Wirth.
While I used Modula-2 a lot in a long distant past, I unfortunately never got into Oberon, so I didn't consider it in my comment. Though if Go is a successor to Oberon and Oberon is a successor to Modula-2, Go is also a successor to Modula-2 :).
Eh? I can't speak for all of Google but I like me some Go. It has a culture of minimalism both in language and code, which makes it easy to pick up and read others' work. I wouldn't recommend it for all problems, but it's at least nice for backend services.
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.
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.
>Look back at this again if golang adds generics and other features that will change how code in it is written.
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.
Java will be getting value types in an upcoming version. C# already has value types (called structs). The JVM also does escape analysis to avoid heap allocation when it can.
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.
Let's look at it from different angle. When first release, AWS Lambda or even Google Cloud FUnction didn't support Go. NodeJS always get there. Python is there always.
So the point of big company backing it doesn't add much value. Even Google didn't support Go for their Google Cloud Function.
Major backing can get you publicity, but don't think that's the deciding factor. What really matters is that major backing gets you the resources to produce a really solid, complete standard library. That is a critical component to language success.
Failed programming languages are not popular, which is why it is hard to remember them.
For example, Ceylon (backed by Redhat) never got any traction, and most people forgot about it or never heard about it.
You can do this with many VM languages too - you package the VM with the code you want to ship. The VM-wrapper still needs to be built for the target arch (like Go), but the code it runs does not (like Go).
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.
