I'm simultaneously amazed and horrified (by the strange but amazing love child you've created between bash and ruby). I spent years (nearly a decade) trying to blend ruby and bash to make the perfect shell, and after never being quite satisfied, I eventually gave up and embraced bash. This does get closer/further than I ever could, and is a fascinating project. I'm going to give it a spin, though I can already imagine the biggest obstacle I'll hit: rubish not being available in the remote environments I need it to, meaning I'll either have to install it (and it's not lightweight currently), or I'll have to live in two different worlds, which isn't usually sustainable.
Kudos though, and great work! I can tell you put a lot of thought and effort into it.
I am deeply hopeful that Oil Shell (now just Oils) will get embraced by a big distro as the standard shell at some point. The lowest friction migration I see available while still offering a bunch of improvements.
Yeah. I will probably join their ranks at some point.
Bash maintainer actually implemented the library feature I suggested and it's already dramatically cut down the amount of unsightly bash code I need to keep around and maintain.
I'm getting pretty tired of coping with old stuff just because it's there though. Went through this phase with GNU make too.
I struggle with this too. On the plus side, the devil you know is often better than the devil you don't know, and anything new will require re-learning a lifetime's worth of muscle memory. It's also nice to know that your bash scripts are going to be hyper-portable and will still work even many years later. The muscle memory is also real. However it isn't great to be constrained with unsightly code for sake of extreme backwards compatibility. I've found a nice balance personally where I use ruby if I need anything that bash isn't good at, but it's never a perfectly clean split.
> It's also nice to know that your bash scripts are going to be hyper-portable
Doubt. I'm up to my neck in bashisms, and I require the very latest bash on top of that.
import() {
local f
for f in "$@"; do
[[ -v loaded[$f] ]] && continue
loaded[$f]=1
source -p "${HOME}/.local/lib/bash" "${f}"
done
}
import arguments terminal
Well yes, if you're using newer features, it's not going to be available on older systems that lack a newer bash version with those features available. I think that's pretty reasonable, otherwise we'd have to freeze the language and never add anything. But your older scripts will be very portable between future systems, and across different distros once they update. If you need to target an older system, you can't use newer features, but that's true of everything so I wouldn't expect any different from bash.
... and many also have succeeded. fish would not be as popular as it is otherwise, other alternative shells that break bash compatibility are being worked on and are gaining traction, elvish, nushell, murex...
mixing shells is not as hard as some people claim. it's like switching programming languages. i do that all the time. but then, i avoid bash scripting as much as i can (or shell scripting in general). if you actually enjoy bash scripting then switching may be harder.
I might be in a minority, but I actually prefer fish as an interactive shell and bash (or plain /bin/sh) for scripting, if anything because that's what I'm used to :), and it's portable
I did the same thing but I'm now pushing it a bit further: POSIX shell rather than Bash for scripts. If what I'm doing can't be done with that it suggests that I should probably just write it in Python or Perl instead.
Fish scripting is limited to functions/aliases and this works out well since they're easy to read and tweak over time.
that's a sensible approach. fish does have the best interactive interface out there. i switched to elvish because i like it better for complex commandlines, mainly because it has support for more advanced data structures and also integrates json well. (and i realized that using braces for code blocks is nicer in a complex one line command, but both are better than bash for interactive use)
disagree. the fact that i can see more and more support for fish and also start seeing support for elvish shows that those alternative shells have reached a scale meaningful enough that tool developers actually consider it worth their effort to support them. what else is that if not evidence that alternative shells have reached a meaningful scale?
before fish basically noone dared to break bash compatibility. zsh is bash on steroids and other incompatible shells like csh, tcsh, ksh, etc were dead ends in that they kept a niche status.
fish was the first shell to break out of that and actually get noticed and gain a following. i believe that all other alternative shells after fish were encouraged only because of fish's popularity.
I'm recently seeing more and more Ruby projects that are at least partly vibe-coded, and I'm kind of torn. On the one hand I appreciate that this allows people to create stuff that they maybe wouldn't have the time to do otherwise. On the other, the code itself makes it harder for people to contribute, especially those, like me, who don't use coding agents.
Where are the interface boundaries? Why are there methods that are 200 lines long? This is not a dis at the author, and it's not really about "code quality" per se, whatever that means. It's just that if someone would like to study the code and be able to improve it or add features, how would one go about it? Does this mean you have to use a coding agent in order to contribute? I felt the same about the recent Ruby compiler from matz [1]. The code looks impenetrable. What does this bode for the future of OSS?
> Where are the interface boundaries? Why are there methods that are 200 lines long? This is not a dis at the author, and it's not really about "code quality" per se, whatever that means. It's just that if someone would like to study the code and be able to improve it or add features, how would one go about it?
Tbh that sounds like quite a lot of codebases from single developers rather than teams I've tried to look at over the years long before LLMs were a thing, and not specifically just for one language (although when it's in a dynamically-typed language it certainly increases the difficulty). Probably quite a lot of training code for LLMs was like this (the people who trained it have access to basically the entire set of code that I did, after all), and the way to avoid it is basically the same: someone has to just care enough to either not write it like this in the first place or take the time to fix it.
As someone who's for a while been a hardline "both developers and users of open source owe each other nothing" advocate (other than the basic human respect that I believe we all owe each other, and that's not specific to open source), I don't really see LLMs as fundamentally changing that calculus. People will create open source, other people will decide to use it or not, maybe to try to contribute back or not, and the maintainers will decide to include those contributions or not, maybe someone decides to fork it, or write a replacement for it because they can't stand the choices or the code of the original, and all of that is basically how things are supposed to work. The system isn't perfect, but I'm not sure what the alternative would be, because putting any further obligations on either side would create worse problems than the ones they solve.
(Some people will choose not to release the source code for their projects instead, and that's fine too, even if in the long run I'm sometimes sad at the result of "this thing that I'd like to run doesn't really support being run in the way I want, and the author is long gone and probably wouldn't even be inconvenienced by my own personal modifications that I don't have any need to distribute". Lots of people will make choices that I wouldn't personally make, but that doesn't inherently make them bad, because other people understanding the rationale is not a particularly good measure of whether something should be allowed or not compared to, like, whether you're actually hurting anyone by doing it).
I think i can handle this code by hand in fact it’s better than code I have handled by hand. (at a cursory glance.)
In my day - I think it was around 2000 – I was handed a 5000 line perl script that both responded to CGI bin requests to run a store and kicked off fulfillment of the orders. Inside that script, it had two 1500 line long subroutines that sometimes navigated internally via goto.
We refactored, and added new features while a profitable business ran on top of the code. You don’t get quite the velocity you do on good code, but it’s manageable.
I think there’s a difference between inheriting a codebase that you can freely refactor, and contributing to someone else’s open source project.
I’m usually trying to find the smallest practical change to accomplish my goal: giving them less to review / consider, and keeping the architecture close to their preferred style.
Honestly I don't know why would you choose ruby for vibecoding.
This is a language that explicitly sacrifices important stuff like the strength of automatic checks possible and performance in lieu of developer ergonomics. Even if you support that particular choice, chosing the language when you won't be writing or reading most of the code is a pretty poor tradeoff.
The interesting part is that agents are good at adding the safety layers (type safety) that exist for Ruby, but which add developer/cognitive overhead (such as Sorbet).
I actually find, for some reason, that LLMs seem to be able to be more "creative" when it comes to Ruby (having used LLMs across 4-5 languages). I don't mean hallucinating, but crafting solutions I would not have thought of, even if I've ensured that I've inserted my original thinking at the beginning.
I wonder if there is something about the combination of the expressiveness of Ruby and the way LLMs are closely tied to human language that brings that out. Of course, usual caveat: n of 1 on my own experience, and a dose of bias.
There are indeed so many compelling arguments against using Ruby these days (e.g. performance, type safety, an increasingly small user base), & yet I continue to reach for it because of this effortless expressiveness (& the maturity of the ecosystem).
I choose it because I know and love it. If I gotta go figure out what the bot did, I'd much much rather try to figure out its ruby than anything else. On the browser plugin I'm making, I took one look at the js code it generated then dropped in a ruby-to-js lib.
I know the bot's not sophisticated enough to metaprogram anything, it writes straightforward code that's easy enough on the eyes, if not to my standards of style.
The idea is eventually I want to build the tooling to where I can actually start writing code again. That code will be ruby.
My favorite part of Ruby is the testability. You can test anything, easily, without having to make interfaces and other design decisions specifically around tests.
Testing anything in Ruby is dead simple, and agents are very good at writing the tests.
The REPL is also a big win for agents. Reproducing a bug, or exploring how to build a feature, agents can get a lot of mileage out of a rails console.
A lot of the developer ergonomics are just as helpful to agents.
I honestly don't get why anyone would choose Python over Ruby other than network effects (which just shifts the "I don't understand why they chose it" to the earlier developers rather than eliminating it), but it's pretty clear that a lot (probably most!) people have the opposite opinion. Sometimes people just prefer different things than us, and even if the answer is "they're fond of Ruby and it makes them happy to choose it even if they never look at the code", I can't really blame that line of thinking for a personal project.
It's especially unfortunate because there are great tools (like rubocop) that coding agents can respond to, and actually generate very readable, maintainable, and contributable code.
I think this will improve, but I also think your comment is important for people using agents to read. Speaking for myself, I want people like you to be able to read/understand/contribute to my projects should you desire, so this is a great reminder for me.
I would love to see more interpreted languages offer shells with native constructs for operating as daily drivers shells (not just REPLs). When I first started learning Ruby I used `rush`[0] as my main shell. Being immersed in the language, even if there were a few helpers for shell operations, really helped me reason better about Ruby and think in the language. `scsh`[1] was enlightening as well. Ultimately the ergonomics of both pushed me back to more conventional variant but they were really helpful learning mechanisms.
Not sure if this is related, but i'd love to see more scripting languages (mostly Python) offer facilities which let them take over from shell script for more scripts and one-liners.
Think about what it would take to write this in Python right now:
for wmv_file in $(find $1 -name '*.wmv'); do
echo -n "${wmv_file} "
ffmpeg -i $wmv_file ${wmv_file%.wmv}.mpg 2>&1 | grep kb/s: || echo "ERROR $?"
done
With a few handy variables and functions predefined, this could be something like:
for wmv_file in find(argv[1], glob="\*.wmv"):
print(wmv_file, end=" ")
result = do("ffmpeg", "-i", wmv_file, basename(wmv_file, ".wmv") + ".mpg")
if result: print(grep(str(result), "kb/s:"))
else: print("ERROR", result.status)
Ruby does a pretty good job, with `system` and backticks. The FileUtils module actually defines some nice helpers like `mv`, `cp` and `ln_s`. So you can do `cp "/tmp/a.txt", filename`. And you can get a list of files matching a glob with `Dir["/tmp/*.txt"]`.
Ruby is compiled, it JIT compiles the code, in theory it should be on par with go once the compiler works out all the code paths, in a long-running application, you should expect the whole codebase to be compiled eventually. More:
There is a big difference between JIT compiled _dynamic_ language and ahead of time compiled static language. While modern JS engines show that difference sometimes can be narrowed down with sophisticated JIT and runtime, it is still there.
Ruby's YJIT compiler does compile ahead of time, the details are in the link provided. On the first run it will, if feasible, compile blocks of frequently executed code and stow it away for when it's needed next. So only on the first run is it interpreting everything.
But who cares really? I am not using Ruby for HPC. I use it for prototyping, oneliners for ETL and to glue different moving parts in a system or network together. That's it. Its not doing the heavy lifting anyways.
Yea. Modern Ruby is "fast enough", but it's very real that when Ruby was hitting its peak it was dog slow. It's hard to shake those sorts of reputations (similar to the "can't scale" reputation that Rails got because of Twitter)
The speed argument never convinced me in general, in that whether it is perl, ruby or python, they are all slower than C. So the comparisons really are odd to me.
The "scripting" languages should of course not try to be slow, but people rarely use them for speed-reasons; they use these languages for gains in productivity and ease of writing code, adding features and so forth. That should be the primary focus point.
In the future we may no longer have such a speed penalty anyway.
I would “up” this a little and say that scripting languages “should” be slow in comparison to low level compiled languages. We want eg. runtime evaluation of multis dependent on type. For (cod) example:
subset Even of Int where * %% 2;
subset Odd of Int where * !%% 2;
multi foo(Even $i) { ‘fizz’ }
multi foo(Odd $i) { ‘buzz’ }
say foo for ^9;
slow is relative and frequently irrelevant. If you're just always waiting for network, or for results from postgres or redis or something, then a 100x speedup in your code won't change the user experience. And if you're doing computationally hard work in ruby or especially python, you're doing it wrong because either someone already wrote a native library to do it or you should.
There's also "slow compared to C" and "slow enough that you notice when using it as an interactive shell". Running something like `Dir.each_child('.') {|x| p x}` in the interpreter completes in 1.3 milliseconds, which includes all the separate print calls. It could be much faster if we compute the string to print first and then only issue a single print call, but this is deliberately inefficient to show it doesn't matter in this usecase.
I wouldn't use Ruby for high performance computing. But for scripting (where runtime is not critical), web services (where transport latency will usually far outstrip the few milliseconds your handler takes) or shell use (where humans aren't fast enough to issue a new command every millisecond anyway), Ruby is more than fast enough.
Akira showed me this work in progress in January and I was pretty amazed by it, but I have to be honest—as someone who prides himself on clever OSS repo names, he just absolutely put me to shame. English as a second language but he's a first class punner.
Usually when I see a project flaunting its language like this it elicits a sigh. (You probably know what I am talking about.) This is a happy exception since this project actually promotes a deep integration with its language of choice, so the title and name are fully warranted. Kudos for that.
Your comparison is not quite optimised as you use () which is not
necessary. But I understand the comparison you make.
But, you can write an optimised pipe in ruby too. I actually did
that, because I could not want to be bothered to be restricted via
ruby's syntax for pipe-like operations.
Even aside from that, the original claim was about pipes versus
method chaining. To me these are not orthogonal to one another;
they are very similar. Just with the pipe focusing on tying together
different programs and focusing on input-output functionality.
Method chaining in ruby is a bit more flexible, we have blocks,
and usually the methods chained occur in one class/object or
the toplevel namespace (less frequently though, usually). Even
the pipe comparison is not ideal, because traditional UNIX pipes
don't support e. g. data manipulation via an object-oriented
focus. And I want that (see avisynth, but extend the idea there
via a) nicer syntax and b) data manipulation for EVERYTHING).
I don't see pipe as being exclusive over method chaining or
reverse.
One interesting idea was to add |> elixir's pipe-like operator
to ruby. I like that, but indeed, the net-gain in ruby is quite
minimal since method-chaining + blocks already offer a ton of
flexibility, so I am not sure how |> would fit into ruby 1:1.
Still I like the idea, but anyone proposing |> needs to come
up with really convincing ideas to matz here. Because people
WILL ask what the real difference is to method chaining. Even
fail-safe method chaining in ruby though I absolutely hate
the syntax via ? there ... it reads like garbage to me. Example:
(It has moved since then, so the above link no longer works,
been some years since I first saw it. Upon seeing it my brain
instantly cancelled any use of "&.", even though I understand
the rationale. It is just ugly to no ends. I still like the
|> syntax in Elixir though, even though I can not really see
what this should do in ruby.)
I'm coming from the point of view of nushell, or powershell, both of which can be used for data manipulation (tables and objects respectively). I love programming in nushell compared to something like this.
Note that I just elaborated what I thought was being asked. Parantheses - see what switching professionally to Ruby wonderland to Python does to a person! Just in about half a year needed..
Like the other commenter elaborated for me. My mental model of how programs are composed much prefers the pipe symbol rather than chaining. There's also less typing too. But each to their own.
Apparently a number of people disagree with me, or the way I initially expressed myself, judging from the amount of downvotes I've had. Weird how that happens; tabs and spaces.
I write a horrifying amount of PowersHell and I've always been craving something like that - rather than pwsh reinventing every wheel, just "bash but also with objects".
I have to confess, seeing Claude as a contributor made me sigh, but I still skimmed through and it looked quite thorough and well thought out. So, I don't know if this sits on the thin line between a vibe coded project and an LLM assisted project.
Hmm. The name is a bit awkward since people can call
it "rubbish". The idea is also not quite new in that
many years ago people worked on an ruby-like shell
with OOP support from the get go and they used a
ncurses drop down box too. I forgot the name, but it
must have been before 2010 already, as I vaguely
remember it from talking on IRC back in those days.
I think the main developer was from South Africa, but
I don't remember that much anymore.
A few years ago irb got a facelift, so rubish probably
represents a more modern take on the shell concept.
I tested it and it works too. I wonder how much the
everything-is-an-object idea is extended here. Many
years ago I learned avisynth + virtualdub and I always
liked how they approached filtering. Ffmpeg is great,
but I absolutely hate the filter system it uses and the
ABSOLUTELY horrible syntax. The ffmpeg devs do not seem
to know avisynth, or any alternatives here - so I want
object manipulation with a convenient syntax at all times,
not just for audio/video data but literally for any data.
Naturally ruby would be a good fit by default, but I am
unaware of many ruby developers even wanting to go that
route. If there are still any ruby developers left that
is - ruby has been tanking hard in the last few years,
approaching extinction level, just like perl did before.
There has to be a better influx of new users; the old
+50 years generation isn't going to keep languages alive
really.
Edit: Also I forgot: the idea and implementation is fine,
I just think we need much more of that in general. Ruby is
kind of in a patchy patchwork situation. Where are the epic projects? Rails is also ancient already.
I think Rails both boosted Ruby and killed it. When I ask people about why they dislike Ruby it's usually due to something specific to Rails (plus some comments around syntax which are easily dismissed or accepted).
I used to be a pretty heavy Ruby user and I still love the language, though I have only used Rails sparsely and not by choice.
I had the opportunity to work on a Ruby project for a couple weeks a few years ago and it was such a pleasure to read through the code and interpret it! It was unfortunately another project that was being replaced with something else because Ruby skills were harder to find.
Indeed, I love Ruby, I find rails to be adequate and powerful, but it largely feels like a different language to me. Rails is so heavy on the "magic" while regular Ruby typically isn't. I use ruby a ton for scripts and small applications (especially micro-services in Sinatra) and it's so readable, expressive, and understandable, often even to people who don't know ruby all that well!
But why would it be a first april article? Are there any arguments to be made for this statement? Because the shell works, I just tested it. It may not be everyone's cup of tea but that's always the case for any given software. The primary reason I use bash over, say, zsh, despite thinking zsh is more advanced, is that I use bash mostly because it is very simple. I like simplicity. (Bash could be even simpler, I would not mind. I don't use shell scripts for instance, ruby or python are much more convenient than shell scripts.)
I have been unironically waiting for someone to properly implement something like this. Perfect way to use method_missing in Ruby.
I'm simultaneously amazed and horrified (by the strange but amazing love child you've created between bash and ruby). I spent years (nearly a decade) trying to blend ruby and bash to make the perfect shell, and after never being quite satisfied, I eventually gave up and embraced bash. This does get closer/further than I ever could, and is a fascinating project. I'm going to give it a spin, though I can already imagine the biggest obstacle I'll hit: rubish not being available in the remote environments I need it to, meaning I'll either have to install it (and it's not lightweight currently), or I'll have to live in two different worlds, which isn't usually sustainable.
Kudos though, and great work! I can tell you put a lot of thought and effort into it.
> I can already imagine the biggest obstacle I'll hit: rubish not being available in the remote environments I need it to
The ubiquitousness of bash is among the few reasons why it continues to endure. It will be eternal if nobody tries to replace it.
I am deeply hopeful that Oil Shell (now just Oils) will get embraced by a big distro as the standard shell at some point. The lowest friction migration I see available while still offering a bunch of improvements.
https://oils.pub/
I was excited for this years ago, but when I tried it about 2 years ago, it felt awkward. Is it different now?
Many, many people have tried...
Yeah. I will probably join their ranks at some point.
Bash maintainer actually implemented the library feature I suggested and it's already dramatically cut down the amount of unsightly bash code I need to keep around and maintain.
I'm getting pretty tired of coping with old stuff just because it's there though. Went through this phase with GNU make too.
I struggle with this too. On the plus side, the devil you know is often better than the devil you don't know, and anything new will require re-learning a lifetime's worth of muscle memory. It's also nice to know that your bash scripts are going to be hyper-portable and will still work even many years later. The muscle memory is also real. However it isn't great to be constrained with unsightly code for sake of extreme backwards compatibility. I've found a nice balance personally where I use ruby if I need anything that bash isn't good at, but it's never a perfectly clean split.
> It's also nice to know that your bash scripts are going to be hyper-portable
Doubt. I'm up to my neck in bashisms, and I require the very latest bash on top of that.
The -p flag for source landed in bash 5.3.Well yes, if you're using newer features, it's not going to be available on older systems that lack a newer bash version with those features available. I think that's pretty reasonable, otherwise we'd have to freeze the language and never add anything. But your older scripts will be very portable between future systems, and across different distros once they update. If you need to target an older system, you can't use newer features, but that's true of everything so I wouldn't expect any different from bash.
... and many also have succeeded. fish would not be as popular as it is otherwise, other alternative shells that break bash compatibility are being worked on and are gaining traction, elvish, nushell, murex...
mixing shells is not as hard as some people claim. it's like switching programming languages. i do that all the time. but then, i avoid bash scripting as much as i can (or shell scripting in general). if you actually enjoy bash scripting then switching may be harder.
I might be in a minority, but I actually prefer fish as an interactive shell and bash (or plain /bin/sh) for scripting, if anything because that's what I'm used to :), and it's portable
I did the same thing but I'm now pushing it a bit further: POSIX shell rather than Bash for scripts. If what I'm doing can't be done with that it suggests that I should probably just write it in Python or Perl instead.
Fish scripting is limited to functions/aliases and this works out well since they're easy to read and tweak over time.
that's a sensible approach. fish does have the best interactive interface out there. i switched to elvish because i like it better for complex commandlines, mainly because it has support for more advanced data structures and also integrates json well. (and i realized that using braces for code blocks is nicer in a complex one line command, but both are better than bash for interactive use)
Really like using fish as my interactive shell too.
Many have succeeded writing functional alternative shells for sure, but none have replaced bash at any meaningful scale.
disagree. the fact that i can see more and more support for fish and also start seeing support for elvish shows that those alternative shells have reached a scale meaningful enough that tool developers actually consider it worth their effort to support them. what else is that if not evidence that alternative shells have reached a meaningful scale?
before fish basically noone dared to break bash compatibility. zsh is bash on steroids and other incompatible shells like csh, tcsh, ksh, etc were dead ends in that they kept a niche status.
fish was the first shell to break out of that and actually get noticed and gain a following. i believe that all other alternative shells after fish were encouraged only because of fish's popularity.
I've used bash for 20+ years. I've tried so many other shells but always go back to bash. Thanks Brian!
Why do you always come back?
I had a very similar reaction.
I went the same way with simply bumping up my bash skills.
Part of me feels like I'd prefer pry loaded with a library that provides shell like methods for doing ruby-esque things.
I'm recently seeing more and more Ruby projects that are at least partly vibe-coded, and I'm kind of torn. On the one hand I appreciate that this allows people to create stuff that they maybe wouldn't have the time to do otherwise. On the other, the code itself makes it harder for people to contribute, especially those, like me, who don't use coding agents.
A random example:
https://github.com/amatsuda/rubish/blob/master/lib/rubish/pa...
Where are the interface boundaries? Why are there methods that are 200 lines long? This is not a dis at the author, and it's not really about "code quality" per se, whatever that means. It's just that if someone would like to study the code and be able to improve it or add features, how would one go about it? Does this mean you have to use a coding agent in order to contribute? I felt the same about the recent Ruby compiler from matz [1]. The code looks impenetrable. What does this bode for the future of OSS?
[1] https://github.com/matz/spinel
> Where are the interface boundaries? Why are there methods that are 200 lines long? This is not a dis at the author, and it's not really about "code quality" per se, whatever that means. It's just that if someone would like to study the code and be able to improve it or add features, how would one go about it?
Tbh that sounds like quite a lot of codebases from single developers rather than teams I've tried to look at over the years long before LLMs were a thing, and not specifically just for one language (although when it's in a dynamically-typed language it certainly increases the difficulty). Probably quite a lot of training code for LLMs was like this (the people who trained it have access to basically the entire set of code that I did, after all), and the way to avoid it is basically the same: someone has to just care enough to either not write it like this in the first place or take the time to fix it.
As someone who's for a while been a hardline "both developers and users of open source owe each other nothing" advocate (other than the basic human respect that I believe we all owe each other, and that's not specific to open source), I don't really see LLMs as fundamentally changing that calculus. People will create open source, other people will decide to use it or not, maybe to try to contribute back or not, and the maintainers will decide to include those contributions or not, maybe someone decides to fork it, or write a replacement for it because they can't stand the choices or the code of the original, and all of that is basically how things are supposed to work. The system isn't perfect, but I'm not sure what the alternative would be, because putting any further obligations on either side would create worse problems than the ones they solve.
(Some people will choose not to release the source code for their projects instead, and that's fine too, even if in the long run I'm sometimes sad at the result of "this thing that I'd like to run doesn't really support being run in the way I want, and the author is long gone and probably wouldn't even be inconvenienced by my own personal modifications that I don't have any need to distribute". Lots of people will make choices that I wouldn't personally make, but that doesn't inherently make them bad, because other people understanding the rationale is not a particularly good measure of whether something should be allowed or not compared to, like, whether you're actually hurting anyone by doing it).
I think i can handle this code by hand in fact it’s better than code I have handled by hand. (at a cursory glance.)
In my day - I think it was around 2000 – I was handed a 5000 line perl script that both responded to CGI bin requests to run a store and kicked off fulfillment of the orders. Inside that script, it had two 1500 line long subroutines that sometimes navigated internally via goto.
We refactored, and added new features while a profitable business ran on top of the code. You don’t get quite the velocity you do on good code, but it’s manageable.
I think there’s a difference between inheriting a codebase that you can freely refactor, and contributing to someone else’s open source project.
I’m usually trying to find the smallest practical change to accomplish my goal: giving them less to review / consider, and keeping the architecture close to their preferred style.
Maybe that changes in the AI coded future
Honestly I don't know why would you choose ruby for vibecoding.
This is a language that explicitly sacrifices important stuff like the strength of automatic checks possible and performance in lieu of developer ergonomics. Even if you support that particular choice, chosing the language when you won't be writing or reading most of the code is a pretty poor tradeoff.
The interesting part is that agents are good at adding the safety layers (type safety) that exist for Ruby, but which add developer/cognitive overhead (such as Sorbet).
I actually find, for some reason, that LLMs seem to be able to be more "creative" when it comes to Ruby (having used LLMs across 4-5 languages). I don't mean hallucinating, but crafting solutions I would not have thought of, even if I've ensured that I've inserted my original thinking at the beginning.
I wonder if there is something about the combination of the expressiveness of Ruby and the way LLMs are closely tied to human language that brings that out. Of course, usual caveat: n of 1 on my own experience, and a dose of bias.
I have had similar experiences & we are not alone: https://bytecode.hr/posts/why-ruby-is-the-better-language-fo....
There are indeed so many compelling arguments against using Ruby these days (e.g. performance, type safety, an increasingly small user base), & yet I continue to reach for it because of this effortless expressiveness (& the maturity of the ecosystem).
I choose it because I know and love it. If I gotta go figure out what the bot did, I'd much much rather try to figure out its ruby than anything else. On the browser plugin I'm making, I took one look at the js code it generated then dropped in a ruby-to-js lib.
I know the bot's not sophisticated enough to metaprogram anything, it writes straightforward code that's easy enough on the eyes, if not to my standards of style.
The idea is eventually I want to build the tooling to where I can actually start writing code again. That code will be ruby.
There is a study that reported ruby as the best language for LLM over something like 15 languages
My favorite part of Ruby is the testability. You can test anything, easily, without having to make interfaces and other design decisions specifically around tests.
Testing anything in Ruby is dead simple, and agents are very good at writing the tests.
The REPL is also a big win for agents. Reproducing a bug, or exploring how to build a feature, agents can get a lot of mileage out of a rails console.
A lot of the developer ergonomics are just as helpful to agents.
The performance of Ruby sucks, though.
I honestly don't get why anyone would choose Python over Ruby other than network effects (which just shifts the "I don't understand why they chose it" to the earlier developers rather than eliminating it), but it's pretty clear that a lot (probably most!) people have the opposite opinion. Sometimes people just prefer different things than us, and even if the answer is "they're fond of Ruby and it makes them happy to choose it even if they never look at the code", I can't really blame that line of thinking for a personal project.
Well it may not life up to uncle Bob's clean code standards but it does fit the repo's name, doesn't it?
It's especially unfortunate because there are great tools (like rubocop) that coding agents can respond to, and actually generate very readable, maintainable, and contributable code.
I think this will improve, but I also think your comment is important for people using agents to read. Speaking for myself, I want people like you to be able to read/understand/contribute to my projects should you desire, so this is a great reminder for me.
Tangential:
I would love to see more interpreted languages offer shells with native constructs for operating as daily drivers shells (not just REPLs). When I first started learning Ruby I used `rush`[0] as my main shell. Being immersed in the language, even if there were a few helpers for shell operations, really helped me reason better about Ruby and think in the language. `scsh`[1] was enlightening as well. Ultimately the ergonomics of both pushed me back to more conventional variant but they were really helpful learning mechanisms.
0: https://github.com/adamwiggins/rush 1: https://github.com/scheme/scsh
Not sure if this is related, but i'd love to see more scripting languages (mostly Python) offer facilities which let them take over from shell script for more scripts and one-liners.
Think about what it would take to write this in Python right now:
With a few handy variables and functions predefined, this could be something like:Ruby does a pretty good job, with `system` and backticks. The FileUtils module actually defines some nice helpers like `mv`, `cp` and `ln_s`. So you can do `cp "/tmp/a.txt", filename`. And you can get a list of files matching a glob with `Dir["/tmp/*.txt"]`.
I think Perl is what you're looking for!
have you seen https://sh.readthedocs.io/en/latest/
People think Ruby is a slow language, but little do they know Ruby is a slower language than Go. But ruby these days is faster than Python.
> little do they know Ruby is a slower language than Go
Isn't it generally expected for a feature-packed interpreted language to be slower than a minimal compiled language?
Ruby is compiled, it JIT compiles the code, in theory it should be on par with go once the compiler works out all the code paths, in a long-running application, you should expect the whole codebase to be compiled eventually. More:
https://www.codemancers.com/blog/rubys-jit-journey
There is a big difference between JIT compiled _dynamic_ language and ahead of time compiled static language. While modern JS engines show that difference sometimes can be narrowed down with sophisticated JIT and runtime, it is still there.
Ruby's YJIT compiler does compile ahead of time, the details are in the link provided. On the first run it will, if feasible, compile blocks of frequently executed code and stow it away for when it's needed next. So only on the first run is it interpreting everything.
But who cares really? I am not using Ruby for HPC. I use it for prototyping, oneliners for ETL and to glue different moving parts in a system or network together. That's it. Its not doing the heavy lifting anyways.
when ruby was trendy the 1.9 branch was still cooking so in a lot of people's mind it is veery slow
Yea. Modern Ruby is "fast enough", but it's very real that when Ruby was hitting its peak it was dog slow. It's hard to shake those sorts of reputations (similar to the "can't scale" reputation that Rails got because of Twitter)
Heavy lifting Python libraries are in C and C++
The speed argument never convinced me in general, in that whether it is perl, ruby or python, they are all slower than C. So the comparisons really are odd to me.
The "scripting" languages should of course not try to be slow, but people rarely use them for speed-reasons; they use these languages for gains in productivity and ease of writing code, adding features and so forth. That should be the primary focus point.
In the future we may no longer have such a speed penalty anyway.
I would “up” this a little and say that scripting languages “should” be slow in comparison to low level compiled languages. We want eg. runtime evaluation of multis dependent on type. For (cod) example:
slow is relative and frequently irrelevant. If you're just always waiting for network, or for results from postgres or redis or something, then a 100x speedup in your code won't change the user experience. And if you're doing computationally hard work in ruby or especially python, you're doing it wrong because either someone already wrote a native library to do it or you should.
There's also "slow compared to C" and "slow enough that you notice when using it as an interactive shell". Running something like `Dir.each_child('.') {|x| p x}` in the interpreter completes in 1.3 milliseconds, which includes all the separate print calls. It could be much faster if we compute the string to print first and then only issue a single print call, but this is deliberately inefficient to show it doesn't matter in this usecase.
I wouldn't use Ruby for high performance computing. But for scripting (where runtime is not critical), web services (where transport latency will usually far outstrip the few milliseconds your handler takes) or shell use (where humans aren't fast enough to issue a new command every millisecond anyway), Ruby is more than fast enough.
People think slugs are slow animals... But slugs these days are faster than snails.
Oh my god this is the best name to the application. You win the weekend.
Exactly. Very clever name!
Akira showed me this work in progress in January and I was pretty amazed by it, but I have to be honest—as someone who prides himself on clever OSS repo names, he just absolutely put me to shame. English as a second language but he's a first class punner.
Missing: size, speed comparsion with Almquist shell
This is probably even slower than bash
Great name though
Wow this is so tempting!
As an avid Rails Console (basically an application-aware Ruby REPL) user, this seems familiar. Nice work.
Usually when I see a project flaunting its language like this it elicits a sigh. (You probably know what I am talking about.) This is a happy exception since this project actually promotes a deep integration with its language of choice, so the title and name are fully warranted. Kudos for that.
A+ name, no notes
Upvoted just for the name.
Is it just me of did others also read rubbish instead of rubi-sh...I think that might be the joke. hm...
For a while the preferred templating engine for .erb files was “erubis” which is the Japanese pronunciation for Elvis
The repository owner is a true ruby hero. I am not sure if the name is a joke, and he was just fooling around, but the code is real.
I much prefer the pipe to method chaining.
Could this be elaborated?
ls | grep file.txt vs ls().grep("file.txt")
yeah but chaining is almost ubiquitous - found in js, ruby, python, rust, go, etc
Your comparison is not quite optimised as you use () which is not necessary. But I understand the comparison you make.
But, you can write an optimised pipe in ruby too. I actually did that, because I could not want to be bothered to be restricted via ruby's syntax for pipe-like operations.
Even aside from that, the original claim was about pipes versus method chaining. To me these are not orthogonal to one another; they are very similar. Just with the pipe focusing on tying together different programs and focusing on input-output functionality. Method chaining in ruby is a bit more flexible, we have blocks, and usually the methods chained occur in one class/object or the toplevel namespace (less frequently though, usually). Even the pipe comparison is not ideal, because traditional UNIX pipes don't support e. g. data manipulation via an object-oriented focus. And I want that (see avisynth, but extend the idea there via a) nicer syntax and b) data manipulation for EVERYTHING).
I don't see pipe as being exclusive over method chaining or reverse.
One interesting idea was to add |> elixir's pipe-like operator to ruby. I like that, but indeed, the net-gain in ruby is quite minimal since method-chaining + blocks already offer a ton of flexibility, so I am not sure how |> would fit into ruby 1:1. Still I like the idea, but anyone proposing |> needs to come up with really convincing ideas to matz here. Because people WILL ask what the real difference is to method chaining. Even fail-safe method chaining in ruby though I absolutely hate the syntax via ? there ... it reads like garbage to me. Example:
https://github.com/ruby/ruby/blob/trunk/test/ruby/test_threa...
(It has moved since then, so the above link no longer works, been some years since I first saw it. Upon seeing it my brain instantly cancelled any use of "&.", even though I understand the rationale. It is just ugly to no ends. I still like the |> syntax in Elixir though, even though I can not really see what this should do in ruby.)I'm coming from the point of view of nushell, or powershell, both of which can be used for data manipulation (tables and objects respectively). I love programming in nushell compared to something like this.
The docs literally says that the () on the first ls is required.
Note that I just elaborated what I thought was being asked. Parantheses - see what switching professionally to Ruby wonderland to Python does to a person! Just in about half a year needed..
Like the other commenter elaborated for me. My mental model of how programs are composed much prefers the pipe symbol rather than chaining. There's also less typing too. But each to their own.
Apparently a number of people disagree with me, or the way I initially expressed myself, judging from the amount of downvotes I've had. Weird how that happens; tabs and spaces.
Very clever name!
I write a horrifying amount of PowersHell and I've always been craving something like that - rather than pwsh reinventing every wheel, just "bash but also with objects".
I have to confess, seeing Claude as a contributor made me sigh, but I still skimmed through and it looked quite thorough and well thought out. So, I don't know if this sits on the thin line between a vibe coded project and an LLM assisted project.
Any software tool requires intelligence to be used well, including AI.
Cool project!
Just for fun, looking at code count as a rough measure of complexity.
rubish: 26,842
rc (plan9 shell): 5,888
To be fair, rubish does a lot more than rc. rc is pretty minimal.
rc source:
https://github.com/9front/9front/tree/front/sys/src/cmd/rc
Measures below:
rc:Hmm. The name is a bit awkward since people can call it "rubbish". The idea is also not quite new in that many years ago people worked on an ruby-like shell with OOP support from the get go and they used a ncurses drop down box too. I forgot the name, but it must have been before 2010 already, as I vaguely remember it from talking on IRC back in those days. I think the main developer was from South Africa, but I don't remember that much anymore.
A few years ago irb got a facelift, so rubish probably represents a more modern take on the shell concept. I tested it and it works too. I wonder how much the everything-is-an-object idea is extended here. Many years ago I learned avisynth + virtualdub and I always liked how they approached filtering. Ffmpeg is great, but I absolutely hate the filter system it uses and the ABSOLUTELY horrible syntax. The ffmpeg devs do not seem to know avisynth, or any alternatives here - so I want object manipulation with a convenient syntax at all times, not just for audio/video data but literally for any data. Naturally ruby would be a good fit by default, but I am unaware of many ruby developers even wanting to go that route. If there are still any ruby developers left that is - ruby has been tanking hard in the last few years, approaching extinction level, just like perl did before.
There has to be a better influx of new users; the old +50 years generation isn't going to keep languages alive really.
Edit: Also I forgot: the idea and implementation is fine, I just think we need much more of that in general. Ruby is kind of in a patchy patchwork situation. Where are the epic projects? Rails is also ancient already.
> Rails is also ancient already.
I think Rails both boosted Ruby and killed it. When I ask people about why they dislike Ruby it's usually due to something specific to Rails (plus some comments around syntax which are easily dismissed or accepted).
I used to be a pretty heavy Ruby user and I still love the language, though I have only used Rails sparsely and not by choice.
I had the opportunity to work on a Ruby project for a couple weeks a few years ago and it was such a pleasure to read through the code and interpret it! It was unfortunately another project that was being replaced with something else because Ruby skills were harder to find.
Indeed, I love Ruby, I find rails to be adequate and powerful, but it largely feels like a different language to me. Rails is so heavy on the "magic" while regular Ruby typically isn't. I use ruby a ton for scripts and small applications (especially micro-services in Sinatra) and it's so readable, expressive, and understandable, often even to people who don't know ruby all that well!
Good April 1 article.
But why would it be a first april article? Are there any arguments to be made for this statement? Because the shell works, I just tested it. It may not be everyone's cup of tea but that's always the case for any given software. The primary reason I use bash over, say, zsh, despite thinking zsh is more advanced, is that I use bash mostly because it is very simple. I like simplicity. (Bash could be even simpler, I would not mind. I don't use shell scripts for instance, ruby or python are much more convenient than shell scripts.)
It is a clever title. It would be funny to have an April fool sounding hook but backed by a legit project.