from Hacker News

Shell-ish scripting in Go with ease

by begoon on 1/31/25, 5:14 PM with 65 comments

• by 0xbadcafebee on 1/31/25, 9:02 PM

    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)

• by decasia on 1/31/25, 8:28 PM

  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.

• by desumeku on 2/1/25, 3:22 AM

  This site is horrible. Every comment here is trying their hardest to systematically dismantle this library out of existence through the use of nihilistic mind-games about what "shell scripting" "really" "is". All because they don't like a programming language that much.

• by breadchris on 1/31/25, 5:57 PM

  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

• by emmelaich on 1/31/25, 10:51 PM

  Too much syntax for a scripting language IMHO.

• by puika on 1/31/25, 9:16 PM

  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

• by chrooted-user on 2/1/25, 9:38 AM

  This is awesome! I enjoy writing Go and like all the tooling around it. Think shell scripts are hard to read and was already planning to adjust some shell-like-Go-tool this weekend, so this post has perfect timing :-)

• by calmbonsai on 1/31/25, 8:40 PM

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

• by tonymet on 1/31/25, 9:50 PM

  a killer feature would be adding a dep tree like make and using goroutines to process the tree concurrently .

• by pyuser583 on 2/3/25, 3:57 PM

  Plenty of languages have a framework to assist with shell/Bash scripting. Nothing wrong with that.

  If you look at the Python build-in API, it's pretty terrible. In all fairness, Python strives to work equally well on Windows, Linux, and some other things. Good luck with that.

  I prefer doing systems scripting in Python over Bash. But writing converting a Bash script to Python without "Pythonizing" it is a bad time.

• by LinuxAmbulance on 1/31/25, 7:28 PM

  Very nice, bookmarking this!

• by synergy20 on 2/1/25, 5:22 AM

  for larger scripts,just use python or lua. otherwise,bash is perfect