3 ms·
Some context to my statements: I'm a SWE that works on infrastructure services and tooling, primarily on Linux but also Unixes. It depends on what I'm doing bu
by kodah 5y ago
Some context to my statements: I'm a SWE that works on infrastructure services and tooling, primarily on Linux but also Unixes.
It depends on what I'm doing but usually Go if an application requires any longevity at all.
I use Python or Java for things that require more dynamic typing. The main usecase here is big data or to prototype applications.
Bash I usually reserve for very small tasks. When I bootstrap services in containers, you'll usually find some Bash. A whole CLI written in Bash? I would not approve that PR. Bash lacks variable scoping for the most part, the ways in which you can implement it are hacky and non-obvious. Bash's syntax and the way it behaves varies by system, even installer scripts have to account for this. As I'm typing this, I realize the Bash code I write generally follows the same testing and constraints as the Makefiles I write.
I don't think I really understand the requirement for "a single document". This departs from programming practices I've built up over the years. When I come across large multi-thousand LOC documents (in any language, much less Bash) I'm usually concerned.
- brimstedt 5y agoAbout the requirements and "single document": Those tasks that I use bash for are usually one-offs, and live on the server they are used on. Thus, it should be easy for the next admin/Dev to find it and understand/fix/extend it. Of course, if there is a more advanced task those requirements fall short and there should be a proper Dev env with source control, tests, etc.
- kodah 5y agoAh, makes total sense. I was conflating the single document requirement with the original post which was seemingly trying to build a CLI tool.