How suitable is Golang for large projects?

Question

go

Good afternoon, colleagues.
I read a lot about the pros and general goals of this wonderful language, networking and system orientation, but now I want to turn directly to the adherents: how appropriate is it to use Go in a big bloody enterprise-monolith for a million lines of code with all sorts of REST, caches, work with the database and etc? It is clear that the language is very suitable for microservices, but the practical experience of a startup plan, possible pitfalls and shortcomings are interesting.

Answer 1

Go has one use - highly network intensive applications. GRPC, protobuf, trillions of rpc calls per second. It is used when there are or immediately similar requirements or the business has grown to this level.
Startups most often require Rapid Application Development frameworks. The language is rather secondary. You can quickly blind - well done. But more often you have to choose from what you know.
In the bloody Enterprise, the old Java (with rare exceptions) is mainly ruled by the fact that there are requirements for the replacement of employees and a large legacy landscape of projects that no one will rewrite

Answer 2

How suitable is Golang for large projects?

He has it at the genetic level. One of its creators already had experience in creating a highly successful programming language that went pretty well into large projects. And he also participated in the creation of the operating system. Just in this language. A very successful OS turned out.

how appropriate is it to use Go in a big bloody enterprise monolith with a million lines of code with all sorts of REST, caches, database work, and so on?

It was originally architecturally designed to be in a fierce bloody enterprise and even in a monolith on a tuev mountain of code lines. Any DBMS is essentially a monolith. And on Go, there are probably about a dozen quite successful bases that are used in the enterprise.

It is clear that the language is very suitable for microservices

Microservices is a development methodology for large, often disparate projects. And by and large it is indifferent on which PL the microservice will be laid out. At least in assembler, if it is justified. Usually microservices are about several PLs per project.

however, the practical experience of a startup plan, possible pitfalls and shortcomings are interesting.

As if for a startup, microservices are not recommended right away. At least revive it and make it work as intended. And then move on to microservices. But this is a digression. Trouble can crawl out of past skill and knowledge. Golang implements its own OOP model, which is not entirely clear to those who wrote in OOP-oriented languages ​​(Java, Python. PHP). It is very difficult after languages ​​with dynamic typing. The model of parallel programming is also not immediately given to many.

Answer 3

Go is often used as a programming language to optimize CPU/memory bottlenecks in large projects. It is often chosen when the bulk of the code is written in languages ​​with dynamic typing and, at the same time, everything works slowly and consumes a lot of memory. It is easier to choose a "quick" language that will solve the problem in one fell swoop and therefore few people are willing to invest in restructuring and finding problem areas in the project.
So, before using Go, I would suggest that you first make sure that you have already squeezed the most out of the technology you are using. Perhaps it is enough to rethink the approach to building a project, rewrite the problematic parts from scratch.
I would also like to add that compared to the same Ruby, there is much more code writing. Purely on sensations, time in 3-5. Business logic is described in Go not as compactly as in Ruby.

Answer 4

If it's not business logic with a bunch of conditions and calculations, then it's great.
Otherwise it's hell.