What is the difficulty of maintaining projects in Go?

Question

go

Greetings!

This is not the first time I have come across statements in the style of "it is difficult to maintain projects in Go", various arguments are given, most often "there is no OOP", "there is no normal error checking", etc.

Tell me, in your opinion, is it really difficult to support projects on go, if so, what does it mean?

Answer 1

I have been writing in Go for more than four years, it is more difficult for me personally to support projects in other languages))
Before Go, I wrote in Perl/PHP/Python/Java/C/Ruby on rails/JavaScript for many years and "twisted" quite a few things.
Now I only write in Go and Python.
The main difficulty in Go is that if you start writing "crookedly" - then it is very difficult to write like that :))
The approach to implementation in Go is quite unusual for those who come from scripting languages.
For example, the prohibition of cyclic imports is the very first thing that "explodes" the brain :)
It takes time to adapt after scripting languages.
About error handling - yes, this is probably the only thing I don't like about Go.
For myself, I solved this problem in 1-2 hours :) and it doesn't bother me anymore.
According to OOP - Go has it, personally I like it much more than OOP in other languages))
Everything that is really needed is there, but there is nothing superfluous.
Interfaces are just wonderful :)) Channels, goroutines are just "happiness" :))
And if objectively, then I would not talk about the complexity of project support applicable to a particular language.
As a rule, the complexity of support arises where the normal architecture is not included in the project.
Those. the project was written by a bunch of people as best they could, plus, as usual, it had to be done quickly )), because of this, no one thought about architecture at all and it turned out what happened :))
We don’t talk about test coverage and documentation at all )))
And when in such a project you need to modify something or fix a mistake, it is almost always very difficult to find the place where you need to edit, and after editing in one place, as a rule, something breaks in another :)
At a minimum, you need follow the principles of SOLID, otherwise the code is, to put it mildly, unsupported.
But understanding these principles also comes with experience, they cannot be learned by simply reading a book or article. You need to make several projects using these principles, write crookedly, understand how it would be right, redo everything and so on several times.
Then, over time, understandable and easily maintainable code will start to turn out.
So we come to the conclusion that if there is no experience, then it will be quite difficult to support the project, regardless of the language, etc.
I would like to add that no matter how they write about Go, that it is simple, etc. - it is clearly more complicated than Python/PHP etc.
This is another reason to say that maintaining code in Go is difficult))
It is also worth considering that projects that write in Go are often more difficult than projects for which they choose a scripting language. Go is chosen when large workloads are planned, parallel processing of something, etc., and this, in turn, further complicates the project.

Answer 2

Because there are no developers.
If you decide to build a product on Go, you will have problems. After creation - support begins. And if the developer chose Go, he is not interested in support, he likes fashionable, new, youthful, he will leave and you will be left with nothing, with vacancies open for half a year, and even a salary much higher than the market will not help much.