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.
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.
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.
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.
Rubber duck debugging often helps.
I don’t like being on this picture.
According to physics, movement is relative. So both you and bug family are right.


I would describe a framework as something that you embed your logic into, letting it orchestrate the flow for you. You can use several frameworks in one project.
Morden computers have hardware that generates entropy. It is used for cryptography.
Also, when creating password for yourself, you can use a simple physical dice, it’s truly random.
YAML for human-written files, JSON for back-to-front and protobuf for back-to-back. XML is an abomination.
Now it reminded me of Vladimir Sorokin’s “Horse soup”. Time to read it again.
Martha is Dead. A tragic and frightening story. Heed to the warnings they give at the start, tho. My wife literally got sick from playing it. No other game or movie has touched me that deep.
Gopher, the Go language mascot mixed in with Rust language mascot.
That boils down to maps. With a few helper functions it’s not a big deal. I can’t remember when I needed to unmarshal JSON into map last time, tho.
I’ve already made this choice. Switched from C++ to Go, and now I never want to touch another language at all. Since I’m not writing kernels or embedded, Go is pretty fast for everything else. Not very popular in gamedev, but that’s just a lack of 3rd party libs, specifically native graphics support.
As for other languages, I can’t justify unnecessary complexity that is generally welcome by those language communities. Go is straight simple yet powerful, and I admire that.
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.