Hacker News Reader

Comment by gher-shyu3i | Hacker News Reader

> Go is for doing the things that Google does on servers,

What does Google do on servers that has not already been served by Java and C++? As far as I know, the vast majority of code both existing and newly written at Google is Java and C++, not golang.

View on HN

Make it easy to ship code? C++ compilation is a nightmare & it's extremely expensive language to teach. JVM tuning is a nightmare and takes a while to setup (at which point it does run well relatively unattended, barring security fixes). With go, you practically need to work to avoid shipping an binary that can copy and run. You can learn the entire language in like two days and it can easily compile as you type with a decent latency to feedback (<1 second, in my experience). Its FFI is about as usable as JNI, maybe a little better once you get past the awkwardness of using a separate stack. Its GC is good enough with reasonable bounds.

Keep in mind, I use rust and c++, primarily. I just look over the fence at go and can appreciate what it does well.

You don’t really need to tune the JVM for most applications other than setting a maximum heap size. More than likely you will make things worse than the defaults.

And I don't see how Go could be better in that respect, other than not allowing tuning. But that's really no different than not tuning the settings on the JVM.

I can't speak for present day, but, while I was still working there a few years ago, they were pushing Golang pretty hard. They weren't being hard-lined, so I'm sure a lot is still done in other languages, but I wouldn't be surprised if Go rivals at least C++ in terms of service count at this point.

They realized C++ sucks for simple services and due to the Oracle litigation they were trying to get away from Java where possible.

Having written backends in C++, Java, Python, Rust, and Golang myself, Golang is far and away the best tool for the job in my opinion.

I guess paying for Go development resources is cheaper than having bought Sun when given the opportunity.

However, Koltin and Android depend heavily on the JVM eco-system, and Google is certainly not going to rewrite everything in Koltin/Native or start using ART outside Android.

Also, the OpenJDK is completely open source (even though it is primarily developed by Oracle employees), it’s not like there is any risk in using it. Google is sued because it created a java-copy instead of buying a license from Sun which explicitly required one for mobile devices.

And since they doubled down on their Android Java flavour, it is now a major headache to produce modern Java libraries that work on Android.

Even if you castrate yourself to Java 7, whatever works depends pretty much on the Android version.

> due to the Oracle litigation they were trying to get away from Java where possible.

not a lawyer here, but isn't the litigation related to Android Java-clone, not 'server-side' java-usage?

Exactly. It seems many people conflate the issue.

I could definitely be wrong. That's how it was explained to me in passing by a co-worker.

well it doesn't make sense... why move away even from server-side java? I mean, you guys can use kotlin which is a combination of all the goodies (functional + ergonomic + type-safer than java/go) that has good java interop... and kotlin's even the official language for android projects...

Reply on news.ycombinator.com