Rubish: A Unix shell written in pure Ruby

Project concept & naming

• Rubish is a Unix-like shell implemented in Ruby, with tight integration between shell commands and Ruby objects.
• Many commenters appreciate the punny name (“rubbish” / “Ruby shell”) and see it as clever, possibly April Fools–style branding but backed by a real, working project.
• Some find the name awkward because it invites “rubbish” jokes.

Pipes vs method chaining

• Debate centers on whether shell-style pipes or Ruby-style method chaining provide a better mental model.
• Pipes: seen as more flexible because they operate on any function that accepts the piped value, without modifying object classes; strongly favored by users of PowerShell/Nushell.
• Method chaining: common across many languages; works well when commands are modeled as methods on a common object.
• Some like Elixir-style |> operators, but others argue Ruby’s existing chaining + blocks already cover most use cases.

Performance & suitability

• Several note Ruby’s reputation as slow stems from older versions; modern Ruby is “fast enough” for scripting, web services, and shells.
• Comparisons to Go, C, and JIT behavior appear, with consensus that dynamic languages remain slower but adequate for their domains.
• For shell usage, Rubish is almost certainly faster than traditional shells for user-interactive workloads, though no hard benchmarks are provided.

Shell ergonomics & portability

• Enthusiasm for language-integrated shells (Ruby, Scheme, etc.) as learning tools and powerful daily drivers.
• Major concern: Rubish will not be installed on remote systems, forcing users to juggle multiple shells; ubiquity is cited as a key reason bash endures.
• Some suggest a middle ground: use a modern/expressive shell for interactive work and keep scripts in POSIX sh/bash or another scripting language.

Codebase size & maintainability

• Rubish has ~26k Ruby LOC vs ~6k for Plan 9’s rc shell; acknowledged as doing much more.
• Concerns about large, monolithic methods and unclear boundaries, possibly linked to “vibe-coded” / LLM-assisted style, making contributions harder without tooling.
• Others counter that messy single-author code predates LLMs and can still be refactored, though with more effort.

Ruby ecosystem & trajectory

• Mixed views on Ruby’s health: some see it as declining and over-shadowed by Rails; others emphasize Ruby’s ongoing strengths in expressiveness, scripting, and LLM-assisted development.
• Common theme: Ruby is valued for ergonomics and expressiveness more than raw performance.