6 ms·

I used to use shell scripts and jq a lot, but got tired of my scripts growing into monstrous mudballs of Bash hackery. I do my scripting mostly in Go now and i

• thechao 6y ago
  How’s go’s batteries-included story? I’ve got nigh-on 50k lines of Python2 that IT is about to boot. My choice is to port it to ... something. I was going to do Python3 but I’ve always thought that a memory-management-free systems-like language would’ve always been better.
  • eat_veggies 6y ago
    go's standard library and docs are high quality and well designed. You can take a look here to see if it fits your needs: https://golang.org/pkg/ https://golang.org/pkg/
  • cle 6y ago
    There is not a language as batteries-included as Go, that I've found. The standard lib includes almost everything, including an excellent HTTP server and client (even an HTTP proxy), a test framework, JSON/XML/CSV libs, SQL driver, CLI parser, a template library, crypto, etc. The "go" command includes tooling like a package manager, unit test runner, code formatter, static analyzer, race condition checker, code coverage, profiler, cross-compiler, etc. I don't know what you mean by "memory-management-free" though, Go is still a garbage collected language.
    • Evidlo 6y ago
      I'd say Python has more batteries than Go. Also I recently learned Go's CLI parser is pretty weak compared to argparse.
      • cp9 6y ago
        ymmv there but for what I'm looking for Go is usually more helpful than python straight out of the box, specifically because you don't have to reach for a third party library to make simple http requests, which is what I often end up using a scripting language for. I did just pick up argparse though and was very pleasantly surprised about how nice it is, go's `flags` module in the stdlib is unfortunately not quite as nice and is one of the things I reach for a third party library on. However, because it's pure go it still compiles down to a single binary which you can just scp around.
• closeparen 6y ago
  Go's error-oriented style makes it very painful to write long sequences of fallible operations, particularly if your organization has test coverage requirements. I'll write servers in Go all day long, but scripting is the last thing I'd use it for.
  • otabdeveloper4 6y ago
    You're not actually supposed to care about errors. It's the C tradition, YOLO. (bash doesn't care about errors either, by the way.)
  • cle 6y ago
    There is some unfortunate boilerplate involved for scripting, but the benefits dramatically outweight that minor annoyance, IMO. Also, as the script accretes complexity (which happens quite often for me), the disciplined error handling starts adding more value.
    • closeparen 6y ago
      Explain the benefits. "if err != nil { return nil, err }" is implicit for every statement in languages with exceptions.
      • cle 6y ago
        That's only one way to handle an error. The benefit is that it's explicit, not implicit, and it's a psychological nudge to ask yourself "oh yeah this could produce an error, how should I handle it?". I can scan code and see where all the errors occur and how that particular component intends for each to be handled. And handling errors in concurrent code is consistent--still passed as values. Languages with implicit stack-unwinding exceptions have inconsistent ways to deal with the errors because, in concurrent programs, error handling doesn't end once the stack is unwound, because there are lots of concurrent stacks. You then usually catch the exception near the top of the stack and pass it to another stack...as a value. So yes, there is some boilerplate involved in that. But as a codebase grows, I appreciate that the language encourages me and others to be intentional about how errors are handled, and also provides a consistent mechanism for handling them in concurrent code (concurrency is a big reason I use Go to begin with).