5 ms·

Has anyone noticed that it is always mentioned that a tool is written in Go, even if this implementation detail has no relevance for the user? Nobody would wri

Has anyone noticed that it is always mentioned that a tool is written in Go, even if this implementation detail has no relevance for the user? Nobody would write "Universal C++ CLI ...".

nicoburns 8y ago
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.
nolok 8y ago
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
Thaxll 8y ago
I've never seen a modern C++ CLI compiled without dependencies.
georgyo 8y ago
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.
koolba 8y ago
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.
- jamespo 8y ago
  not if you use GraalVM :D
  - oblio 8y ago
    Or if you bundle your JVM... you can do it with the regular Java stack.
- innagadadavida 8y ago
  +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 https://github.com/colinmarc/hdfs
danso 8y ago
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.
jerf 8y ago
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.
- burntsushi 8y ago
  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/ https://blog.burntsushi.net/ripgrep/
  - jerf 8y ago
    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.
bsg75 8y ago
Same with Rust, various JS frameworks...
dbattaglia 8y ago
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.
coffeeacc 8y ago
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.
sctb 8y ago
We've updated the title from “Usql: Universal Golang CLI for SQL Databases” to the original from the linked page.

Has anyone noticed that it is always mentioned that a tool is written in Go, even if this implementation detail has no relevance for the user? Nobody would write "Universal C++ CLI ...".

nicoburns 8y ago

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.

nolok 8y ago

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

Thaxll 8y ago

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

georgyo 8y ago

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.

koolba 8y ago

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.

jamespo 8y ago
not if you use GraalVM :D
- oblio 8y ago
  Or if you bundle your JVM... you can do it with the regular Java stack.
innagadadavida 8y ago
+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 https://github.com/colinmarc/hdfs

danso 8y ago

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.

jerf 8y ago

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.

burntsushi 8y ago
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/ https://blog.burntsushi.net/ripgrep/
- jerf 8y ago
  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.

bsg75 8y ago

Same with Rust, various JS frameworks...

dbattaglia 8y ago

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.

coffeeacc 8y ago

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.

sctb 8y ago

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