Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Diving into Go by building a CLI application

eryb.space

Post reply on HN
Print view View original

91–100 of 124 posts

Re: Diving into Go by building a CLI application

#91

Post by bloblaw »

maallooc wrote: post #58

As much as I like Go I don't think it's ideal for CLI apps. IMO Python is the best at creating simple to complex CLI apps due to it being interpreted and simple. It's an overcharged bash.

I do like Python, but I think Perl is actually designed (and actually is) a super-charged bash. Perl was created with the purpose of simplifying the combination of bash + awk + sed + grep, a goal it has achieved quite well.

Python has better OO and has won more mindshare than Perl, but I don't think it was ever meant (or accomplishes the goal) of being an "overcharged" bash.

Re: Diving into Go by building a CLI application

#92

Post by throwaway894345 »

pansa2 wrote: post #61
maallooc wrote: post #58

As much as I like Go I don't think it's ideal for CLI apps. IMO Python is the best at creating simple to complex CLI apps due to it being interpreted and simple. It's an overcharged bash.

The problem with Python is that it’s really hard to distribute a Python app to users. Nothing beats Go’s ability to compile into a self-contained binary. Python is also slow and has poor support for parallelism. Finally, “Python is simple” only really applies to its syntax. Overall, Go is a significantly simpler language than Python.

"Slow" isn't a typically big deal for CLI apps, but Python culture tends to do a lot of work on initialization, and I've consequently seen a lot of Python CLIs that take nearly 10 seconds to print --help. Because the way most apps and libraries are written, you end up loading and initializing every single library that any part of your CLI uses, even if the subcommand in question doesn't use those libraries (e.g., printing --help). This is solvable via lazy imports, but few go through the hassle of doing this, especially since it makes the code ugly and non-idiomatic.

Re: Diving into Go by building a CLI application

#94

Post by maxioatic »

If anyone would like a book on this subject, I recommend Powerful Command-Line Applications in Go: https://pragprog.com/book/rggo/powerful-command-line-applica...

It's currently in Beta but the first 6 chapters are finished and available. As someone learning Go I found it a nice complement to reading The Go Programming Language.

Re: Diving into Go by building a CLI application

#95

Post by eryb »

zouhair wrote: post #19

Just a note, xkcd has 2 image sizes. Small: https://imgs.xkcd.com/comics/confidence_interval.png Big: https://imgs.xkcd.com/comics/confidence_interval_2x.png Though not for older ones.

Thank you for pointing this out, I didn't about it. How did you come to know? It isn't on their API info page.

Re: Diving into Go by building a CLI application

#96

Post by moreaccountspls »

eryb wrote: post #3
radicalriddler wrote: post #2

I had a similar idea a couple of months ago. Make a CLI in golang that allows me to easily open all my favorite timewaster sites at the start of the work day. But it ended up in the "Started, but never looked at again" pile. Maybe I'll have another look at it on the weekend.

Same thing with me, however I am forcing myself to complete pending projects in this Covid lockdown. Trust me it is always difficult to restart work on pending projects, once you give it two minutes you'll get glued to it. Just force yourself to get started.

Is your goal to learn go (or other language), or to accomplish a specific task (both valid and wonderful goals!)? The reason I ask because if it's the second, I've become dramatically more productive by really learning shell. Just as an example:

  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}'
That took maybe a minute for me to write, vs. like 20 or so minutes for Go. I personally can get stuck in a such a paralysis of doing things the "right" way in a "real" language. So, it's nice to be able to bang out a prototype super quickly and then iterate from there if I want.

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}'

Re: Diving into Go by building a CLI application

#97

Post by mpfundstein »

vips7L wrote: post #72
mpfundstein wrote: post #45

Earlier quoted context omitted.

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?

does it?

Re: Diving into Go by building a CLI application

#98

Post by vips7L »

mpfundstein wrote: post #97
vips7L wrote: post #72

Earlier quoted context omitted.

> start up a whole async event loop Doesn't Go start NCPU event loops every time?

does it?

I'm not a Go dev, but is that not what the go runtime is? An event loop for NCPUs or a work stealing queue that uses NCPUs?

Re: Diving into Go by building a CLI application

#99

Post by sagichmal »

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.

> But I guess the counter-downside to Go is that you need to compile different versions for different platforms; the binaries are not portable.

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

Re: Diving into Go by building a CLI application

#100

Post by apta »

Thaxll wrote: post #87
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…

"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..." 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 soluti…

His comment makes sense. golang "goroutines" are finicky compared to other ways of doing concurrency (e.g. Futures/Tasks in Scala/C# or Java's upcoming green threads). There are several reasons to this, not limited to the fact that it's trivial to mistakingly ignore return values (especially errors) when executing `go foo()`. Also, there's a lot of boilerplate involved if you want to start several of them and wait until they're completed, or if you want to compose them. The other languages I mentioned, which have superior abstractions to golang, solve the issue in a much better way.
Post reply on HN