He lists many things he likes and very few he dislikes, but the last sentence is:
> For big and longstanding projects, I do believe Go is bad because if you want to do something complex, Go won’t let you do this anyhow.
Without a proper explanation how he got to this strong conclusion.
And especially with so many cloud infrastructure projects being written in Go (Docker, Kubernetes, Terraform, Consul, etcd, CockroachDB, Nebula, ...), it seems to be in contrast to the common perception, thus requiring a proper explanation even more.
This interested me as well. In particular since we have developed quite a few medium sized projects in Go (20.000-50.000 LOC) and, in my experience, it is more pleasant than, say, doing it in Java or C++.
In my experience, with both C++ and Java there is always a discussion of style, frameworks and practices. Especially in C++ those choices have big consequences since C++ isn't just one language: it is every snapshot of the language for the last 20 years. If your project requires the use of a library, your code has to adapt to choices made for that library.
Java has different problems. Higher level problems. It isn't so much about which features aren't available/usable/advisable, but about what framework you use. Most people don't really work in Java, they work in various Java frameworks. And some frameworks are like herpes of programming: if you start using them in a project, you can never get rid of them. At least not at reasonable cost. (Actually it is much worse than that, but let's save that for another time).
The barriers of entry tend to be higher when so many parameters have to be figured out and adapted to in a software project. Go appears to have fewer such barriers.
I haven't done any large projects (200kLOC+) in Go yet, but I don't quite see how C++ would make large projects much easier. C++ itself is hard. It takes years to learn. Add to that the complexity in having to decide what subset of it to use and what C++ culture to adopt, and you might have to compromise on comfort from day one. Skip this discussion, and there's trouble further down the road.
I agree and in fact i think this sentence is a self-contradiction in some way :
If you want a "big longstanding" project, then doing "complex" thing is probably the thing you want to avoid at all cost. And as a proof that it's possible, one can have a look at the standard library, which is big, longstanding and is the most readable std lib i've ever seen.
HPC where you try to wring the last ounce of performance from machines insufficiently powerful for the task. Weather forecasting, weapons simulation, protein folding...
That's interesting. I don't think as optimized memory manipulation via convoluted casting and such as "complex stuff". I think of that as optimization.
I thought what the author meant by complex was a gigantic system that needs to use many design patterns for good reasons; the code models a very complex, convoluted domain.
Last few weeks I have been working on a project in Go that required using multiple libraries I had no previous experience with. Usually when in doubts I would Google or go to Stackoverflow or Github issues.
But Google results today are mostly spam or copycat sites that echo forever some old answers. And Stackoverflow answers are too often outdated for fast evolving language leading onto false paths.
Surprisingly I started just go to source libraries and read the code. It provided answers faster and with less noise.
> For big and longstanding projects, I do believe Go is bad because if you want to do something complex, Go won’t let you do this anyhow.
Without a proper explanation how he got to this strong conclusion.
And especially with so many cloud infrastructure projects being written in Go (Docker, Kubernetes, Terraform, Consul, etcd, CockroachDB, Nebula, ...), it seems to be in contrast to the common perception, thus requiring a proper explanation even more.