Hacker News new | ask | show | jobs
by dkulchenko 4051 days ago
To me, "written in Go" is essentially shorthand for zero-dep, statically linked, single binary deployment.

This is a pretty big selling point for command-line utilities like rtop, as opposed to utilities written in Java/Python/Ruby/Node/etc. which require their respective runtime to be installed.

8 comments

Yep. It immediately tells me that I probably will have zero issues deploying it, compared to many of the python/ruby/node etc apps these days.
I would agree with this, but rtop is not meant to be installed on every server you want to monitor. The point is that it can remotely monitor any number of servers without previous agent installation. So, being written in go is kind of "useless" in this case, as you only need to install it in your C&C server, so to speak.
> as opposed to utilities written in Java/Python/Ruby/Node/etc. which require their respective runtime to be installed.

In Java's case only by those that don't know what the Java eco-system offers.

There are plenty of commercial JVMs that offer AOT compilation, including static linking.

Plus as of Java 8, there is even a packager as part of the reference JDK.

I'm curious to know more about these. Are any free? Are any open source? These aren't rhetorical questions, there's a ton of Java stuff I'd want to test it with.

I tried robovm, it actually worked nicely but apparently only does 32 bit. Also, the simple reference HelloWorld was nearly 10MB, the build process took 20 seconds, and running it took 15x longer than a comparable one in Go. I don't mean to knock it, what it does is amazing, but it's not a viable replacement for simple static command line tools.

> Are any free? Are any open source?

No, most of those that produce good quality code are commercial, hence why I stated that on my comment.

Some of most well known,

http://www.excelsiorjet.com/

http://www.atego.com/products/atego-perc/

https://www.aicas.com/cms/en/JamaicaVM

http://www-03.ibm.com/software/products/en/real-time

https://www.codenameone.com/

Oracle Research has SubstrateVM as part of Graal, but it is still experimental.

https://wiki.openjdk.java.net/display/Graal/Publications+and...

There's also RoboVM for compiling to native binaries.
This. Knowing that a command line / server side tool is written in Go conveys that it's very easy to install and dependency free.
You're probably getting downvoted for saying "This."
Ah okay! Will refrain from doing that next time :) Thanks!
Me taking note: do not ever again distribute tools in source code in .tar.gz by default. Provide pre-compiled, copy & run binaries.
Since the same is true of Haskell, can I add this tagline to everything made with Haskell without people complaining?
It is as easy to achieve in so many languages (zero-dep, statically linked, single binary). I think this is part of the best practices more than the language itself.
It doesn't seem that easy. How would you do that in Python or Ruby? Indeed, you can't easily do it with anything that links against glibc as it wont do static linking for some things, so even for C code it can be non trivial (install Musl libc).
Since Go is compiled it would be fair to see the other compiled languages, but I guess even Python and Ruby has some level of support.

OCaml -> http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual025.ht... Rust -> rustc -C link-args=-static-libgcc hello.rs C -> gcc -o foo main.o -static -lbaz -lbar Python -> http://www.py2exe.org/ Ruby -> https://github.com/larsch/ocra

Isn't Python installed by default on most distros?
Most != all. Which version of python are you talking about? Has it been updated recently? Are there other python libraries required by the project? I could go on. There's a huge difference between "no dependencies" and "a simple dependency".
This is a client-side tool. You do not have to deploy it. Any such tool would have zero dependencies server side. Client-side you can pip install most things in a few seconds.
Shipping python projects isn't easy. Even if you have a prefect package on pypi, that specifies its dependencies, it may conflict with other tools using other versions of those libraries.

Compiling python does not feel right.

Using native packages is better[1], but you have to plan it out. You can package virtualenvs into native packages[2] - and this is probably the most solid way, but you'll need packaging setups for various package managers.

In short, "written in Go" for me means with a high probability, just run "go get x" - or download a binary.

Since we are at it, I'd love to hear about better shipping strategies for Python projects.

[1] https://hynek.me/talks/python-deployments/ [2] https://labs.spotify.com/2013/10/10/packaging-in-your-packag...

> In short, "written in Go" for me means with a high probability, just run "go get x" - or download a binary.

Then you have to install & compile `go get` first, no?

When you mean shipping, do you mean deploying production apps to the cloud or just downloading/using top-like tools as a user?

I thought we were just talking about resource monitoring something. I think deployment is a totally separate subject. But for a top-like Python tool, I really like "glances". It has way more features than this Go version.

But regarding deployments, everything works if you make your own pip packages stored locally for your project. That way if it works on your clean VM, it works when you push to the cloud.