Live data from Hacker News

Ruby: A great language for shell scripts

lucasoshiro.github.io

341–350 of 368 posts

Re: Ruby: A great language for shell scripts

#341

Earlier quoted context omitted.

It's not quite what you're describing, but TruffleRuby is Ruby on GraalVM: https://github.com/oracle/truffleruby Unlike GraalVM Java, as far as I can tell TruffleRuby doesn't provide a bundler that can create a single executable out of everything, but in principle I don't see why it couldn't.

Worth noting that the GraalPython implementation does support creating a single binary. https://www.graalvm.org/latest/reference-manual/python/stand... I'm not sure I'd try replacing shell scripts with natively compiled Python binaries. That said, I use a Kotlin Scripting based bash replacement in my own work that has many useful features for shell scripting and is generally much more pleasant. You have to "install"…

I wasn't so much imagining each shell script being replaced with a binary, as I was imagining deploying a single static binary "sysadmin-DSL interpreter binary" — where that "interpreter" is just "Ruby with a custom prelude, all packed together" — such that I could then name that interpreter in the shebang line for my admin scripts written in that DSL.

Re: Ruby: A great language for shell scripts

#342
post #340

Earlier quoted context omitted.

Sure, especially every bash script that goes over 200-250 lines is super readable. /s Or when you have to start using all the combinations of characters to achieve f.ex. proper iteration through an array without word splitting. Etc. to infinity. I've danced this dance hundreds of times and got sick of it. Gradually moving away from scripts and to Golang programs and so far it has been an improvement in almost every w…

still more readable than disassembler output :) sure if it's your "script" and you know exactly the code corresponding to it it might be ok, but that's a lot of overhead for a disposable script.

Are you arguing against my point or for it? :D

Re: Ruby: A great language for shell scripts

#343

Earlier quoted context omitted.

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…

I work on a 12 year old Ruby project at my job, and while some of what you say is true, I still love working on it more than anything else.

> ...while some of what you say is true...

What parts of what I said is not true, and how?

Re: Ruby: A great language for shell scripts

#344
post #299

Earlier quoted context omitted.

This has been my experience too reading the Gitlab code. It's absolutely impossible to follow - you can't use static typing to follow flow because there isn't any, and you can't even grep for identifiers because half of them are dynamically generated. Every time I've wanted to understand something I've been unable to even find the relevant code. Contrast that with gitlab-runner (Go) or VSCode (Typescript) both of whi…

Years ago, this was almost exactly my experience at my first software job, a large Rails monolith in the Ruby-on-Rails heyday. Obviously I was inexperienced, but aside from that, the application code itself was so hard to understand that I was seriously considering whether I was cut out for professional software development. It was just impossible to tell where things were defined, where data was coming from, when th…

> [A]side from that, the application code itself was so hard to understand that I was seriously considering whether I was cut out for professional software development. It was just impossible to tell where things were defined, where data was coming from, when things were actually executing, etc.

If the enormous pile of Ruby projects that I and the folks I work with at $DAYJOB had been the things I was required to work on and maintain at my first dayjob, I would have (no joke) left the field to go become a lawyer.

I'm so, so, so glad that I started off with C++ and got to work at a couple of C++ shops which got me to understand in my bones the importance of good tests and comprehensible-to-a-mere-mortal code.

> ...there absolutely is a difference between what the average Clojure programmer will write and what the average Java programmer will write.

Oh yeah, definitely. After being worn down by the many years I've burned at my current position, I've become VERY skeptical of the "Let's use $LANGUAGE_OR_TOOL because it will make it easy to hire!" argument. The quality of the stuff that the average user of that tool produces matters A TON.

Re: Ruby: A great language for shell scripts

#345

Earlier quoted context omitted.

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.

> Implicit library loading isn’t even the real problem, it’s the global namespace.

I'm not sure what you mean by this? Ruby gives you pretty much the same namespacing powers that most mainstream languages do.

If your argument is that noone should EVER be able to hoist something into the global namespace, then I'm going to have to pretty strenuously disagree with you. Power tools are good to have for when you need them... but it's very important to have the restraint to only use them when you need them and leave them on the shelf when you don't.

Re: Ruby: A great language for shell scripts

#346

Earlier quoted context omitted.

Oh but golang's "deployment story" is SO SIMPLE! /s

isn’t it though?

I was arguing with myself about adding additional context. It looks like I should have put it in.

In my professional experience, Go cannot consistently avoid producing binaries that fail when run on an incompatibly-different version of glibc than they were build and linked on.

Also. for most deployment situations, Go's "single, enormous binary" doesn't matter.

* In The Cloud(TM), you have full control over what you deploy. So, so, so often you have a custom VM or Docker image that you just squirt out there and automation to keep it updated and rebuilt, which makes deployment just trivial.

* On Windows, you have Windows Installer, which you can instruct to check for and install any prereqs you require. (It's incredible how all of the pieces to build a proper package manager have been in Windows since the early 2000s, and yet no package manager came out of MSFT.)

* On OSX, you either use the App Store or one of the handful of package managers... but I expect nearly zero non-Power-Users use the package managers. I guess there are also the nutballs who do 'curl $INSTALL_SCRIPT | sudo bash'.

* On Linux... well nearly zero non-Power-Users run desktop Linux, and those that do likely already have Ruby, Python, Perl, and GCC installed.

Re: Ruby: A great language for shell scripts

#347

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…

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'm not sure why people keep comparing to Python. Python is not replacing shell either.

Re: Ruby: A great language for shell scripts

#348
post #204

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…

Mentioning 1.9 migration and ruby being slow? Python 2 to 3 was waaaaay worse and more negatively impactful, and equally slow (slower in most cases). Ruby never had US market penetrative as perl or python, which were basically invented in the US, and congregated people from the academic realm. These things aren't decided based on meritocracy (no things ever are).

Compare Ruby to shell, not Python, when considering what I wrote above.

Re: Ruby: A great language for shell scripts

#349

Earlier quoted context omitted.

Ha - I actually haven't changed my opinion about verbosity, Python is still more verbose and I will choose Perl for throwaway scripts even today; I just have a greater appreciation of readability of Python code compared to the free-for-all style-fest of Perl code (admittedly written by a bunch of devs with little code style enforcement). Perl is great for smaller scripts but I'm talking about many thousands lines of…

Thousands of lines := time to use a real (compiled) language

Very true; unfortunately quite often one is not in the decision maker's seat.

Re: Ruby: A great language for shell scripts

#350

Earlier quoted context omitted.

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

> much-criticized

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

> showed Ruby ≤ 1.8 a good deal slower than CPython 2

It's taken me a couple of days to remember web.archive.org :(

CPython 2.5 vs ruby 1.8.6 (2007-03-13)

https://web.archive.org/web/20070219190706/http://shootout.a...

Post reply on HN