3 ms·

Speaking from some experience, Go is probably the best option these days at "do one thing well" command line tools - the mix of library support, native binaries

Speaking from some experience, Go is probably the best option these days at "do one thing well" command line tools - the mix of library support, native binaries, and the simple, stable language make it a good fit for a weekend project that opens files, munges strings and pushes them over standard protocols. When Go has to support a large application that defines a platform in itself, the downsides of the language rise to the forefront, but that level of expression usually isn't entailed in a Unix-style CLI tool. (Rust also has more potential for performance scaling in this space, but with the "if you have the time for that" kind of caveat.)

majewsky 6y ago
> Rust also has more potential for performance scaling in this space, but with the "if you have the time for that" kind of caveat. When you have a CLI for some network-based service, the network latency is going to be magnitudes larger than the performance differences between Go and Rust anyway. (Or at least in 99% of cases.)
- tonto 6y ago
  some suggestions are that in the future, the I/O latency is going to get very low, network speeds very fast, etc. [0] https://www.youtube.com/watch?v=SM3PhGGllL0&feature=youtu.be https://www.youtube.com/watch?v=SM3PhGGllL0&feature=youtu.be [1] https://www.ece.rice.edu/~willmann/teng_nics_overview.html https://www.ece.rice.edu/~willmann/teng_nics_overview.html
  - majewsky 6y ago
    Unless that 10-gig NIC messes with the speed of light, I don't see it reducing the RTT between me and some server in the US by any significant amount.
CogitoCogito 6y ago
One thing I hate is that the go flags package sorts the options by default. Ordering options in a thoughtful way is definitely a plus in an api. I know there are (not very intuitive) ways to override this, but I just can't understand why they would make such a bizarre choice even given their penchant for being opinionated. edit: Now that I read this over, this complaint seems a bit misplaced in this thread, but I guess I'll leave it due to its sort of relation to cli programs in go.

majewsky 6y ago

> Rust also has more potential for performance scaling in this space, but with the "if you have the time for that" kind of caveat. When you have a CLI for some network-based service, the network latency is going to be magnitudes larger than the performance differences between Go and Rust anyway. (Or at least in 99% of cases.)

tonto 6y ago
some suggestions are that in the future, the I/O latency is going to get very low, network speeds very fast, etc. [0] https://www.youtube.com/watch?v=SM3PhGGllL0&feature=youtu.be https://www.youtube.com/watch?v=SM3PhGGllL0&feature=youtu.be [1] https://www.ece.rice.edu/~willmann/teng_nics_overview.html https://www.ece.rice.edu/~willmann/teng_nics_overview.html
- majewsky 6y ago
  Unless that 10-gig NIC messes with the speed of light, I don't see it reducing the RTT between me and some server in the US by any significant amount.

CogitoCogito 6y ago

One thing I hate is that the go flags package sorts the options by default. Ordering options in a thoughtful way is definitely a plus in an api. I know there are (not very intuitive) ways to override this, but I just can't understand why they would make such a bizarre choice even given their penchant for being opinionated. edit: Now that I read this over, this complaint seems a bit misplaced in this thread, but I guess I'll leave it due to its sort of relation to cli programs in go.