Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rubish: A Unix shell written in pure Ruby

github.com

Post reply on HN
Print view View original

61–70 of 111 posts

Re: Rubish: A Unix shell written in pure Ruby

#61

Post by saghm »

ciconia wrote: post #32

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/ma…

> 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).

Re: Rubish: A Unix shell written in pure Ruby

#62

Post by e28eta »

nmcfarl wrote: post #40
ciconia wrote: post #32

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/ma…

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…

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

Re: Rubish: A Unix shell written in pure Ruby

#63

Post by saghm »

torben-friis wrote: post #46
ciconia wrote: post #32

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/ma…

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.

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.

Re: Rubish: A Unix shell written in pure Ruby

#65

Post by flats »

cknoxrun wrote: post #51
torben-friis wrote: post #46

Earlier quoted context omitted.

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 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).

Re: Rubish: A Unix shell written in pure Ruby

#66

Post by DmitryOlshansky »

vinceguidry wrote: post #59
Crestwave wrote: post #28

Earlier quoted context omitted.

> 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.

Re: Rubish: A Unix shell written in pure Ruby

#67

Post by em-bee »

montroser wrote: post #45
matheusmoreira wrote: post #44

Earlier quoted context omitted.

> 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.

Many, many people have tried...

... 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.

Re: Rubish: A Unix shell written in pure Ruby

#69

Post by nasretdinov »

em-bee wrote: post #67
montroser wrote: post #45

Earlier quoted context omitted.

Many, many people have tried...

... 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 ac…

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

Re: Rubish: A Unix shell written in pure Ruby

#70

Post by 3eb7988a1663 »

matheusmoreira wrote: post #44
freedomben wrote: post #39

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 imagin…

> 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/

Post reply on HN