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

91–100 of 111 posts

Re: Rubish: A Unix shell written in pure Ruby

#91

Post by 3eb7988a1663 »

rirze wrote: post #78
3eb7988a1663 wrote: post #70

Earlier quoted context omitted.

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?

No help here. I daily drive fish, and subscribe to the philosophy that more than 5 lines of bash is probably a mistake. That being said, I still run into bash everywhere and wish that there was a more robust default installed already. Something which did not require pathological monitoring by shellcheck.

Re: Rubish: A Unix shell written in pure Ruby

#92

Post by em-bee »

shevy-java wrote: post #16
ilvez wrote: post #10

Earlier quoted context omitted.

ls | grep file.txt vs ls().grep("file.txt")

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; t…

the difference between method chaining and the pipe operator is that method chaining normally only works on methods that are supported by the object being returned, whereas the pipe operator works on any function that can take that object as input. in other words the pipe operator is a lot more flexible and doesn't require me to patch the objects class in order to add support for the function i want to call with it. method chaining syntax works in rubish because it either defines or pretends that all unix commands are methods of some class that represents the output of a command.

Re: Rubish: A Unix shell written in pure Ruby

#93

Post by em-bee »

shevy-java wrote: post #16
ilvez wrote: post #10

Earlier quoted context omitted.

ls | grep file.txt vs ls().grep("file.txt")

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; t…

your example is here: https://github.com/ruby/ruby/blob/master/test/ruby/test_thre...

although that line could move again, so here is a permalink: https://github.com/ruby/ruby/blob/6c6df00bbcefe/test/ruby/te...

Re: Rubish: A Unix shell written in pure Ruby

#96

Post by ifh-hn »

fhn wrote: post #83
ilvez wrote: post #10

Earlier quoted context omitted.

ls | grep file.txt vs ls().grep("file.txt")

yeah but chaining is almost ubiquitous - found in js, ruby, python, rust, go, etc

But so are pipes, right? Bash, and the many variants, powershell, nushell... Not to mention the languages that implement them with slightly different symbols (|> in R for example).

Re: Rubish: A Unix shell written in pure Ruby

#97

Post by IshKebab »

Crestwave wrote: post #28
faangguyindia wrote: post #7

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?

Generally being interpreted or compiled is a property of the implementation, not the language.

Re: Rubish: A Unix shell written in pure Ruby

#98

Post by pwdisswordfishs »

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…

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

Re: Rubish: A Unix shell written in pure Ruby

#99

Post by fsckboy »

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.

>The ubiquitousness of

and here I was thinking ubiquity was ubiquitous for this concept

>ubiquity of bash is among the few reasons...

I guess I'm getting older than I thought, I feel uneasy pangs every time I use a bashism because /bin/sh is the ubiquitous one.

Re: Rubish: A Unix shell written in pure Ruby

#100

Post by sxldier »

matheusmoreira wrote: post #47
montroser wrote: post #45

Earlier quoted context omitted.

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.

Sorry, which library feature?
Post reply on HN