Comment by bob1029 | Hacker News Reader

Comment by bob1029 | Hacker News Reader

Parent Full thread

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.

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.

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.

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