121–130 of 133 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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
Earlier quoted context omitted.
From an implementation perspective this has much more in common with Go than either Python or Node. In Go, you simply write a blocking IO call, and the scheduler in the Go runtime pauses your current lightweight thread ("parks the go routine" in their terminology) until the IO operation has some results to read. While waiting, the runtime is free to run any other go routine(s) on any number of OS threads. What is com…
So the Ruby runtime has some kind of internal list of operations that are blocking, and can optionally be executed asynchronously when called from inside a fiber?
Could someone familiar with the Fiber/Async thing explain how does this differ from Python's (or Node's)? How come Python (and Node) needs explicit awaits but Ruby seems to "just work"?
Python Zen: Explicit is better than implicit There's a python library gevent which experimented with a more implicit design. Or more, this is about green threads vs async/await It can also be a bit confusing when you don't allow separating await from the call: how do you implement Promise.all? For official rationale see https://www.python.org/dev/peps/pep-0492/#why-async-and-awai...
Anecdotally, since I got away from Ruby, working on software became way more productive and tolerable. Maybe it was something with the corner of the Ruby world I fell into, but the syntax sugar options and “cleverness” that enabled was maddening to deal with, and permeated that crowd. Code bases with mixed styles are a thing in any language, but the Ruby-ists around me found a way to make one project look like half a…
I mention Rails specifically because I can't think of any other reason I'd use Ruby these days.
Earlier quoted context omitted.
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.
> 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 concret…
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 p…
> 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.
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.
Earlier quoted context omitted.
> Is the goal of Ruby right now to claw back all the people who moved to Elixir by adding Erlang features to Ruby? One has to wonder. I don't think I'll go back. I found that I was coding almost exclusively in a functional style, in Ruby (because it was easier code to test and it seemed to produce less bugs/fewer mental-model problems), then realized I was still missing out on the guarantees that Elixir gives you, th…
I see a lot of Elixir lovers but I just can't wrap my head around a lot of the idioms. Is it bad I much prefer loops to reduce? Also modelling complex domains things just flow better in my brain with OOP, whenever I go to draw things I put them in boxes with as little state as I can. I would love love love to see two people approach the same exact problem with OOP and FP and see the rewards of both. However I really…
Earlier quoted context omitted.
15% is a decent speedup.
When implementing a JIT I would hope for a much higher speed up than 15%. In comparison: LuaJIT with the JIT switched on runs about five times faster than the most recent PUC Lua interpreter, see http://software.rochus-keller.ch/are-we-fast-yet_lua_results... . Compared to that 15% is nothing.