It seems like the author thought stack traces are underrated because people don’t like exceptions and don’t always throw. It seems like they don’t understand why people don’t like exceptions, and think that stack traces should be there for every case where the author thinks should be an exception, and ties the desire to avoid exceptions to some strawman use case — a nice looking output — and called it “modern error handling”.

Error / exception handling is separate from stack traces. You don’t need to have an exception to have a stack trace, and stack traces aren’t just used for exceptions.

They also seem to not understand why people make do without stack traces in a microservice architecture. That’s simply not true. First off, you can still get stack traces of individual services. And secondly, if you build your services to accept, eg, something like a tracing ID, and print it along your logs, you essentially have a stack traces across services. In a web service, you can track the work done by all your systems for a single request from the client.

Now, onto why exceptions are somewhat disliked. Let’s just get the simple stuff out of the way: they’re generally bad for performance; they’re invisible to the method caller until they run into the problem, meaning you can’t ever ship updates that you’re confident won’t fall over disgracefully; try-catch hell, etc.

For a slightly more philosophical answer, why aren’t your exceptions just cases you need to handle? The try-catch pattern essentially builds up a separate channel of logic where your program needs to operate in but is expressed or recorded in very fragmented ways, forcing devs to have to pop open every function to look at why something is thrown, and hope that somewhere down the stack, no new exceptions are being thrown and not handled. The logic behind exceptions becomes second-class citizens that programmers can easily forget, instead of being front and centre. Can’t divide by 0? Tell me instead of setting me on a separate handling path. Why should I try-catch every single method call, or even property access? Don’t wait for the user to hit the call and just tell me that something is supposed to be impossible, or if I should handle the case where it doesn’t hold any values, right as I compile (dynamic languages can’t really do that).

You come from a healthy background is what I’m hearing. And that’s good, and I don’t mean that in a derogatory way. What you have there is absolutely the right mindset to have. These tools are made by humans, who have their own set of problems they want to solve with their tools. It may not be the best tool, but it can work pretty damn well.

However, it’s also not uncommon to see communities rage and fight over the superiority of their tools, if not just to shun those that they think are inferior. It’s a blatantly childish or tribalistic behaviour, depending on how you look at humanity. And you’ll see this outside of programming too; in the office, in town, on the streets. People engage in this behaviour so that they can show that “I am on your side”, for the side where they think is the right or superior side, based on factors like a perception of group size, a perception of power, a perception of closeness. It appeals to a common human desire to belong to a strong group. It appeals to the human desire to feel safe. And when you start looking at it that way, that’s not too different from how animals behave. It’s important to note that not all humans have the same amount of desire for this sort of tribe, or would give into that desire to engage in such behaviours, but it’s not surprising to see.

In any case, this article is essentially a callout to the sort of toxic behaviour done for the sake of feeling superior, that exists within the programming community, to a point where some may even say is a major subculture.

Is there anyone here who’s familiar with the paper(s) mentioned in the article? I’d actually like to read them, so if you do, it’d be great if you could share it with me. I couldn’t really find it in the article, unless it’s just hidden under one of their links.

I found the following paper with the authors mentioned:

https://arxiv.org/abs/2501.11582

But not sure if that’s it. It does have some semblance to the topic though. My search-fu isn’t really doing me great with just author names though.

I understand that. I have coworkers with about 15-20 years in the industry, and they frown whenever I put a bash script out for, say, a purpose that I put in my example: self-contained, clearly defined boundaries, simple, and not mission critical despite handling production data, typically done in less than 100 lines of bash with generous spacing and comments. So I got curious, since I don’t feel like I’ve ever gotten a satisfactory answer.

Thank you for sharing your opinion!

I’ve never had that impression, and I know that even large enterprises have Bash scripts essentially supporting a lot of the work of a lot of their employees. But there are also many very loud voices that seems to like screaming that you shouldn’t use Bash almost at all.

You can take a look at the other comments to see how some are entirely turned off by even the idea of using bash, and there aren’t just a few of them.

Good point. It’s definitely something to keep in mind about. It’s pretty standard procedure to secure your environments and servers, wherever arbitrary code can be ran, lest they become grounds for malicious actors to use your resources for their own gains.

What could be a non-secure environment where you can run Bash be like? A server with an SSH port exposed to the Internet with just password authentication is one I can think of. Are there any others?

Creature comfort is a thing. You’re used to it. Familiarity. You know how something behaves when you interact with it. You feel… safe. Fuck that thing that I haven’t ever seen and don’t yet understand. I don’t wanna be there.

People who don’t just soak in that are said to be, maybe, adventurous?

It can also be a “Well, we’ve seen what can work. It ain’t perfect, but it’s pretty good. Now, is there something better we can do?”

You’re speaking prophetically there and I simply do not agree with that prophecy.

If you and your team think you need to extend that bash script to do more, stop and consider writing it in some other languages. You’ve move the goalpost, so don’t expect that you can just build on your previous strategy and that it’ll work.

If your “problem” stems from “well your colleagues will not likely be able to read or write bash well enough”, well then just don’t write it in bash.

I’m going to downvote your comment based on that first quote reply, because I think that’s an extreme take that’s unwarranted. You’ve essentially dissed people who use it for CI/CD and suggested that their pipeline is not robust because of their choice of using Bash at all.

And judging by your second comment, I can see that you have very strong opinions against bash for reasons that I don’t find convincing, other than what seems to me like irrational hatred from being rather uninformed. It’s fine being uninformed, but I suggest you tame your opinions and expectations with that.

About shared libraries, many popular languages, Python being a pretty good example, do rely on these to get performance that would be really hard to get from their own interpreters / compilers, or if re-implementing it in the language would be pretty pointless given the existence of a shared library, which would be much better scrutinized, is audited, and is battle-tested. libcrypto is one example. Pandas depends on NumPy, which depends on, I believe, libblas and liblapack, both written in C, and I think one if not both of these offer a cli to get answers as well. libssh is depended upon by many programming languages with an ssh library (though there are also people who choose to implement their own libssh in their language of choice). Any vulnerabilities found in these shared libraries would affect all libraries that depend on them, regardless of the programming language you use.

If production only implies systems in a user’s path and not anything else about production data, then sure, my example is not production. That said though, I wouldn’t use bash for anything that’s in a user’s path. Those need to stay around, possible change frequently, and not go down. Bash is not your language for that and that’s fine. You’re attacking a strawman that you’ve constructed here though.

If your temporary small script morphs into a monster and you’re still using bash, bash isn’t at fault. You and your team are. You’ve all failed to anticipate that change and misunderstood the “temporary” nature of your script, and allowed your “temporary thing” to become permanent. That’s a management issue, not a language choice. You’ve moved that goalpost and failed to change your strategy to hit that goal.

You could use Deno, but then my point stands. You have to write a function to handle the case where an env var isn’t provided, that’s boilerplate. You have to get a library for, say, accessing contents in Azure or AWS, set that up, figure out how that api works, etc, while you could already do that with the awscli and probably already did it to check if you could get what you want. What’s the syntax for mkdir? What’s it for mkdir -p? What about other options? If you already use the terminal frequently, some of these are your basic bread and butter and you know them probably by heart. Unless you start doing that with Deno, you won’t reach the level of familiarity you can get with the shell (whichever shell you use ofc).

And many argue against bash with regards to error handling. You don’t always need something that proper language has. You don’t always need to handle every possible error state differently, assuming you have multiple. Did it fail? Can you tolerate that failure? Yup? Good. No? Can you do something else to get what you want or make it tolerable? Yes? Good. No? Maybe you don’t want to use bash then.

But not everything needs to scale, at least, if you don’t buy into the doctrine that everything has to be designed and written to live forever. If robust, scalable solutions is the nature of your work and there’s nothing else that can exist, then yeah, Bash likely have no place in that world. If you need any kind of handling more complicated than just getting an error and doing something else, then Bash is not it.

Just because Bash isn’t designed for something you want to do, doesn’t mean it sucks. It’s just not the right tool. Just because you don’t practice law, doesn’t mean you suck; you just don’t do law. You can say that you suck at law though.

People have really been singing praises of Powershell huh. I should give that a try some time.

But yeah, we wield tools that each come with their own risks and caveats, and none of them are perfect for everything, but some are easier (including writing it and addressing fallovers for it) to use in certain situations than others.

It’s just hard to tell if people’s fear/disdain/disgust/insert-negative-reaction towards bash is rational or more… tribal, and why I decided to ask. It’s hard to shake away the feeling of “this shouldn’t just be me, right?”

Seems like something that can happen in any languages, though yeah, bash doesn’t make it easier, and it’ll depend on what the cli tool would return given the error (eg does it return some code in stdout or stderr, or some non-zero exit code). Depending on the library (in the language of choice), you may still have to handle such errors manually, eg adding the necessary logic to retry.

And in such a case, I guess it would be prudent to either make sure that the data can be retrieved again, or push it somewhere a bit more permanent (shared fs, or object storage), sort of in a dead-letter-esque style. Seems like the lesson here is to have a fall over plan. The failure mode is not something a proper language and library would necessarily help discover more easily though.

Always welcome a new shell. I’ve not heard of yash but I’ll check it out.

There are times when doing so does make sense, eg if you need the script to be portable. Of course, it’s the least of your worries in that scenario. Not all systems have bash being accessible at /bin like you said, and some would much prefer that you use the first bash that appears in their PATH, e.g. in nix.

But yeah, it’s generally pretty safe to assume /bin/sh will give you a shell. But there are, apparently, distributions that symlink that to bash, and I’ve even heard of it being symlinked to dash.

Certainly so. The same applies to any languages we choose, no?

I honestly don’t care about being right or wrong. Our trade focuses on what works and what doesn’t and what can make things work reliably as we maintain them, if we even need to maintain them. I’m not proposing for bash to replace our web servers. And I certainly am not proposing that we can abandon robustness. What I am suggesting that we think about here, is that when you do not really need that robustness, for something that may perhaps live in your production system outside of user paths, perhaps something that you, your team, and the stakeholders of the particular project understand that the solution is temporary in nature, why would Bash not be sufficient?

I suspect you just haven’t used Bash enough to hit some of the many many footguns.

Wrong assumption. I’ve been writing Bash for 5-6 years now.

Maybe it’s the way I’ve been structuring my code, or the problems I’ve been solving with it, in the last few years after using shellcheck and bash-language-server that I’ve not ran into issues where I get fucked over by quotes.

But I can assure you that I know when to dip and just use a “proper programming language” while thinking that Bash wouldn’t cut it. You seem to have an image of me just being a “bash glorifier”, and I’m not sure if it’ll convince you (and I would encourage you to read my other replies if you aren’t), but I certainly don’t think bash should be used for everything.

No. If it’s missing $1 will silently become an empty string. os.args[1] will throw an error. Much more robust.

You’ll probably hate this, but you can use set -u to catch unassigned variables. You should also use fallbacks wherever sensible.

Absolutely not. Python is strongly typed, and even statically typed if you want. Light years ahead of Bash’s mess. Quoting is pretty easy to get right in Python.

Not a good argument imo. It eliminates a good class of problems sure. But you can’t eliminate their dependence on shared libraries that many commands also use, and that’s what my point was about.

And I’m sure you can find a whole dictionary’s worth of cases where people shoot themselves in the foot with bash. I don’t deny that’s the case. Bash is not a good language where the programmer is guarded from shooting themselves in the foot as much as possible. The guardrails are loose, and it’s the script writer’s job to guard themselves against it. Is that good for an enterprise scenario, where you may either blow something up, drop a database table, lead to the lost of lives or jobs, etc? Absolutely not. Just want to copy some files around and maybe send it to an internal chat for regular reporting? I don’t see why not.

Bash is not your hammer to hit every possible nail out there. That’s not what I’m proposing at all.

I actually love listening to or reading someone else’s war story, and tbh the entire purpose of this post is to dig those up. Bash is one of those places where a lot about it is passed around as tribal knowledge. So I’d really love to hear how things have failed.

This is almost a strawman argument.

You don’t have to shell out to a db cli. Most of them will gladly take some SQL and spit out some output. Now that output might be in some tabular format with some pretty borders around them that you have to deal with, if you are about the output within your script, but that’s your choice and so deal with it if it’s within your comfort zone to do so. Now if you don’t care about the output and just want it in some file, that’s pretty straightforward, and it’s not too different from just some cli that spits something out and you’ve redirected that output to a file.

I’ve mentioned in another comment where if you need to accept input and use that for your queries, psql is absolutely not the tool to use. If you can’t do it properly in bash and tools, just don’t. That’s fine.

With web API calls, same story really; you may not be all that concerned about the response. Calling a webhook? They’re designed to be a fire and forget, where we’re fine with losing failed connections. Some APIs don’t really follow strict rules with REST, and will gladly include an “ok” as a value in their response to tell you if a request was successful. If knowing that is important to the needs of the program, then, well, there you have it. Otherwise, there are still ways you can get the HTTP code and handle appropriately. If you need to do anything complex with the contents of the response, then you should probably look elsewhere.

My entire post is not to say that “you can do everything in bash and you should”. My point is that there are many cases where bash seems like a good sufficient tool to get that simple job done, and it can do it more easily with less boilerplate than, say, Python or Ruby.

That’s my take on the use of bash too. If it’s something that people think it’s worth bring their pitchforks out for, then it’s something you should probably not write in bash.

To each their own really. You have what you’re familiar with, and I have mine. That said, I’m not proposing Bash as a good language. It is by no means that.

Now, to use Python for comparison. With a year of not using it, I’d be asking lots of questions. How do I mkdir? How do I mkdir -p? What about cp or mv and their flags? Did I use to bring in some library to make this less painful?

Cause look, I already use many of these commands in the terminal, basically all the time cause I work in it.

Fwiw, there’s a bash-language-server that can warn you of some syntactical errors.