It's interesting, I feel like it's the opposite and Go excels at large projects. Compared to other languages, Go doesn't let you use as many abstractions, so writing code takes longer, but it is much more straightforward to read.
I work at a >1000 person company that codes mostly in Scala, and some in Go, and would prefer to read unknown Go code any day. With
the Scala I run into things like implicit parameters and 7 layer of inheritance, but the Go code is straightforward.
Go is somewhat of a lowest common denominator language. You could out perform it with a small team of strong developers, but when once your project gets to a certain size, it's unlikely all of the developers will be strong.
I think it's philosophically interesting. The Go approach to needing a more powerful language is to assume that you actually want to write a custom code generator for your project's needs. And it's not pretty to do so(the "go generate" thing makes quite a wart in its attempt to ease this process), but it works, and you can move on with your project. Most newer languages get tied in knots trying to generalize that same task and have a kind of configurability meltdown where everyone does it differently, so while it can be shared and reused in theory, none of it is actually compatible. I think it's akin to criticism of OOP in that in a lot of cases, "you wanted a banana but you got a banana plantation, three tractors, and twenty employees".
And Go is just a little bit closer to the sweet spot than C was, since a greater proportion of Go code seems to successfully avoid extensive preprocessing.
On the other hand, it might be a bit too restrictive for prototyping to have these power limits. I definitely have an easier time feeling my way through an unknown data modelling problem if I can start slinging things together dynamically.
That is an interesting point, and even if that is true, it still means adding generics would be a detriment.
I do wonder if that's an inherent property of languages with a more expressive type system. Many would blame it on OOP, but I think Haskell also suffers from it. Haskell that is written without using typeclasses is much more readable than Haskell that's written more plainly, at least to me.
It might be a unique property to Go, which other language is strongly typed yet with such a basic typesystem, lacking inheritance or even generics?
I will echo this too. I think Go has helped usher in the sensible concept BDD and of microservices to the forefront and the do one thing do it well approach. Versus monolithic applications instead you have a lot of digestible standalone services comprising the overall application and Go excels in this.
> I don't think Go should be used for larger projects. Apparently though the community disagrees because they're really adding generics.
Go is actually specifically built for large projects: the project was started because C++ has severe problems when used at the scale of Google.
The basic design of Go was intended to engineer out the issues that Google developers saw when using C++ at scale for long periods, such as circular references and problems with combining exceptions with concurrency.
What makes Go distinctive is that the team concluded that complexity inherantly does not scale, and designed for simplicity. Which enables Go to scale down in a way, even though it was originally intended as a "systems language".
I work at a >1000 person company that codes mostly in Scala, and some in Go, and would prefer to read unknown Go code any day. With the Scala I run into things like implicit parameters and 7 layer of inheritance, but the Go code is straightforward.
Go is somewhat of a lowest common denominator language. You could out perform it with a small team of strong developers, but when once your project gets to a certain size, it's unlikely all of the developers will be strong.