Well written article. Also points are valid. What I disagree with is that author overestimates dangers that those ugly aspects pose. There are linters and unit tests to catch those things before they reach production. I can’t quickly recall when the last time failure to initialize a structure field was a source of bug that was pushed to master (in fact, I love to use zero values as intended). Most bugs I remember are the logical ones, which no compiller can prevent. But then, I am senior developer, so maybe I can’t understand the struggles of juniors.

It may well be that Go is not adequate for production services unless your shop is literally made up of Go experts (Tailscale) or you have infinite money to spend on engineering costs (Google).

Reality says otherwise. I worked for a few large companies that chose Go as their main code base language. I can also see wide adoption of Go as backend language. It not only did not increase development or maintenance costs of those products, but reduced them. From the perspective of developer, who used C++ before Go.

I use Ctrl+Shift+Arrow Up/Down for multiple cursors. Maybe because I’m already long time Linux user and use MMB to paste selected text.

I’ve dumped 18 years of C++ experience for Go in 2018, and never wanted to come back. Took me a couple of months to become accustomed.

The main Go’s feature is a green light for ignoring OOP baggage collected for decades, which makes writing code unnecessary burden. And Go have tools for not doing that.

Yes, sometimes it can be a bit ugly, but if you’re ready to trade academic impeccability for ease of use, it’s a real blast.

I’ve seen a lot of bad code in Go, which tried to do OOP things taught in school or books. Just don’t. Go requires a different approach, different mindset. Then everything falls in their places.

In other words, Anon is right on every point? Honestly, I thought some were exhaggerations. But thanks for confirming each and every.

Gunfright on Spectrum

Which suspiciously reminds optimization. Like computer game with infinite procedural world, where map chunks only generated where player interacts with world, being just formula (algorithm) everywhere else.

I was referring another comment in the thread, sorry for confusion. The OP attacks both Go and microservices, although it’s no Gos fault in the story.

Also I just hate Java too, and OOP in general.

According to votes, hating Java is bad, but hating microservices is good.

Well, that’s the architecture problem, not the language.

Swap Java and Go in text, then I buy it. Java is memory hungry monstrosity that runs on JVM and idiomatically uses piles of abstractions. I have exactly opposite experience, when rewriting a microservice from Java to Go reduced memory usage tenfold and sped up requests processing.

Hiding the complexity behind nice interfaces makes it actually more difficult to understand programming.

This is a very important point, that most of my colleagues with OOP background seem to miss. They build a bunch of abstractions and then say it’s easy, because we have one liner in calling code, pretending that the rest of the code doesn’t exist. Oh yes, it certainly exists! And needs to be maintained, too.

Black Mirror season 7 (I think) has an episode about this. Surgery to fix a part of brain (not cheap) installing a chip. And after some time pay a subscription to get rid of ads. And subscription gets more expensive over time.

In Go, the recommended convention for variable name length is to be proportional to their scope. It is common to use one or few letters long variables if they are local to a few lines loop or a short function.

Well, every natural plant have seeds. They need to reproduce. Those without seeds go extinct in one generation.

Agree.

Still, story resolution was smoother, than, for example, in Hereditary, where tension was masterfully built (and to a higher degree), but last few minutes left me with a sense of unfinishedness.

Anyway, both are great hororr movies.

I liked Weapons (2025), also by Zach Cregger.

In Go you can compare structure instances with == (by value). You can also compare pointers (in which case they can be different even if values are equal). You get what you ask for.

Also, I’ve never needed “Equals” method in Go.

Usually I load machine gun turrets manually. And use them mainly to clear nests early in the game. Later, when I get my hands on oil, I build perimeter with walls, flame and laser turrets. Connect pipes with oil and connect electricity. That do the trick.

That is convenient. This way you can explain anything you like. I think, Sam Harris said “it’s like playing table tennis without a net”.

That is logical. Practically, though, this is used for justification of selected events. If a person confronts with something he doesn’t like, e. g. bugs in his home, he will actively try to change it.