Diving into Go by building a CLI application

Post by pansa2 » Wed, May 27, 2020, 7:55 AM UTC

Cthulhu_ wrote: post #41

winrid wrote: 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.

Node is nice, but maybe a bit verbose and the CLI utilities are a bit low-level. The main downside to Node is that you need an external runtime to run your applications. But I guess the counter-downside to Go is that you need to compile different versions for different platforms; the binaries are not portable.

Post by mpfundstein » Wed, May 27, 2020, 8:12 AM UTC

VexorLoophole wrote: post #35

Groxx wrote: post #28

Earlier quoted context omitted.

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…

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…

Post by kstenerud » Wed, May 27, 2020, 8:24 AM UTC

pansa2 wrote: post #37

boyter wrote: 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…

> [Go] is forgiving enough that you can do exploratory programming in it. I agree with most of your post, but I’m not sure I would describe Go as “forgiving”. In fact, it’s well known for being strict. For example, exploratory programming would be significantly easier if the Go compiler could (optionally) ignore unused variables and unreachable code. I’ve also found exploratory programming in Go is hindered by needin…

    package main

    import "fmt"

    func main() {
        var start int = 1

        breakOuter:
        // for x := start; x 

    $ 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)