Hacker News Reader

Comment by atomicnumber3 | Hacker News Reader

I'm glad to see they're picking up native type-hinting. I don't like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it's official.

The concurrency stuff is cool but I can't really comment on it, my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there.

I really wish ruby had won over python as the "general purpose scripting language", I like it better. For example, I wish all the "big data" tooling was written in Ruby. But python is just the lingua franca. PySpark, Pandas, Airflow, etc are all python. I'm not really going anywhere with this, just lamenting I don't get to do more Ruby in my day job. I recently switched to writing python at home just because my productivity is so much better because I've memorized the standard library better from using it for years at work.

View on HN

I worked with both Python and Ruby daily for several years, both quite a few years ago and now just write the occasional scripts in those languages (small scripts, maintenance of older projects, patches for various projects when needed, etc.)

I much prefer Python for this. As an occasional Python/Ruby programmer I find it's just so much easier to work with. Ruby has a lot of features, which is part of its appeal, but that also means a lot of remember and ... a lot to forget. If you're not steeped in it, then that makes things quite a bit harder.

I programmed some Ruby a few weeks ago; it had been quite a while since I last did any Ruby, and ended up having to look up the syntax for blocks. This is really basic stuff, but I had written str.gsub!('pat', {|m| ... }), and the correct syntax is of course str.sub!('pat') { |m| ... }. Kinda silly I guess and a bit of a "oh, du'h" moment; I spent two years with Ruby as my day job, but that was also five years ago, and I think these kind of mistakes aren't that unusual if you're not programming Ruby too often.

And then there are caveats like using "return" where you should have used "next", and quite a few other things.

Don't get me wrong, I like Ruby, and there's also a bunch of things I don't like about Python. But I can definitely understand why people settled on Python. I think Matz once said "Ruby is 80% Perl and 20% Python"; I feel that with a slightly lower Perl-to-Python-ratio Ruby would have been better.

---

There may also have been implementation considerations by the way. I believe that historically at least, Ruby has been a lot slower than Python, although I think the differences today aren't very large. And a lot of these tools are written as native extensions, which Python seems to support a bit better.

> But I can definitely understand why people settled on Python

I think people settled on python because for a spell it was really hard to install ruby (1.6-1.8), it got worse around 2.0, (by the time python also ran into these issues, it had way more momentum) and:

- schools (high schools, colleges) were teaching python, because "it forced students into code indentation discipline"

- linux distros shipped with python because core features were being written in python

After five years without programming in a language, one will inevitably forget syntax and/or concepts, that's not something specific to Ruby - there isn't a presence of "sharp corners" more than any other language.

Actually, Ruby's selling point, during the golden times (I guess it was around the mid-2000s), was actually the simplicity and human friendliness of it.

I guess (but it's hard to prove anything in this sense) that Python came out earlier as human-friendly scripting language (1991 vs. 1995), and Ruby didn't provide any killer feature - until Rails came out, but that caused Ruby to "be" Rails, while Python had other areas of application, for example operating system tools.

To be clear, it's not that I didn't write any Ruby for 5 years: I just didn't write a lot of it.

And yes, I've also forgotten plenty about Python; but in Ruby there's just so much more to forget. I've retained much more of my Python knowledge.

> I wish all the "big data" tooling was written in Ruby.

On a practical note, Ruby's heavy use of reflection, inheritance and method_missing style dispatch currently makes performance for big data tasks less than ideal. Python is less expressive but its "one true way" makes things like vectorization and type specialization easier for data tasks.

Sometimes you really just need a better Fortran.

I believe you’re confusing Ruby with Rails.

While these can eventually come in handy sometimes, they are by and large seldom used, but Rails heavily leverages such patterns for flashy yet ultimately questionable magic.

As a long time Rubyist, I believe Rails, for all its innovation, has been warping the view of what Ruby is, and when and how to use its features responsibly.

I concur.

The dynamic inheritance part of Ruby is still core even in a non-Rails ecosystem. That does make optimizing performance more difficult.

But on a much simpler level, a lot of Pythonic data code is just functions + values, without them being complected in an object. That makes a lot of stuff like wrapping numerical libraries in C very easy in Python. I think you'd still have a bit of a culture shock writing procedural, return-by-value code in Ruby. That's pretty normal in Python and I think one of the (many) reasons it got picked up by STEM disciplines in academia. Looks over shoulder at awful code in Numerical Recipes in Fortran book.

Different strokes for different folks and all that, I just think there are probably constraints (and cultural values) that Python has that make it more suited to data problems than Ruby.

I'm inclined to agree.

One of Python's strengths in this space is that it's a procedural language with just enough in the way of object-oriented facilities. That makes it possible to write reasonably object-oriented libraries with easy-to-learn interfaces, while still sticking to procedural idioms for the actual data hacking.

Which, in turn, means makes it a comfortable environment and interfacing mechanism for both engineers and analysts.

That said, sometimes I look at tools like https://moosetechnology.org and desperately wish I could be using something like that at work.

Totally.

Another thing is that outside of scientific data applications, ordinary data processing apps at scale have been map-reduce for a long time. That's an inherently functional paradigm that's closer to Python.

Having parallelized heavily OO Ruby code across machines by unrolling it into functions that could be sent data payloads... that's not a fun thing to sell in an OO culture. In Python you're kind of already writing code that way, so increasing performance by splitting the data onto different machines is simple.

I don't think that would really be too bad, TBH. Don't forget that the first project to popularize distributed map-reduce, Hadoop, was a Java project.

All you really have to do to translate map and reduce into an OO paradigm is have the map and reduce operations take objects that implement specific interfaces instead of functions that have a certain signature.

> Don't forget that the first project to popularize distributed map-reduce, Hadoop, was a Java project.

Yeah, but that required everybody learning a different style of programming that wasn't OO ;-).

The problem is for "map", you have to get rid of shared state and the interleaving of state and time. Interleaving state and time is basically the only thing objects do beyond providing a namespace and polymorphism. There's also an inherent 1-ary behavior in most OO code. If you've got a complicated object graph, making something a bulk N-ary operation is non-trivial. A lot of ORMs have this problem when trying to optimize queries. When you're passing a vector of "state" to a function, it's much easier to make things bulk. (Anyone who's had to make legacy code provide a bulk API with an efficient DB insert operation knows what I'm talking about).

What you usually get in Ruby is a bunch of code that's like Duck.quack() and a complex set of things below that interface. What you need for data processing is something like quack(ducks[]). The way of parallelizing real-deal objects keeping them objects is with actors, and then you need to worry about distributed state a lot more.

Anyhoo, that's a long way of saying that the much-derided procedural or functional style of Python avoids this problem from the get-go. You can just slap the "map" step onto a stream processing system without cutting your graph into pieces that don't share state.

Smalltalk collections have map reduce, and it is as OOP as it gets.

Parallelize smalltalk collections across multiple machines without a distributed coordinator (reduce). Even the pedantic original version of smalltalk OOP has this problem.

map-reduce and functions do not require coordination until reduction. map doesn't require a serialized mailbox (like actors), or worrying about ordering in time. Smalltalk requires a consistent state and the location of where to send messages is important. Distributed map is stateless. All versions of OOP concern themselves with state encapsulation, whereas map is state elimination. map is functional.

Smalltalk map reduce works across VM processes, there is nothing in CS literature that requires map reduce to be a cluster only algorithm.

Functional paradigm closer to Python? I think you mean procedural as Guido has openly professed his distaste for all things functional to which Python's crippled lambdas bear witness. Ruby, on the other hand, with its procs, blocks and lambdas, supports an elegant functional style even if it is implemented in OO.

All of which go back to Smalltalk blocks and collections.

As for Python, Guido might not like it, but Python has enough features to do FP, in spite of crippled lambdas.

So I'm using a simple, deliberately not correct version of "functional" because a lot of people don't know the difference.

I don't like it when people break out their monocle and pipe and complain about this or that being true functional :-). I really do just mean "procedural functions + return by value instead of mutation" here.

It is completely normal to have a python script that is just ordinary functions, without state being enclosed in a class and accessed via `self`. This "My First Program" behavior scales extremely well, both from a parallelism perspective, as well from a complexity perspective. OO features can be applied iteratively on top of that.

With Ruby--syntax aside--it is just very rare to see people only write functions or private_class_methods. The "Everything is a Class" mantra is very strong, and there's lots of rich behavior in Ruby attached onto what would be considered primitives or basic structs in Python.

With data science specifically, this natural way of pushing simple procedures, primitives, structs from Python down into C has lots of performance benefits. Because those functions are "flat", you don't have to traverse the call stack routinely and lose performance there.

Just enough?

Python has the full program with multiple inheritance, metaclasses, abstract classes, slots, attributes, properties and decorators.

One can go wizard level with Python's OOP facilities.

I don't think that's been true for quite a while. Even a function like len('abc') is implemented as 'abc'.__len()__ under the hood so no different from Ruby really.

Well, the problem is that Rails (and ActiveSupport) is borderline idiomatic Ruby. I imagine the vast majority of Ruby codebases use them. And honestly I don't even know how vanilla Ruby stacks up to Python, it's almost an inconceivable idea (though I left Ruby behind some years ago.)

Rails is dominating Ruby less and less every year. There are plenty of alternative web frameworks to use, and Rails is a really heavy-weight thing to include if you're not building a website. I'll pull in an ActiveSupport module every once in awhile but so few of the things I write are websites that need Rails.

There's no evidence for this in the job market. Most Ruby jobs are Rails jobs.

> While these can eventually come in handy sometimes, they are by and large seldom used

I don't think they are seldom used in practice - I think large parts of the Ruby ecosystem use them pervasively, even if you disregard Rails.

But even if we don't agree on that - it's missing the point. The point is you pay for much of Ruby's metaprogramming, even if you aren't using it. So not using it doesn't help you.

A concrete example is that you pay for `Kernel#binding` every single time you finish using a local variable but Ruby retains it for the binding, even if you never ever call `Kernel#binding`. Even JITs cannot remove this cost.

> The point is you pay for much of Ruby's metaprogramming, even if you aren't using it.

I don't think there has been any meaningful attempt at assessing the performance of Python vs Ruby.

If we consider the benchmarks game, their performance is comparable.

I assume that PyPy is faster, but whether to consider it representative of Python's general performance is arguable.

Which cost do you mean? Needing to keep the value alive for deoptimization if Kernel#binding is actually called or?

Python isn't less expressive for the most part except for lack of blocks(although can be emulated with decorators and def _), and ruby's strategic lack of parentheses and not being to add/change methods in c based classes.

Python has just as much access to reflection, it has more powerful and arguably easier to shoot yourself in the foot inheritance (python has multiple inheritance while ruby only has mixins). Python also has method_missing in __getattr__. Arguably python tends to use these less often then ruby but I've definitely used both reflection and __getattr__. I've also once had to debug a really hairy multiple inheritance issue(in a test framework that used base classes to test different hardware features where you might want to have both you'd need to use multiple inheritance and then make sure they were initialized in the right order, multiple inheritance can get really annoying)

> On a practical note, Ruby's heavy use of reflection, inheritance and method_missing style dispatch currently makes performance for big data tasks less than ideal. Python is less expressive but its "one true way" makes things like vectorization and type specialization easier for data tasks.

FWIW the things you mention are available in Python. There are things Python doesn't have like singleton objects but I'd say those are syntactic sugar & conveniences (not unlike classes existing from the start of the `class` statement) rather than a lower level of expressivity.

Python absolutely does have extensive reflection, inheritance, and "method_missing-style dispatch" (cf `__getattribute__` and `__getattr__`), and so has to accommodate the possibility of them being used… unless it doesn't want to which specialised Ruby implementations (à la numba and friends) could certainly do as well.

I've found Ruby to be far more "learnable", in that once I learn how something works in Ruby, it will work that way in most every situation going forward, whereas Python has a lot of caveats to its functionality. This might just be due to my use cases, but the Ruby documentation is 100x more useful for getting me from point A to point B than anything I've seen from Python's docs.

I still use Python daily, since its so ubiquitous, I just find myself having a difficult time using it for anything remotely complicated without a lot of extra research.

> my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there.

I could see reasons for preferring Java over Ruby but concurrency isn't one of them considering that Concurrent-Ruby running on JRuby gives you access to all of Java's concurrency tooling.[1]

1. https://github.com/ruby-concurrency/concurrent-ruby

you can still go with jruby and have best of both worlds.

Or bake it into a task graph and use the gmake executor.

I've tried on a project, but incompatibility with some libraries (gems) made it impossible. I guess it's very much like PyPy.

I think parallelism is just not part of the Ruby ecosystem anyway, at least in the present (possibly in the future, who knows).

Rails released officially support for multithreading long ago, but it was broken. And there is a Ruby global lock, anyway (3.0 will have true parallelism, although in alpha).

Well the parallelism issues doesn't exist in the jruby world, but yes, gems with C extensions normally don't work out of the box with jruby, but in another hand you can call java straight from ruby. That's so powerful and often better than the gems - if you know how to right ruby and wrap the java classes with ruby! So as many times said along this thread, ruby isn't rails. I have a project running in a government agency with jruby. It was a port of an old Java SWT application and we rewrote it in jrubyFX. The project was such a pleasure!

It is a pity the type hinting is done in a separate file though, as it leads to a lot of duplication. In this case, I pretty much prefer Python’s approach.

You can still use the inline type hinting from Sorbet. Sorbet is compatible with RBS and you'll probably want to check types via Sorbet anyway.

FWIW Python does also support type hinting in separate files, although the use case is mostly in adding annotations to existing code bases.

> "if you're going to even think about threads, just use Java or go" since concurrency is so nice there.

Concurrency in Java is not very great although there are some improvements in these years. The actor model (Ruby 3 / Erlang) is on par with CSP model (Go) though they have different trade-off and scenarios.

I'm really really glad it didn't. Once you get into looking at advanced ruby with all the implicit eccentricities it starts looking a whole lot like the Perl of old.

Ruby should be one VM per CPU with message passing like I did for the Blue Gene/L port. Threading can't scale between cgroups let alone kernels.

It's a mish-mash language like perl and should die the same death.

Ruby might have some qualities but overall it's less polished than python

Just as a small example, Edit: .methods, "the Ruby equivalent of 'dir'" doesn't present the results as a sorted list

Also the optionality of parentheses sounds like a good idea but it actually makes things more confusing and less parseable

I would argue that is a good thing since it allows for performant access when you do not care about order. If you do not care about order you do usually not even have to allocate an array which means lower memory use. And how hard is it to write.

    Dir[path].sort

Ruby lacks polish in certain areas but this is not one. A d I would argue Python can be pretty tough in places too.

Not that Dir, I mean as in .methods/.instance_methods (or dir(instance) in python )

I fixed it in my original comment

Then I understand your complaint even less. I almost never sort the output from methods and I do not think I have ever sorted the output from instance_methods during my over 10 years as a Ruby developer.

Python orders it. And when you want to look up a method by name you do a binary search by fact of being a sorted list

Anyway you can just .sort

> .methods, "the Ruby equivalent of 'dir'" doesn't present the results as a sorted list

This seems like an odd complaint: Both languages use hash maps to look up methods/attributes, which aren't inherently sorted. Looking at the implementation `dir` in python does an explicit sort, which just seems like arbitrary behaviour.

It's not an arbitrary behaviour if you want a well behaved result from it. Same with Python dictionary keys which used to have no intrinsic ordering.

Especially when dir() is more used in interactive applications (and sure, sometimes programatically like in plugin architectures, etc)

Because Ruby uses fairly deep metaprogramming much more, idiomatically, than does Python, while “dir() is more used in interactive applications” may be true, that does not imply that “#methods is more used in interactive applications”. And, anyhow, an interactive application that wants the information it asks for will quite often wan’t to impose an organization other than alphabetic ordering.

Reply on news.ycombinator.com