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

Shell-ish scripting in Go with ease

github.com

Post reply on HN
Print view View original

11–20 of 68 posts

Re: Shell-ish scripting in Go with ease

#11

Post by calmbonsai »

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

Re: Shell-ish scripting in Go with ease

#12

Post by 0xbadcafebee » 

  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)

Re: Shell-ish scripting in Go with ease

#13

Post by puika »

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

Re: Shell-ish scripting in Go with ease

#14

Post by geodel »

decasia wrote: post #10

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 th…

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.

Re: Shell-ish scripting in Go with ease

#15

Post by wswope »

Thaxll wrote: post #9
wswope wrote: post #5

Earlier quoted context omitted.

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.

dependency management in Go is best in class what are you talking about? go mod is that good.

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.

Re: Shell-ish scripting in Go with ease

#16

Post by geodel »

wswope wrote: post #5
throwaway77385 wrote: post #4

Earlier quoted context omitted.

How come the hate? That's a pretty strong emotion for something as benign as a programming language.

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.

Huh, people are extracting whole bunch of value in Python at expense of society. Should I blame Python or its contributor for it?

Re: Shell-ish scripting in Go with ease

#17

Post by eschneider »

decasia wrote: post #10

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 th…

This always seemed like the sweet spot for Perl.

Re: Shell-ish scripting in Go with ease

#18

Post by skydhash »

0xbadcafebee wrote: post #12

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…

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.

Re: Shell-ish scripting in Go with ease

#19

Post by wswope »

geodel wrote: post #16
wswope wrote: post #5

Earlier quoted context omitted.

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.

Huh, people are extracting whole bunch of value in Python at expense of society . Should I blame Python or its contributor for it?

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.

Re: Shell-ish scripting in Go with ease

#20

Post by skydhash »

calmbonsai wrote: post #11

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 fro…

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.
Post reply on HN