My first application of Ruby was to use it for shell auto-completions. I'm so grateful that I learnt Ruby first, and then Rails. Ruby is a great language to get some utility working out real fast. Rails is great for MVP. I fail to understand why people bitch about Ruby/Rails by comparing them to other languages/frameworks.
Ruby: A great language for shell scripts
221–230 of 368 posts
Re: Ruby: A great language for shell scripts
#222Earlier quoted context omitted.
They have inherited the second biggest mistake of shellscripts; Requiring the user to manually check $? after each command. No thanks. Anything that doesn't have error handling enabled by default goes straight in the trash bin.
How is it supposed to know how you want your errors handled by default? Handling errors is the programmer's job.
There are lots of techniques to make it obvious that errors can happen and need to be handled.
1. Make it difficult to ignore that a function can return an error. This is the golang approach. Errors are part of the return values and unused return values are compiler errors.
2. Make it impossible to use parts of the return value having an error state. Rust does this with the Result sum type and pattern matching.
3. Tailor for the happy-path and throw exceptions in case there are any errors. With optional means to catch them if recovering errors is desired. This is how most other languages function.
Hiding the error status in another variable, that is super easy to overlook and that the programmer might not even know exists, then continuing despite this variable not being checked will inevitably introduce bugs allowing faulty data in your system.
Re: Ruby: A great language for shell scripts
#223Earlier quoted context omitted.
100ms !!!! wtf? :) [borg@cube] time ruby -e 'nil' real 0m0.007s
Whoa, interesting... What version are you running? Here's my system: $ ruby -v ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] $ time ruby -e '' real 0m0.122s user 0m0.102s sys 0m0.020s I found an old Reddit thread also hinting at bad start-up times: https://old.reddit.com/r/ruby/comments/aqxepw/rubys_startup_... .
Very old one :) Because its reliable. Version 1.8.7 here.
I want controllable delays. I want controllable threads :) I want portability.
Of course, if you need more peformance, you need to go for newer stuff.
Re: Ruby: A great language for shell scripts
#224Earlier 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…
Your first two points don’t seem valid, in my experience. The Ruby 2.0 migration wasn’t that interesting from a compatibility perspective; it certainly wasn’t anything like Python 2 -> 3. And Ruby is __not__ slow compared to bash. I don’t where these myths get started, but someone needs to justify the Ruby-is-slow thing with actual data.
> I don’t where these myths get started, but someone needs to justify the Ruby-is-slow thing with actual data.
As an outside observer of the Ruby world, I have an impression that it was Ruby MRI that was slow. CPU-bound synthetic benchmarks like the much-criticized Benchmarks Game showed Ruby ≤ 1.8 a good deal slower than CPython 2. Here is an illustrative comment from that time: https://news.ycombinator.com/item?id=253310. People also complained about early Rails, and the perception of Ruby's performance got mixed up with that of Rails.
Then YARV came out, and Ruby became several times faster than its MRI former self on different benchmarks (https://en.wikipedia.org/wiki/YARV#Performance). With YARV, Ruby gradually caught up to "fast" interpreted languages. Now interpreted Ruby seems as fast as CPython 3 or faster in synthetic benchmarks (for example, https://github.com/kostya/benchmarks/blob/7bf440499e2b1e81fb...), though still behind the fastest mainstream interpreters like Lua's. Ruby is even faster with YJIT.
Re: Ruby: A great language for shell scripts
#225No pipe (and I mean in parallel too) no love for me. Nice calling syntax though.
You can pipe with the `pipeline*` method of open3 which is part of the stdlib: For example: require "open3" last_stdout, wait_threads = Open3.pipeline_r("cat /etc/passwd", ["grep", "root"]) last_stdout.read # => "root:x:0:0::/root:/bin/bash\n" wait_threads.map(&:value).map(&:success?) # => [true, true] https://ruby-doc.org/3.2.2/stdlibs/open3/Open3.html
Can you easily chain these, though? (gzcat some.txt|grep foo|sort -u|head -10 etc?). Especially lazily, if the uncompressed stream is of modest size, like a couple of gigabytes?
Re: Ruby: A great language for shell scripts
#226My first application of Ruby was to use it for shell auto-completions. I'm so grateful that I learnt Ruby first, and then Rails. Ruby is a great language to get some utility working out real fast. Rails is great for MVP. I fail to understand why people bitch about Ruby/Rails by comparing them to other languages/frameworks.
[deleted]
Re: Ruby: A great language for shell scripts
#227[dead]
Re: Ruby: A great language for shell scripts
#228To simulate “types” in complex shell scripting I typically involve a lot of json objects acting as my data structures and the file system for a rudimentary database. They’re horrifying ugly, but they tend to work pretty reliably. This is probably easier.
The `ip` network utility now supports JSON ouput via the `ip --json` invocation since a while back. I would love to see more tools implementing this as an option!
Re: Ruby: A great language for shell scripts
#229Cool, I'm sold, added Ruby to my to learn list! I use Python a lot but I don't think it's as good for writing scripts as bash or Perl. Ruby looks like it fits that "better but not much harder" category much better.
Re: Ruby: A great language for shell scripts
#230Ruby's a great language- I've always enjoyed its ergonomics and clarity. But its editor tooling hasn't kept up with its one-time competitor, Python. I've mostly been in the Python ecosystem for the past few years and the LSP investment from Microsoft has really shown. Rich Python support in VSCode is seamless and simple. Coming back to Ruby after that caught me off guard - it feels like I'm writing syntax-highlighted…
Funny, I have the complete opposite experience with python. Constantly turned off inline errors and warnings because they were almost always wrong - packages I installed “could not be found” by the LSP, it constantly worried about type issues that were no longer incorrect, it didn’t pick up function changes across files, etc etc. Then you think “maybe I just have the wrong lsp” only to realize there are half a dozen…
Hmm... I use python-lsp-server and it just works almost every time. The main thing is your editor being aware of your venv. Which editor do you use? I use direnv and the direnv support in Emacs so each project has its own venv, then install the project plus all dev dependencies (like type stubs) in that venv. The LSP server itself is installed globally, though.