Comment by sosodev | Hacker News Reader

Comment by sosodev | Hacker News Reader

My feelings on Go are pretty mixed. I think a significant portion of software can be described inside the box that you’re given with Go but if you enter even moderately complicated territory it becomes a shit show.

I’ve had the displeasure of working on a pretty complicated Go project at work and it’s given me plenty of counters to what OP is saying.

First, Go’s dependency management has been terrible and inconsistent for years. Dependencies started very loose and without any versioning at all and I was bitten many times by this mostly because developers used the looseness of Go get to consume repositories that were never meant to be public APIs and without versioning those repositories had zero guarantees of compatibility.

The community eventually noticed this was a problem and vendoring was introduced but the community and Go itself flip flopped on a “correct” solution for ages which ultimately led to even more package incompatibility. Now we’ve got modules which is a step in the right direction but it’s going to take quite some time for all of the Go projects to implement it correctly. Modules have been nothing but a pain in the arse for us because our Go project has a lot of dependencies.

Another thing I hate is the idea that people spread that Go’s simplicity leads all developers to write simple, clean code. Some developers, I’ve noticed, pine for abstraction like moths towards a lightbulb. In Go abstraction can be very painful to do elegantly and I’ve seen some nightmares where developers have tried. Using reflection on interfaces produces some of the shittiest code I’ve seen in a long time and yet I’ve seen it repeatedly by different developers in different organizations.

I must not be the only one who has noticed these issues because the creator of Go himself made the Go Proverbs (https://go-proverbs.github.io/) which include things like “interface is never clear” and “reflection is never clear”.

Okay, I’m going to stop ranting now but I seriously don’t get the hard-on for Go. I think I kinda got it before I used it professionally.

This is exactly the take I have been expecting to unfold for a lot of developers regarding Go. It is a very compelling language to get started with because it is so reductionist compared to alternatives like Java and C#. This makes learning it very straightforward, to the extent that you would almost want to die defending the language that is feeding your dopamine loop.

But, one day you might wake up and realize it was all a fantasy. That is, if you ever step foot into a shop where you are expected to build a line-of-business application with sufficiently-complex business entities and rules. All of your ideas about how wonderful Go is will fly directly out the window. Sure, you can eventually implement anything in Go. It is Turing complete after all. But, that isn't to say you'll have enough time to implement it. Go advocates will happily dismiss the value of things like LINQ, generics & reflection until they are faced with a reality where tools like these are the most productive way get a feature into production before 2020 hits. If you open your mind up to the possibility of using different (god forbid, unique) approaches to solve problems, you might then find that Go does not even offer the best implementation of these alternative language features.

This is not my experience at all. We've spent the past few years building a multi-hundred thousand line of code distributed system in go and have found that sticking to idiomatic go has been very beneficial in building the thing successfully.

Everything you describe screams to me of choosing the wrong tool for the job.

Go certainly isn't a general all-around fits-all tool, it's a rather specific and opinionated approach. It's almost a given than Go alone can't solve 100% of most company's needs, this is not Js or Python or C#.

So trying to shoehorn a classic OOP or functional paradigm into Go is just asking for trouble, and no the language won't change to become a clone of another (what would be the point?)

If generics and reflection are core to your solution, there are languages for that. Don't make your life harder. Not every codebase needs to be in one language only.

Also have worked in some pretty massive Go codebases. It's about writing the language idiomatically. If you're super concerned with trying to mimic Java-style abstraction and shoe-horning OOP into Go you're going to have an awful time.

If anything, I've found shipping code to be WAY faster in Go than Java due to the much cleaner build system and approach to testing.

The one main area where Go struggles is in math-heavy code where the lack of generics or algebraic types means duplication or code-gen.

But you're right. It's not the be all end all of languages. If anything, it's just a much better substitute for the use cases where Java traditionally excels.

Docker and Kubernetes are not real world enough for you?

I have ported stuff from Java to Go, for my long running app, and very happy.

Also at a client place, over the past year, I developed stuff in Python and Go, where Java was traditionally chosen, and it led to faster execution times, and stable microservices.

Reply on news.ycombinator.com