Live data from Hacker News

Rubish: A Unix shell written in pure Ruby

github.com

51–60 of 111 posts

Re: Rubish: A Unix shell written in pure Ruby

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

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.

Re: Rubish: A Unix shell written in pure Ruby

#53

Earlier quoted context omitted.

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

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

Re: Rubish: A Unix shell written in pure Ruby

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

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.

Re: Rubish: A Unix shell written in pure Ruby

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

Re: Rubish: A Unix shell written in pure Ruby

#59

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

Re: Rubish: A Unix shell written in pure Ruby

#60

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

Post reply on HN