As I will be switching clients next year, I will also be switching programming languages, from Go …

Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

The author discusses challenges faced while using Go, expressing relief at switching back to Java. Go's simplicity and lack of essential features, discouragement of clean code principles, immature package ecosystem, and cumbersome error handling are highlighted as major pain points. The author advises against using Go for complex software, suggesting it is more suitable for infrastructure work.

Why Go Should Sometimes Be a No-Go

80% of the article seems to have a problem with the philosophy of the core go team and not the language itself.
Complaining that assertions are not in the core language but then mentioning being happy using testify assertions is really just a philosophical complaint.
I’m pretty sure junit is still a thing, so not sure why it’s a go problem.

It seems like you were just disappointed that Go isn’t Java.

AI suggestion mentions
<blockquote>
discouragement of clean code principles
</blockquote>
That’s a big plus.
If the a author is more comfortable programming Java, more power to him.
I’d take Go over Java any time for any project where the JVM isn’t a requirement.

I remember feeling the same early on with Go too. I remember being frustrated with GORM as it was no Hibernate or Django. BUT I have realised this is not needed with Go and is probably where the experience comes in. Stop using Go like Java or C# and its much better.
I agree there are some frustrating aspect BUT I like that the language is small.