Hacker News Reader

Comment by saagarjha | Hacker News Reader

I don’t see how Go presents anything new in the portability front.

Like Java, I can write a Go program, compile it on my computer for 3 different OSes, ship the binaries, and I can be reasonably sure that it works on other OSes.

All of this has been possible for decades (eg cross compile C++), but Go is the first mainstream compiled-to-native language that I know that makes it easy. Thanks to this, I can run many utilities written in Go on my Windows box, written mostly by people who likely never even tested in on Windows. That's pretty amazing to me.

People just drop a Windows binary on GitHub and think "I'll get the PR if stuff doesn't work". They'd never do that if it cost them effort to cross build a Windows binary. People didn't do that before Go, and many modern OSS command line utilities / server apps only worked on unixes.

The JVM's "write once, run everywhere" doesn't just apply to any OS that happens to have a JVM available... it means any architecture. You don't have to compile one version of your program for MIPS, ARM, x86, etc. The same bytecode will run on any JVM without being touched... something C/C++ (which were popular when Java was being created) couldn't do.

> and many modern OSS command line utilities / server apps only worked on unixes

This, I think, likely has more to do with being POSIX compatible and/or oriented for headless server usage where a shell is "home" for many 'nix admins.

Sorry I think it does mean any OS that has a JVM available. It can't run on ANY architecture without a JVM. Maybe I miss understood what you mean?

On some kind of deployments, the JVM is the OS.

Really? I don't understand? What do you mean?

This is a little bit off. The only architecture supported by Java is the JVM. It is a fictional CPU architecture with predefined characteristics, such as a memory model. The implementation of a JVM is a mapping from a real CPU to the J VM's requirements. So no, JVM doesn't mean 'any architecture', it means 'JVM'. It only applies to OSes where a JVM is available.

That's a bit of a nitpick.

The developer no longer cares what architecture the program will run on, it just works.

You compile to bytecode, and stop caring. The JVM becomes your only target architecture, regardless of what actual architecture the system has.

That's unlike C or pretty much any (all?) other compiled languages around in the early 90's when Java was still Oak and Gosling was just getting started.

> Like Java, I can write a Go program, compile it on my computer for 3 different OSes, ship the binaries, and I can be reasonably sure that it works on other OSes.

With Java, you compile one “binary” and it works not just on three OSes, but all of them that have a JVM available. The beauty of it is that it’s as portable as an interpreted language, no cross-compilation needed at all.

Go is nice, but when you have to deal with some of the real life architectures like as400 or AIX, it silently retreats to the bushes.

Heard about cross compilation while learning Go. Go surely made it mainstream and easy. Maybe thats the reason so many CLI's being build in Go. Before that python was mostly used for CLI but windows does not have python installed by default.

I would like to see how that Windows binary compiled on Linux does WMI.

Sure, and it be confused if your favorite Go iptables frontend would work on Windows.

But there's plenty use cases for which the go standard library offers a sufficiently good abstraction that cross compiling just works. The same holds for JVM apps for ages (and for nodejs etc etc) but not eg for C(++).

As a windows dev I very much noticed an increase in good CLI tools that just work on my box since Go got to the scene. I think that's cool.

Reply on news.ycombinator.com