Live data from Hacker News

Diving into Go by building a CLI application

eryb.space

71–80 of 124 posts

Re: Diving into Go by building a CLI application

#71
post #50

Earlier quoted context omitted.

As the typical SysAdmin who likes to automate stuff, I have to agree. I am not experienced enough to talk about language designs. But I can say, that writing some small CLI application and deploying it onto some server is way less work with go. Simply because you can crosscompile the application and generate a standalone binary. Everytime I deploy some Python3.7 Flask Application on RHEL7 I start to scream. You were…

Alternative: I'd say Java (or similar), since it has the language abilities and sophisticated static analysis tools are readily available. But startup time is still not interactively-fast, so for CLIs it's sorta a no. For long-running processes tho I mostly like it, and stuff like compacting GCs keeps it running healthier much more easily than Go. Beyond that, dunno - I usually reach for Python since I've written it…

Java has made some strides with startup time. It's still a little bit slower than python when loading the full vm.

Re: Diving into Go by building a CLI application

#72
post #31

I personally love building CLI tools in Node, since I and my co-workers all have it installed. Nice synchronous STD lib for file manipulation and async/await makes for compact async code. If I worked in a Go shop I'd probably use Go, though.

i always find it 'perverse' to start up a whole async event loop for a tool that then transforms a csv or does some other single task :-) also portability quite sucks. if you use features that my node version doesn't support, i screwed. with go (or C, Rust...), I just compile and distribute the binaries. look for instance how easy it is to install nomad.

> start up a whole async event loop

Doesn't Go start NCPU event loops every time?

Re: Diving into Go by building a CLI application

#73
post #28
post #21

Go is a particularly good language for CLI's I have found. At least compared to Java/C#/Python. It's reasonably fast, compiles down to a simple to distribute binary, and the language is forgiving enough that you can do exploratory programming in it. Go-routines make it especially easy to deal with network calls in it as well. For anything that needs absolute performance though look elsewhere, but even then Go might b…

CLIs are sorta my ideal use-case for Go. Goroutines are so error-prone to control since you don't have many options for abstraction, so it's relatively difficult to build long-running highly-stable programs... But CLIs don't usually need that. They can be ctrl-C'd if they go off the rails, and any dangling goroutines just die when the process dies. The simple distribution, fast startup, simple type system, and yolo-c…

> Goroutines are so error-prone to control since you don't have many options for abstraction, so it's relatively difficult to build long-running highly-stable programs...

Oh? Building long-running microservices is literally my main use of Go, and in my opinion the language excels at it. What sort of issues are you having?

Re: Diving into Go by building a CLI application

#74
post #62

Seems overcooked in some places and undercooked in others. I of course prefer my own CLI template but so it goes: https://github.com/carlmjohnson/go-cli

Would you mind sharing some concrete feedback? I'll make improvements for next time.

While following along locally I got an unhelpful error the first time I ran the program. Ultimately the bug was that I was using a lowercase 'o' instead of a zero '0' in the url builder. The API returned a 404, but the code ignored that and tried to marshal the html error response to the struct and failed.

For your guide, it would be helpful to include a status code check on the response and returning a helpful error message around that.

Re: Diving into Go by building a CLI application

#75
post #31

I personally love building CLI tools in Node, since I and my co-workers all have it installed. Nice synchronous STD lib for file manipulation and async/await makes for compact async code. If I worked in a Go shop I'd probably use Go, though.

i always find it 'perverse' to start up a whole async event loop for a tool that then transforms a csv or does some other single task :-) also portability quite sucks. if you use features that my node version doesn't support, i screwed. with go (or C, Rust...), I just compile and distribute the binaries. look for instance how easy it is to install nomad.

"Start up a whole async event loop" is really just "call one of the event loop APIs in the kernel". It's not like "starting an event loop" is intrinsically costing a millisecond and half a gig of RAM or something.

What a larger system builds around the event loop may be heavyweight, but I think that would generally be less about "using Node" or "using Go" and more about picking up some heavyweight framework within the event-looping language. The event loop itself is generally going to be too light-weight to worry about compared to the things it is waiting on to worry about, until you get to a scale that you're unlikely to reach on a CLI.

Re: Diving into Go by building a CLI application

#76
post #10

Since everyone else is throwing out recommendations I personally think https://github.com/spf13/cobra is the best CLI templating system, especially because of how well it pairs with https://github.com/spf13/viper . Large projects like Hugo and Kubernetes have used Cobra to build their CLI tools, and it's fairly light as well even if you need simpler usage. We use it at my workplace simply for wrapping our microservic…

Great stuff! Does anything like Cobra exist for Java?

argparse4j is really easy to use and feels similar to argparse in Python.

Re: Diving into Go by building a CLI application

#77
post #21

Go is a particularly good language for CLI's I have found. At least compared to Java/C#/Python. It's reasonably fast, compiles down to a simple to distribute binary, and the language is forgiving enough that you can do exploratory programming in it. Go-routines make it especially easy to deal with network calls in it as well. For anything that needs absolute performance though look elsewhere, but even then Go might b…

Cobra is actually probably the worst CLI package to choose, because it encourages/forces you into a globals-based architecture.

https://pkg.go.dev/github.com/peterbourgon/ff/v3/ffcli is one that I've been using recently, which has been a lot nicer.

Re: Diving into Go by building a CLI application

#78
post #10

Since everyone else is throwing out recommendations I personally think https://github.com/spf13/cobra is the best CLI templating system, especially because of how well it pairs with https://github.com/spf13/viper . Large projects like Hugo and Kubernetes have used Cobra to build their CLI tools, and it's fairly light as well even if you need simpler usage. We use it at my workplace simply for wrapping our microservic…

Cobra is actually probably the worst CLI package to choose, because it encourages/forces you into a globals-based architecture.

https://pkg.go.dev/github.com/peterbourgon/ff/v3/ffcli is one that I've been using recently, which has been a lot nicer.

Re: Diving into Go by building a CLI application

#79
post #47

Why would I dive into Go in the first place?

Here are some arbitrary reasons that Go is worth a look:

It's easy to learn, tractable, consistent, performant, and safe.

It's great for writing services. The type system is predictable and catches a lot of problems ahead of time.

It's opinionated about basic stuff which helps avoid clutter (no unused variables or imports allowed, etc).

It fills a lot of the same niche as Python, Java, Ruby, etc, but with some distinct advantages when compared to each of them (and some drawbacks depending on your preferences).

Binaries are standalone, easy to compile (cross compilation), and easy to distribute.

It's fun (subjective, but I enjoy writing Go).

Re: Diving into Go by building a CLI application

#80
post #74
post #62

Earlier quoted context omitted.

Would you mind sharing some concrete feedback? I'll make improvements for next time.

While following along locally I got an unhelpful error the first time I ran the program. Ultimately the bug was that I was using a lowercase 'o' instead of a zero '0' in the url builder. The API returned a 404, but the code ignored that and tried to marshal the html error response to the struct and failed. For your guide, it would be helpful to include a status code check on the response and returning a helpful error…

Understood
Post reply on HN