[HN Gopher] Shell-ish scripting in Go with ease
___________________________________________________________________
Shell-ish scripting in Go with ease
Author : begoon
Score : 86 points
Date : 2025-01-31 17:14 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| breadchris wrote:
| pairing this with yaegi [1] would be interesting. You could
| having a REPL open doing os operations and when you get the data
| looking like you want, you select which lines to save to a file.
|
| [1] https://github.com/traefik/yaegi
| AzzieElbab wrote:
| I hate go-lang with passion, but these two libs are really cool
| throwaway77385 wrote:
| How come the hate? That's a pretty strong emotion for
| something as benign as a programming language.
| wswope wrote:
| Not OP, but the usual talking points were covered pretty
| well in this thread from yesterday:
| https://news.ycombinator.com/item?id=42884337
|
| To sum it up, the biggest complaints are error handling,
| null handling, and dependency management. And y'know, being
| backed by a company of ghouls hellbent on extracting value
| for themselves at the expense of society.
| Thaxll wrote:
| dependency management in Go is best in class what are you
| talking about? go mod is that good.
| wswope wrote:
| Referring to this thread:
| https://news.ycombinator.com/item?id=42885476
|
| I don't personally have a bone to pick with Go mod, save
| for how the GOPROXY DoS issue was handled.
| geodel wrote:
| Huh, people are extracting whole bunch of value in Python
| at _expense of society_. Should I blame Python or its
| contributor for it?
| wswope wrote:
| I fundamentally disagree with the assertion that Python
| operates at the expense of society.
|
| Google is an exploitative monopoly. There's been plenty
| of ink spilled on the subject to the point that I feel no
| obligation to repeat it.
|
| While it's true that GVR is currently employed by
| Microsoft, the ecosystem of Python is far more anarchic
| and decentralized.
| johnmaguire wrote:
| I think he was probably making a comment about Python in
| regards to PyTorch and AI's energy usage.
|
| i.e. Whether a language exists "at the expense of
| society" probably depends less on who makes the language,
| and more on what you do with it.
| summarity wrote:
| Strongly opinionated languages beget strong opinions on the
| same, both positive and negative.
| latchkey wrote:
| These sorts of comments always make me wonder what you
| prefer.
| LinuxAmbulance wrote:
| Very nice, bookmarking this!
| decasia wrote:
| I just rewrote a tangled 500 line shell script in go.
|
| It was my first time writing a golang project at work, so I'm
| sure it could have been better. But writing it the naive way,
| with all the required golang error handling, it ended up taking
| about 10x more lines of code in golang than the original bash
| script.
|
| It does have a dramatically better UX (largely thanks to spf13's
| cobra and viper), and is way faster than the original, and the
| codebase is a lot cleaner and more maintainable. So I think it
| was worthwhile for the users and maintainers.
|
| But still, 10x more lines of code. I like the OP, but I'm still
| not sure I would reach for golang for short shell scripts.
| geodel wrote:
| It depends. For single scripts its too much, but if there are
| dozen or so scripts with related/similar tasks, there can be
| common code or pattern to be shared. I have one Go project with
| ~3kloc and does 20 or so operations. But if were to do just
| single operation it would still need ~1.5K line of code.
| eschneider wrote:
| This always seemed like the sweet spot for Perl.
| sigzero wrote:
| It is. Very much so.
| bqmjjx0kac wrote:
| One neat thing about Go that makes it superior to a shell
| script is that it compiles a statically-linked binary. One
| self-contained file! Or N if you support N platforms. Did I
| mention that cross-compilation is trivial?
| c0balt wrote:
| As someone who once inherited a static binary (without debug
| symbols, gotta save those few bytes) that should have been a
| shellscript: Please don't. If your logic reasonably fits into
| a shell script, then put it there.
|
| Posix shell-compatible scripts will also likely work on all
| platforms where you go program would've been run.
| calmbonsai wrote:
| I'm not going to knock the usefulness of the library, but I am
| going to knock its application.
|
| Architecturally, shell scripts should _exclusively_ be for
| bootstraps, configs, or extremely localized (individual
| developer) automation.
|
| The New York Minute you need non-trivial error-handling/flow-
| control it's no longer a "shell script" and deserves a proper
| rewrite in a proper programming language.
|
| Ian Malcom's quote from Jurassic Park comes to mind:
|
| "Your scientists were so preoccupied with whether or not they
| could, they didn't stop to think if they should."
| skydhash wrote:
| This. And this is why I like the init system on FreeBSD and
| OpenRC on Alpine Linux, at least on personal computers. Systemd
| maybe useful on a server, but I only got a few "services" on my
| PC and I much prefer something that I can easily understand and
| hack upon.
| 0xbadcafebee wrote:
| Why shouldn't it be as easy to write system administration
| programs in Go as it is in a typical shell?
|
| 1. Shell scripting offers infinite functionality. You can shell
| script with any program in any language. All it needs to do is
| take input and produce output. And if the functionality doesn't
| exist, you can create it on the fly, without having to follow any
| of the traditional rules of programming.
|
| 2. Shell scripting is a combination of a grammar, operators, a
| few simple functions, and an extremely loose coupling with
| generic i/o and logic. I don't know Go well, but it probably
| doesn't support a similar flexibility. (most languages are very
| proscriptive about _how_ you can use the language, so you usually
| can 't make things as easy as they are in a different, more
| tailored language/interface/paradigm. this is why we have DSLs)
|
| 3. Programmers don't really understand the concept of
| productivity [outside of programming itself]. A programmer would
| solve a problem by taking 6 weeks to design a perfect program to
| do the thing. A Sysadmin would take 5 minutes with a shitty
| language and a shitty tool and get way more done in less time.
| And re-writing everything into a Go library would always be
| slower than shell scripting, because it requires re-implementing
| what a shell script would just use as-is.
|
| Scripting is duct-taping the wheel rather than reinventing it. If
| you want to save yourself a whole lot of time and trouble, just
| use the duct tape.
|
| (also: don't go templates exist? why isn't that used for
| scripting)
| skydhash wrote:
| I believe point 2 is the best. Shell scripts are usually
| software coordinators. Before even starting you already have a
| collection of software that already does most of the work. The
| script is just to speed the execution. As an analogy, it's like
| serving already cooked dishes you ordered. While a programming
| language is like having the ingredients, and cooking everything
| yourself. More versatile, but not that easy. And as you say,
| the first option is better when everyone's hungry.
| graerg wrote:
| >A Sysadmin would take 5 minutes with a shitty language and a
| shitty tool and get way more done in less time.
|
| Most people aren't sysadmins, but occasionally have to do
| sysadmin-like things. I've been programming with python and go
| for years. I've never been able to get the "core" command line
| utilities to really stick in my head. A sysadmin uses them
| every day, whereas I rarely have to reach for them. On the rare
| occasion when I _do_ have to reach for them, it is excruciating
| (what was the flag I need for `find` again?). If it were life
| or death and I had to debug even the simplest sed/awk command,
| it would be death for me! But this package makes perfect sense
| to me and really enables me to write this sort of quick and
| dirty thing in a language I'm familiar with and can confidently
| maintain.
|
| This isn't for everyone, but there's definitely a population
| that can get a lot of value out of this.
| puika wrote:
| If anyone wants to experiment with this lib + yaegi interpreter I
| put up a trivial example at [1]. Composing scripts with LSP
| support and such might be doable with a proper abstraction, in
| the example a main package with a main function is required.
| Interpreting might break some functionality for `script` so
| perhaps rerunning their test suite with yaegi is a good idea if
| you get serious about this.
|
| 1. https://github.com/danicc097/yaegi-script
| tonymet wrote:
| a killer feature would be adding a dep tree like make and using
| goroutines to process the tree concurrently .
| emmelaich wrote:
| Too much syntax for a scripting language IMHO.
___________________________________________________________________
(page generated 2025-01-31 23:00 UTC)