8 ms·

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 k

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.

abernard1 6y ago
> 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.
- lloeki 6y ago
  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.
  - abernard1 6y ago
    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.
    - mumblemumble 6y ago
      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 https://moosetechnology.org and desperately wish I could be using something like that at work.
      - abernard1 6y ago
        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.
        mumblemumble 6y ago
        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.
        abernard1 6y ago
        > 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.
  - lukeschlather 6y ago
    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.)
    - vinceguidry 6y 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.
      - cutler 6y ago
        There's no evidence for this in the job market. Most Ruby jobs are Rails jobs.
  - chrisseaton 6y ago
    > 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.
    - pizza234 6y ago
      > 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.
    - jashmatthews 6y ago
      Which cost do you mean? Needing to keep the value alive for deoptimization if Kernel#binding is actually called or?
- rat87 6y ago
  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)
- masklinn 6y ago
  > 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.
progressbwc 6y ago
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.
- Lio 6y ago
  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.
- nerdponx 6y ago
  FWIW Python does also support type hinting in separate files, although the use case is mostly in adding annotations to existing code bases.
arp242 6y ago
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.
- dnautics 6y ago
  > 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
- pizza234 6y ago
  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.
Lio 6y ago
> 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 https://github.com/ruby-concurrency/concurrent-ruby
- pelasaco 6y ago
  you can still go with jruby and have best of both worlds.
  - crb002 6y ago
    Or bake it into a task graph and use the gmake executor.
  - pizza234 6y ago
    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).
    - pelasaco 6y ago
      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!
raverbashing 6y ago
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
- jeltz 6y ago
  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.
  - raverbashing 6y ago
    Not that Dir, I mean as in .methods/.instance_methods (or dir(instance) in python ) I fixed it in my original comment
    - jeltz 6y ago
      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.
      - raverbashing 6y ago
        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
        fomine3 6y ago
        Anyway you can just .sort
AcerbicZero 6y ago
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.
crb002 6y ago
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.
PointyFluff 6y ago
It's a mish-mash language like perl and should die the same death.
stjohnswarts 6y ago
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.
namelosw 6y ago
> "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.

abernard1 6y ago

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

lloeki 6y ago
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.
- abernard1 6y ago
  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.
  - mumblemumble 6y ago
    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 https://moosetechnology.org and desperately wish I could be using something like that at work.
    - abernard1 6y ago
      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.
      - mumblemumble 6y ago
        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.
        abernard1 6y ago
        > 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.
- lukeschlather 6y ago
  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.)
  - vinceguidry 6y 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.
    - cutler 6y ago
      There's no evidence for this in the job market. Most Ruby jobs are Rails jobs.
- chrisseaton 6y ago
  > 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.
  - pizza234 6y ago
    > 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.
  - jashmatthews 6y ago
    Which cost do you mean? Needing to keep the value alive for deoptimization if Kernel#binding is actually called or?
rat87 6y ago
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)
masklinn 6y ago
> 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.

progressbwc 6y ago

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.

Lio 6y ago
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.
nerdponx 6y ago
FWIW Python does also support type hinting in separate files, although the use case is mostly in adding annotations to existing code bases.

arp242 6y ago

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.

dnautics 6y ago
> 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
pizza234 6y ago
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.

Lio 6y ago

> 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 https://github.com/ruby-concurrency/concurrent-ruby

pelasaco 6y ago
you can still go with jruby and have best of both worlds.
- crb002 6y ago
  Or bake it into a task graph and use the gmake executor.
- pizza234 6y ago
  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).
  - pelasaco 6y ago
    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!

raverbashing 6y ago

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

jeltz 6y ago
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.
- raverbashing 6y ago
  Not that Dir, I mean as in .methods/.instance_methods (or dir(instance) in python ) I fixed it in my original comment
  - jeltz 6y ago
    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.
    - raverbashing 6y ago
      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
      - fomine3 6y ago
        Anyway you can just .sort

AcerbicZero 6y ago

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.

crb002 6y ago

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.

PointyFluff 6y ago

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

stjohnswarts 6y ago

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.

namelosw 6y ago

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