Hacker News Reader

Comment by rednafi | Hacker News Reader

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!

View on HN

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

Thanks for the nudge:

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

Haha, thanks! This is why I love HN.

> Ruby is slow and encourages an esoteric convention over configuration style of OO code.

I think you are commenting on Rails, not Ruby when you refer to "convention over configuration". Even in Rails I'm not sure what "esoteric" means in your comment and that approach isn't even related to the object-oriented concepts.

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

Go is a good language for when I want binaries an order of magnitude larger than necessary.

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.

> Ruby is slow

We're talking about code that calls external commands here. If one wants performance it is already doing wrong by calling external commands. Don't think it is relevant here.

> encourages an esoteric convention over configuration style of OO code.

I can't see that. Its OO is not so different from other languages. Perhaps you are thinking about Rails (as I said in the first paragraph).

Perl is basically available everywhere git is installed, too. Way lower startup time than ruby.

Reply on news.ycombinator.com