Most language that rapidly add new features gets those features used and that causes the need for containerization on any machine with a release older than $shorttimeperiod. The problem is not old code forwards but code from today back to whatever your distro had at release. With fast moving languages like Rust, Python, and moreso these days even C++ with it's extension you'll eventually find your system repos don't have the required version to turn arbitrary new source code into a running program. It could be a pyenv or a container (flatpack, snap, appimage, docker, etc) but something has to bring in *and contain* the unsatisified deps and provide them.
But I've never had to do that for a Bash or any shell script. They just run even on decades old installs. I assumed this was because bash wasn't getting new features and was just bug fixes and maintainence at this point. But I was wrong. Bash does get new features all the time. Features that older bash versions cannot run.
<phogg> rangergord: bash changes *all the time*. It just doesn't break backwards compatibility very much. <superkuh> It does? <phogg> superkuh: was that intended for me? <superkuh> Yeah, I'm genuinely surprised. I thought it was just bug fixes and such these days. <phogg> superkuh: New features with every release, too. <hexnewbie> superkuh: People simply don't follow the Twitter feed with new features to use them, so you're far less often surprised. Come to think of it, the amount of cmd1 `cmd2` I see suggests even less up-to-date coders :P <superkuh> Well, that destroys my argument. <phogg> superkuh: the POSIX shell command language changes, too, although much more slowly--and absolutely without breaking things. <hexnewbie> In Python everyone's *dying* to have that feature *yesterday* (that includes me) <phogg> superkuh: see https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063.html and https://lists.gnu.org/archive/html/info-gnu/2020-12/msg00003.html for the two latest bash releases.
So why don't we have bash script compatibility problems? I don't know. None of my guesses are based on very much information. I will again just assume that most people, most devs, that work in bash don't care about the latest and greatest. They care about having their script run on as many machines as possible as smoothly as possible. I've been thinking about language/lib future shock in the wrong way. It's not the rapidity of the language that causes it. It's the culture of the devs using it.
[comment on this post] Append "/@say/your message here" to the URL in the location bar and hit enter.
1:14:21, Tue Aug 17, 2021 : /blog/2021-05-07-1.html/, for more than a decade, bash is the shell i relied on. not only do i have it installed, its one of the few things ive compiled from source. i never was much into more limited shells, i never was much into newer fancier ones, i just used bash like a new standard. now that ksh comes with openbsd, i find it is more predictable and less tedious. the reason? fewer features. fewer gotchas in what a string does. some of those substitutions are useful, dont get me wrong, but the stability of ksh is what makes me appreciate it. i am tired of massaging code to work in bash, it has too many rules. and thats after years of tryig to rely on it. simplicity wins here. obviously dos was even simpler, but it did next to nothing and that wasnt enough.