Around 2017, Go became the language I used most in later work.

Seen against the whole column, that is interesting. In the 1990s I wrote assembly, Delphi, and Perl. In the 2000s I wrote C, C++, PHP, Java, and Python. By the later Weibo years, Go gradually became my everyday language.

Go is not as sharp as C++, and not as flexible as Python. It can even feel a little “dumb”: small syntax, few abstractions, generics absent for a long time, and verbose error handling.

But it suits internet backend work very well.

Plainness Is An Engineering Capability

Many languages attract programmers because they are expressive.

Go attracts engineering teams more because it is plain.

Unified formatting, fast compilation, simple deployment, static binaries, approachable goroutines, a useful standard library, and a consistent toolchain all matter when engineers of different levels write services together.

In large internet businesses, a language is not one person’s toy. It is a team collaboration tool.

Too much expressiveness can let everyone write in their own style. Too much abstraction can make simple problems circuitous. Go’s restraint lowers communication cost. You may dislike its lack of elegance, but you can usually understand someone else’s service quickly.

This became especially important in the microservice era.

There were more services, more APIs, and more frequent deployments. A language cannot solve architecture by itself, but a stable, simple language with a smooth toolchain reduces everyday friction.

The Psychological Gap From C++ To Go

I had written C/C++ very early, and in Linux companies I had seen C++ frameworks with strong design.

C++ is undeniably powerful. It can stay close to the system while also building high-level abstractions. But its complexity is just as real: headers, templates, memory, compile time, ABI, object lifetime, and concurrency details can each become long-term cost.

Go takes many choices away.

It does not try to let you write beautiful abstractions. It encourages you to write services clearly. Network services, JSON, HTTP, RPC, background jobs, cache access, logging, and monitoring are direct to write in Go.

That directness is valuable under business pressure.

Internet backend work is often not language art. It is building maintainable online systems. Systems must run, be diagnosable, scale, and be handed to newcomers. Go saved teams a lot of effort in those places.

Microservices Are Not A Silver Bullet

Around 2017, microservices had become an unavoidable backend topic.

Splitting a large system into small services sounds beautiful: clear responsibility, independent deployment, team autonomy, and flexible stacks. Reality is more complicated.

When services multiply, call chains get longer, diagnosis gets harder, data consistency becomes more complex, and deployment and monitoring get heavier. A function call inside a monolith becomes network calls, timeouts, retries, degradation, circuit breaking, and version compatibility after being split into services.

Go is good for writing microservices, but it will not design microservices for you.

That is why I later kept emphasizing this: tools solve tool-layer problems; architecture still depends on engineering judgment. When to split, how fine to split, how APIs evolve, how failures are handled, and who owns data are not automatically solved by changing languages.

Engineering Efficiency Matters More Than Language Belief

Looking back, I have used many languages. Every period had its “best choice” for that time.

Delphi was good for fast desktop and database apps. Perl fit the scripts and text processing of its era. PHP carried a huge amount of web work. Java was strong in platforms and big data. Python was smooth for tools and data. C/C++ remains foundational for systems software and high-performance scenes.

Go’s most important meaning for me around 2017 was that it reduced the everyday friction of backend engineering.

That is not language belief. It is engineering efficiency.

After experiencing multiple technical cycles, a programmer gradually loses interest in arguing which language is best. The more practical questions are: who is on the team, what is the business, how large is the system, how long will it be maintained, where are the online risks, and can the toolchain support the work?

Go in 2017 answered many real questions for internet backend teams.

The next year, short video and recommendation would more visibly change the traffic landscape. The gap between Weibo and Toutiao would also become increasingly visible.

IT Events Of 2017

• Go expanded in backend and cloud-native ecosystems. Go’s compile speed, static binaries, concurrency model, and toolchain made it a pragmatic choice for many internet backend and infrastructure teams.
• Transformer was proposed. The paper “Attention Is All You Need” introduced Transformer. At the time it looked like an important advance in machine translation and sequence modeling; later it became one of the key foundations of the large-model era.
• Microservices became a high-frequency topic. Microservices, containers, service governance, monitoring, and tracing became common backend engineering themes. System complexity moved from inside monoliths to between services.
• Cloud-native engineering kept spreading. Kubernetes, container images, CI/CD, and infrastructure automation gradually changed service delivery. Deployment and operations were increasingly absorbed into platforms.
• Team collaboration affected language choice. Language choice was no longer only personal preference. Readability, toolchains, deployment style, online maintenance cost, and team composition all affected whether a language could last inside an organization.

References

• The Go Blog: Go turns 10
• The Go Blog: Go at Google: Language Design in the Service of Software Engineering
• Google Research: Attention Is All You Need

WeChat

Follow ZiCode on WeChat

If this post was useful, you can follow later updates on WeChat as well.

X / Twitter

Follow @ax2_zicode

Faster technical notes, short thoughts, and new-post alerts are posted on X.

X Open X Profile @ax2_zicode