This is a hurdle, but IMO it's not too annoying if you already have rights to install packages. Just automate interpreter installation in bash if it's not already there. Way too much time and money is invested in fighting the esoteric crannies of Bourne shell when the logic would be much clearer in Ruby or Python.
Ansible's moment in the sun is fading now that Docker came onto the scene, but that was a glorious moment. It's still very useful for anyone with long-running, non-removable machines. Ansible requires Python and allows a great deal of behavior to be defined in simple YAML instructions.
You might have the right to install packages, but that may not solve your problem, that the application may require different version than available in the repo.
The classical case is Ruby + Rails + Passenger + CentOS. While there is SCL with any Ruby and Rails version you might want, that does not mean, that the Passenger package will work with it :(.
Yeah, if you can install packages, then you can run the RVM installation script and install the right version of Ruby. In fact, you don't even need admin privileges if you use RVM.
That will get you off package system for the entire stack and now the maintenance of the whole circus is up to you. Which is exactly what I'm trying to get away from.
I do dislike individual language package managers and ecosystems for this reason, but I think it's gotta be accepted at this point. Practically every language has their own package repo and versioning apparatus now. Ruby has RVM, Node.js has NVM, Python has PyPi/venv, etc. Most projects expect their users to deploy with these and include things like Gemfiles to define dependencies. That usually means if you insist on using the upstream packages provided by the distribution, you're going to have to install them manually and have a bunch of extra headaches to worry about anyway (to be honest, most custom applications are really difficult to get running using only distro-packaged Ruby or Python libs).
The individual language package managers are very nice for development, as you may have any package version you want, and also for non-linux users, where there may be no native package management at all. For operations, however, they suck mightly (that's terminus technicus).
I quite like the SCL [1]. It solves the problem, that you might need different version of node/python/ruby/rails/php/whatever, than is packaged with the OS release of your choice. It has the software nicely packaged and maintained. Now getting third party packages to work with that, that's the problem. Passenger rpm [2] requires system-provided ruby, not just any ruby... I will survive that that App X wants Gem Y installed by rubygem. I won't like it, but it is workable and makes maintenance/updates slightly more difficutlt. But I will not put unpackaged module into Apache config.
Maybe try Crystal (https://crystal-lang.org/) then. It has many of the benefits of Go and a Ruby-like syntax. It feels even more like a scripting language than Go because of awesome type inference, uses a similar model as Go for concurrency, and even has proper generics ;-)
Agreed. I recently transitioned from Rails development to devops, and there's no Ruby on any system by default. My Bash got better fast!
Fortunately Elixir/Erlang releases include all the executables you'll need. They aren't quite as slick as Go binaries, which all live in one file, but it's still pretty cool.
Ansible's moment in the sun is fading now that Docker came onto the scene, but that was a glorious moment. It's still very useful for anyone with long-running, non-removable machines. Ansible requires Python and allows a great deal of behavior to be defined in simple YAML instructions.