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

Ruby: A great language for shell scripts

lucasoshiro.github.io

Post reply on HN
Print view View original

61–70 of 368 posts

Re: Ruby: A great language for shell scripts

#61

Post by pansa2 »

rednafi wrote: post #33

Ruby is slow and encourages an esoteric convention over configuration style of OO code. If you enjoy it, more power to you. However, Python is everyone's second favorite or least favorite language, and it runs laps around Ruby any day. Then there's Go if you need some extra oomph!

> Python […] runs laps around Ruby any day

Is today’s Python much faster than, say, 5 years ago? Ruby was definitely quicker than Python back then.

I’ve heard of performance improvements to Python, but they seem to be 10-25% range which wouldn’t be enough to catch up to Ruby.

Re: Ruby: A great language for shell scripts

#62

Post by lolinder »

cortesoft wrote: post #51
solidsnack9000 wrote: post #46

Earlier quoted context omitted.

Instability. Ruby has not been the same language for very long. Migrating to 1.9 was a huge hassle for many firms. This may seem like a long time ago in tech years; but then there was Ruby 2.0; and shell scripts, meanwhile, have stayed the same the whole time. A secondary reason is that Ruby has been very slow for much of its life, which means that for situations where you need to run a huge stack of scripts -- init…

> Migrating to 1.9 was a huge hassle for many firms. This seems contrary to my experience. We took a large project from 1.8 to 1.9 to 2.0 to 3.0, and it was much easier than we expected. It was a lot easier than our Python 2 to 3 conversations were.

> It was a lot easier than our Python 2 to 3 conversations were.

Python's is (present tense very much intended) notoriously one of the worst-managed transitions in programming language history, so that's not exactly a ringing endorsement.

Re: Ruby: A great language for shell scripts

#63

Post by pilaf »

rednafi wrote: post #33

Ruby is slow and encourages an esoteric convention over configuration style of OO code. If you enjoy it, more power to you. However, Python is everyone's second favorite or least favorite language, and it runs laps around Ruby any day. Then there's Go if you need some extra oomph!

Ruby performance has improved a lot in the last few years, especially with the introduction of the JIT (YJIT), and it keeps improving with every new release. I think the notion of Python being the faster of the two may be outdated. You can see some comparisons in the Benchmarks Game [1] (ignore the reference to PHP and Erlang in the URL, seems to be a typo by the website's maintainer, although my link will break if they fix it).

Also I think the convention over configuration mantra belongs in the Ruby on Rails world rather than Ruby itself. Ruby as a language is far less opinionated about how you do things, especially for small shell scripts.

1: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Ruby: A great language for shell scripts

#64

Post by pas »

lambdaba wrote: post #8

The greatest feature for this is inline deps, something very rare to have built-in (I've only found Deno to have a similar feature): https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...

for Scala there's Ammonite which can do this https://ammonite.io/#MagicImports

Re: Ruby: A great language for shell scripts

#65

Post by sestep »

nequo wrote: post #7
sestep wrote: post #3

Earlier quoted context omitted.

What does LSB stand for?

I assume it means Linux Standard Base: https://refspecs.linuxbase.org/LSB_3.2.0/LSB-Languages/LSB-L...

Thanks, I didn't know about that! I'm curious though; even LSB 5.0 only demands Python 2.4: https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Languages...

Do people really write scripts against Python 2 just so that they're guaranteed to be supported by LSB?

Re: Ruby: A great language for shell scripts

#66

Post by noisy_boy »

seabrookmx wrote: post #13
codesnik wrote: post #9

I sometimes wonder why we don't see ruby used for shell stuff more often. It inherited most of the good stuff for shell scripting from Perl, and Perl took a lot of it's syntax from sh and sed and awk, so almost anything you can do in shell script you can do in ruby, but with an option of making it gradually less terse and more readable, while having sane variables and data handling from the start. Also ruby is great…

I think golang is used because you can easily create a single static binary, which is incredibly easy to distribute. I often find non-trivial CLI tools written in Python cumbersome because of the dependency wrangling necessary.

I think one of the advantages of a script is that you can quickly check what it is doing by simply opening it - an executable won't afford that.

Re: Ruby: A great language for shell scripts

#67

Post by CoffeeOnWrite »

yen223 wrote: post #42
codesnik wrote: post #9

I sometimes wonder why we don't see ruby used for shell stuff more often. It inherited most of the good stuff for shell scripting from Perl, and Perl took a lot of it's syntax from sh and sed and awk, so almost anything you can do in shell script you can do in ruby, but with an option of making it gradually less terse and more readable, while having sane variables and data handling from the start. Also ruby is great…

It wasn't that long ago that all the interesting infrastructure projects (vagrant, chef) were written in Ruby.

fluentd today is a popular (most popular?) log collector in k8s land.

Re: Ruby: A great language for shell scripts

#68

Post by NullInvictus »

codesnik wrote: post #9

I sometimes wonder why we don't see ruby used for shell stuff more often. It inherited most of the good stuff for shell scripting from Perl, and Perl took a lot of it's syntax from sh and sed and awk, so almost anything you can do in shell script you can do in ruby, but with an option of making it gradually less terse and more readable, while having sane variables and data handling from the start. Also ruby is great…

I think the quality of a language for shell scripting is often secondary. What’s of greater significance is where it is at. I.e., does it have it already installed? The answer with Linux and Bash is almost always “yes”. Not so with ruby.

The moment you start asking the user to install things, you’ve opened up the possibility for writing a program rather than a shell script. The lifecycle of a piece of software is almost always one of growing responsibility. This cycle is devastating when it happens to shell scripts. What was once a simple script slowly becomes creaking mass of untestable, poorly understood code playing in the traffic of swimming environments (which grep you got, buddy?).

I guess I’m saying that once you open up the possibility of writing a program, you generally take that option and are usually happier for it. In the “write a program” world, ruby is still good, but it becomes a far harder question to answer whether ruby is still the right choice. There are a lot of languages with a lot of features engineers like.

Re: Ruby: A great language for shell scripts

#69

Post by MatthiasPortzel »

cyclotron3k wrote: post #19

Totally agree! Other tricks I rely on: a) put a `binding.irb` (or `binding.pry`) in any rescue block you may have in your script - it'll allow you to jump in and see what went wrong in an interactive way. (You'll need a `require 'irb'` in your script too, ofc) b) I always use `Pathname` instead of `File` - it's part of the standard library, is a drop in replacement for `File` (and `Dir`) and generally has a much more…

> You'll need a `require 'irb'` in your script too, ofc

irb is a part of Ruby core, so this isn’t true. (It may have been at one point? I’m not sure.)

I love binding.irb. I use it all the time.

Re: Ruby: A great language for shell scripts

#70

Post by amarshall »

simoncion wrote: post #31
cortesoft wrote: post #5

Earlier quoted context omitted.

Ruby is fantastic for the main project language, too! And is also standard on many Linux distros.

Ruby's fine for small to medium-sized projects. It's pretty great for small DSLs. In my professional experience on medium to large-sized projects, its lack of explicit typing, the habit of Rubyists to use its fairly-substantial metaprogramming capabilities at the drop of a hat, and (for projects that include pieces or all of Rails) the system's implicit library loading make such projects a nightmare to reason about a…

Implicit library loading isn’t even the real problem, it’s the global namespace. I think it, more than anything else, makes large projects difficult to manage due to the inability to grok the dependency graph.
Post reply on HN