Diving into Go by building a CLI application

Generally if you just stick to fan-out-in processing though I find goroutines not too bad.

Everytime I deploy some Python3.7 Flask Application on RHEL7 I start to scream.

You were talking about long running applications and broken goroutines: What is the best alternative? I liked to stumble around in Elixir but I feel bad about deploying some application probably nobody at my office will ever be able to 'fix/update'. Python feels too "sluggish". Since I am no Python Pro I have often the feeling, that I am doing something wrong because the language doesn't show any borders.

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?

This comment does not really makes sense, Go #1 usage is for backend services, so it's indeed long running / stable program.

"They can be ctrl-C'd if they go off the rails, and any dangling goroutines just die when the process dies"

There are solution in Go to handle that case, using context and channel but ultimatly it's not a Go problem if you kill an app right away usually there is no way to clean-up everything in a clean way.

I use it as my daily driver for go development.

main.go:

    package main

    import "fmt"

    func main() {
        var start int = 1

        breakOuter:
        // for x := start; x < 10; x++ {
        for x := 3; x < 10; x++ {
            for y := 0; y < 10; y++ {
                result := y * 10 + x
                // fmt.Printf("Result: %d\n", result)
                // if result == 42 {
                //  fmt.Printf("Breaking")
                //  break breakOuter
                // }
            }
        }
    }

    $ go build
     # example
     ./main.go:3:8: imported and not used: "fmt"
     ./main.go:8:5: label breakOuter defined and not used
    (compilation fails)

    $ go build -gcflags=-warnunused
     # example
     ./main.go:8:5: Warning: label breakOuter defined and not used
     ./main.go:3:8: Warning: imported and not used: "fmt"
     ./main.go:6:9: Warning: start declared and not used
     ./main.go:12:13: Warning: result declared and not used
    (compilation succeeds)

It can actually be a feature, and one of the things that brought me to go, as you can define your own integer (or float, or string, etc.) types, thus making them incompatible with each other:

    type distance int
    type speed int
    func distFor(d distance, t time.Time) speed { ... }
    ...
    x = distFor(x, t) // Oops, that's probably a bug!

As long as my execution path doesn't hit any code containing errors, I can run debug and even modify code in the debugger.

That's exploratory programming.

Personally, I feel you with respect to casting integer types. I'll code away with int's until something suddenly needs an int64 to use a package and I have to cast everything or refactor everything to int64. I once commented in a thread where people were asked, "In hindsight what feature would you like in Go?" I said that int should just be an alias for int64 (and float == float64), since these were the defaults in the stdlib. I was downvoted into oblivion in a thread on hypotheticals. I understand the historical machine dependent 32/64 difference, but since the stdlib made a choice, the default should line up nicely. That said, I mostly run into this in Project Euler problems, so not in my day to day work.

1: https://picocli.info/

2: https://github.com/airlift/airline

Bonus: picocli lets you create native images using Graal, so you can really build native cli executable using Java.

I’ve struggled to find a well-supported command-line argument parser that supports subcommands.

  comic_number=321;  curl -L http://xkcd.com/"$comic_number"/info.0.json | jq '{title, number: .num, title, date: "\(.day)-\(.month)-\(.year)", description: .alt, image: .img}'

edit: getting them all, because who can resist some fun code golf:

  yes | awk 'BEGIN{count=1} {print count++;}' | head -n 2311 | xargs -I {} curl -sL http://xkcd.com/"{}"/info.0.json | jq '{title, number: .num, title, date: "\(.day)-\(.month)-\(.year)", description: .alt, image: .img}'

cat sites-list | xargs -n1 firefox --new-tab

Maybe not, but Go has excellent support for cross-compilation. You can still support users on multiple platforms while only developing and building on one.

Unlike any other language Go lets you create binaries for almost all architectures and OS with a single command, you won't find this in any language.

Why is this a downside? Native binaries are the Platonic ideal for distributing applications.

Doesn't Go start NCPU event loops every time?

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.

All my co-workers have the same version of Node, since we code in Node, so that argument is mute. My point was it depends on your environment! :)

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

You don’t need separate client and models packages. You should have two packages: main (which has only one line) and everything else (call it package xkcd).

Your main continues even after it finds an error in fetching the comic. This is because you can’t return err in main and you didn’t use panic/log.Fatal. You also don’t exit with a non-zero code on error.

The solution to all of this is the one line main function. Main should look something like os.Exit(xkcd.Run(os.Args[1:])). I have a helper package at github.com/carlmjohnson/exitcode so you can return an error with an associated exit code, but you can also be simple and just return an int.

Separate flag gathering/processing from execution. You’re not using global flags, which is a good step, but you should go further and make an appEnv struct that consolidates what you’re taking in from the flags. See here: https://play.golang.org/p/-gs5nqXBSuB

Your client package basically doesn’t need to exist. What you want are some simple convenience wrappers around the http package and a URL builder for XKCD. Make something generic for HTTP and you can copypasta it into your future projects. Basically, it just needs to be httphelper.GetJSON(cl ∗http.Client, url string, data interface{}) error. Saving to disk is a separate idea that you’re conflating with downloading. Make something like jsonhelper.SaveToDisk(path string, data interface{}) error. The timeout stuff you’re doing is overblown. Either just use context.WithTimeout or put a ∗http.Client in your appEnv and have ParseArgs set the default timeout on that.

The stuff with the base URL is unnecessary. Obviously you know the XKCD base URL is a constant and will never change. But don’t you need to set it in an XKCDClient struct for testing purposes? The answer is no. If you take in a ∗http.Client, that can set a different http.RoundTripper for testing purposes and the test RoundTripper can read from memory or do whatever you want. (You can see this principle at work in Google’s Go http libraries. Once you realize how powerful ∗http.Client is, it makes a lot of the hoops other libraries jump through see like a waste of time. It can do all your auth stuff, caching stuff, everything. It’s great.)

The model package should just be a file in your xkcd package. I find the names Comic vs. ComicResponse confusing. Do you need Comic at all? Maybe just add some nice helper methods onto ComicResponse. Don’t do cr.FormattedDate() string. Do cr.Date() time.Time and let the output layers handler formatting, not the model layer. The c.JSON() string method doesn’t need to exist. With Go, you can run into this problem of trying to make things more convenient by adding helpers but you end up with methods that just run two commands and don’t actually make things more convenient on net. Is this really a model level concern or should it just be in the xkcd.Run() function?

Anyway, not to be overly negative. For such a small app, none of this really matters. I’ve been making a lot of Go CLIs for a long time[1] and my experience is that the most important thing is to separate flag stuff from execution, and everything else is not a big deal to let evolve over time. The main challenge is avoiding create abstractions that don’t actually pay for themselves in setup time vs. time saved in extension.

[1]: https://blog.carlmjohnson.net/post/2018/go-cli-tools/