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.
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.
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.
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.
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?
> 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?
LLM-backed code assistants have brought to languages that have been historically less "toolable" the same downsides that IDEs brought to e.g. Java.
Expectation: nominally, an IDE would do one thing, which is to make it faster and easier to do what you would have done without the IDE.
The reality: IDEs make their programmer slightly more productive and other programmers not using IDEs much less productive; instead of "producing programs, faster", what IDEs do is produce programmers who produce programs that aren't especially work-withable (e.g. navigable) without tooling.
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.
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.
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".
24 comments
[ 0.28 ms ] story [ 43.7 ms ] threadA 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 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
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: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?
LLM-backed code assistants have brought to languages that have been historically less "toolable" the same downsides that IDEs brought to e.g. Java.
Expectation: nominally, an IDE would do one thing, which is to make it faster and easier to do what you would have done without the IDE.
The reality: IDEs make their programmer slightly more productive and other programmers not using IDEs much less productive; instead of "producing programs, faster", what IDEs do is produce programmers who produce programs that aren't especially work-withable (e.g. navigable) without tooling.
Kudos though, and great work! I can tell you put a lot of thought and effort into it.
This is probably even slower than bash
Great name though