People are fanatic about using tools written in a language they like. If people think that a program written in C will be faster than a program written in Python then it is a feature to them that may or may not be valid.

However modern languages have a lot of trade offs in deployment strategies that are just easier to say by stating the language.

Golang is normally fully statically compiled so getting this tool on a host requires nothing other than coping the completed binary. It often requires nothing at all from the system it is running on. This is an implied feature of the language.

C/C++ code can be that simple, but static binaries are not always possible. And then you require the libaries on the remote machine.

There is a good chance Python will be on a remote machine, but deployment could be complicated. Psql support requires the the libaries to be on that machine for example.

And if the tool was written in node, a ton dependencies and work would be required for a normal user to use it.

I agree that the language should not be a feature, but it is. Containers/snap/flatpak sorta help with this, but they are even more work for the user currently.

It does matter to the user.

A Java based tool requires installation of a JVM and likely has a non-trivial startup time. A Python / Ruby tool requires a runtime and probably some kind of mucking with virtualenv or rvm to work properly. A Node.js tool would require (haha!) a Node runtime and crossing your fingers that the NPM dependencies for what you're going to use to connect to your database haven't been compromised since the last build.

A Go based tool would be statically compiled, start up quick, and not have any external dependencies.

+1 for mentioning startup time. The default Java hdfs client takes 5+ seconds to just startup. The one written in Go is super fast and supports shell completion.

[1] https://github.com/colinmarc/hdfs

not if you use GraalVM :D

Or if you bundle your JVM... you can do it with the regular Java stack.

It's a cycle. We're on the tail end of it now for Go; there's been a couple of occasions where someone posts their project on HN and I'm surprised to notice it's Go without having been advertised as such. Rust is a bit behind Go, but I expect that to happen to me soon now. (ripgrep was close, but IIRC I was introduced via a blog post about how it works full of Rust source. Getting there, though.) Crystal, Nim, and a few others seem to be trying to initiate that cycle now.

Without disagreeing with your broader point, I'm happy to say that ripgrep was introduced using a title that never mentioned "Rust" (that was very much intentional on my part), and there isn't any Rust source code in the intro blog post.[1] To be fair, I did just re-skim it to make sure. There are plenty of references to Rust, but Rust had a very minor role in the blog post itself. It, of course, has a very major role in the viability of continued maintenance and feature development of ripgrep though. :-)

There will hopefully be a ripgrep-related blog post in the near future that will feature Rust quite a bit, but that will be about a library, not a tool.

[1] - https://blog.burntsushi.net/ripgrep/

Fair enough. Skimming over your post, I don't feel too bad as remembering it as having significant code, since it is pretty detailed with a lot of discussion (it's a great post!), but your correction is valid.

I do encourage people in the Rust community to have the confidence to just be in Rust and let people find it out, like you did. There's good reason in the early days to wear the language on your sleeve, but there's also good reason as time wears on to project quiet confidence. Rust is, in my opinion, quite solidly there, at least relative to HN.

It's a benefit to me over it being a Ruby/Node/Python CLI. Means it's likely to be easy to install, and performant.

I've always seen the mention of Go as shorthand that the software in question will be relatively easy to install, being a self-contained binary and all.

nodejs and rust comes to mind as language getting included the same way.

For me "in go" is useful information since I infer "easy to deploy" from it

I think it’s appropriate for a HN thread title. A lot of us are here because we are into coding and may want to see OSS projects in the languages we use. For me at least, the rest of the world can be all about the use cases and end products, but HN should be allowed to get geekier and worry about the language it was coded in.

If you look on the GH read me the Golang attributions are not quite as prominent.

I've never seen a modern C++ CLI compiled without dependencies.

Gets points quicker from the enthusiasts. Same effect as when I found a bug in the std lib a few years back, mentioned round these parts and got voted down. People.

We've updated the title from “Usql: Universal Golang CLI for SQL Databases” to the original from the linked page.

Same with Rust, various JS frameworks...