Hacker News Reader

Comment by victor106 | Hacker News Reader

As awesome as Go is, Java & SpringBoot are so entrenched in the enterprise world that Go has to come up with something much more awesome.

It's very hard to justify why teams within an enterprise should not use Java/SpringBoot. A typical enterprise already has thousands of developers who support and develop existing critical business applications. Due to historical reasons most of these developers are familiar with Java and they find it hard to justify using another language.

That coupled with the fact that Java and SpringBoot made some really good choices and can compete with most newer language features, its hard for other languages to penetrate that.

View on HN

the support tooling for java is fantastic. Profilers, APM tools that can trace webapps, visual debuggers and so on. Most of the tooling just works.

We have part of our application written in another language/framework and while developing in it is fun and easy, it is a nightmare to debug and maintain in production.

People complain about the verbosity of java, but that makes it great for projects where lots of people are working on it over the years. It is fairly easy to see what is going on. (spring complicates things a bit). Contrast this with say, clojure, where sometimes I have to spend an hour trying to figure out what a blob of code I wrote last year does.

If we're talking about Go, the tooling is good, your IDE will be pretty snappy because of the dedication to single-pass parsing, and you have to really work against the language to write complex and confusing code. The trade-off is that your first write can be more tedious (I really miss filter/map type operations for instance).

The good news is that Go have very little entry point. Thanks to that you can hire people, who are working in other technologies and are interested in learning something new. From my experience they can be productive within a week. It's totally not possible with Java I guess ;-)

It's probably a bigger problem to justify it on the company level. It's always some risk to go with a language that doesn't have such good position on the market ("Who will maintain it?", "Where you will find people who will fix it?", "Wouldn't this language disappear in 2 years?").

Fortunately, a lot changed in recent years. Thanks to Kubernetes, Prometheus, Docker and all other infrastructure Go is already used in the most of the companies. That's giving people much more confidence about Go.

You're missing one key question in your list: "How much (time/money) will it cost and what will be the gain?" Two key aspects to that question: whether/when/how to re-write existing systems in Go and how re-written or new implementations integrate with the existing ones. That's probably the most important question, actually.

> You're missing one key question in your list: "How much (time/money) will it cost and what will be the gain?"

I guess it depends on the situation of the company. But I guess that before doing such movement, company should do a pilot to verify if introducing Go can solve currently existing issues (with development velocity, bugs, performance etc.). After that answer should be simpler :)

> Two key aspects to that question: whether/when/how to re-write existing systems in Go and how re-written or new implementations integrate with the existing ones. It also really depends, but from my experience companies that were switching to Go were keeping legacy part and people who were able to maintain it. In the meantime they re-written what was worth to be re-written. Without touching old part too much.

In that case yo can stay with a situation where you have some developers of old technology and some of the new one. But AFAIK it was not a major issue.

Also as the context, most of these companies where PHP, Python, Ruby or NodeJS. In that case migration to Go had a lot of clearly visible benefits.

More of a question when you start a new project, no?

"Go is already used in the most of the companies" - there is nothing close to truth in this statement.

Reply on news.ycombinator.com