Is it interesting? I think the whole debate of "Ractor versus Fiber" originates from the prior problem of ruby trying to overcome the GIL. Ractor is a more extensive solution here rather than Fibers.
What shopify does or does not do, IMO, should not be of any concern. I'd rather like to have a ruby variant where shopify does not pull any strings. I think your assessment is incorrect here, though. There is not really a "Ractor versus Fiber". To me it is more a question of namespaces versus Ractor, since that has indirectly to do with per-process isolation (Ractor is kind of the attempt to do that for all of the thread/GIL, but personally I think Ractors should not even exist in the first place at all, since to me that is just a work around, even if that description is also not completely correct either; I also don't think Fibers should exist, everything should go back to threads+processes only. No need to make ruby any more complicated than it already is, when it comes to multiprocessors).
It is interesting not in terms of its technical capabilities or merit ( or lack of ), but what Rails will default into. Apart from Minitest, defaults in rails tends to have a large impact on its ecosystem. ( Not that I like it either, but in most cases that is the. Way it is )
I am sorry but this is really a problem in the ruby world. Everyone sees how much ruby is struggling right now, yet key problems, such as documentation, are not a focus. Look at rack, ruby-wasm, ruby-opal and many other projects. Too many ruby developers hate documentation. There are a few exceptions (Jeremy Evans projects typically have a strong focus on documentation, for instance), but by and large I don't understand why documentation is always an afterthought of most projects.
Debatable. I always found languages without parentheses inscrutable. To distinguish methods you have to have all method signatures memorized or rely on an advanced IDE with highlighting.
> inscrutable. To distinguish methods you have to have all method signatures memorized or rely on an advanced IDE with highlighting.
I'm confident that you're either an outlier or have simply come across a terribly written or badly formatted Ruby codebase - considering Ruby (and Rails which followed the same principles) was created with the purpose of being highly readable (made for humans [1]).
What is advanced IDE highlighting? Do you mean.. colours? And memorising methods - huh?
Right. And that's the issue. I want to read at a glance, without having to ask tools. Monkey patching and lack of parentheses means dropping into a new codebase is like wading into a ocean of possibilities with every file.
The community does generally document monkey patching and meta programming constructs. All other code tends to be self documenting. That’s all I am saying.
Perhaps I just didn't write enough Ruby. It all felt very hard to grok for the time I spent with it. Whereas other languages, even quite obscure ones, felt more parsable to me.
People love taking generic engineering problems and somehow spinning them as Ruby specific issues. None of the issues you mentioned have anything to do with Ruby. They’re problems you can run into in any engineering project.
I've such fond memories of Ruby. Just moved to Kotlin since and it feels like a Ruby-with-types-and-Java-interop. Both Ruby and Kotlin are OO-first but FP-ready. Both are very expressive.
Interesting enough the JVM is so much further ahead that my HTTP-server is implemented "in JVM" (the built in "Sun" HTTP server is good enough for production use in our case). Where as in Ruby land there was (and is) always a native HTTP-server in the dependencies of a production app.
22 comments
[ 0.20 ms ] story [ 26.8 ms ] threadWhat shopify does or does not do, IMO, should not be of any concern. I'd rather like to have a ruby variant where shopify does not pull any strings. I think your assessment is incorrect here, though. There is not really a "Ractor versus Fiber". To me it is more a question of namespaces versus Ractor, since that has indirectly to do with per-process isolation (Ractor is kind of the attempt to do that for all of the thread/GIL, but personally I think Ractors should not even exist in the first place at all, since to me that is just a work around, even if that description is also not completely correct either; I also don't think Fibers should exist, everything should go back to threads+processes only. No need to make ruby any more complicated than it already is, when it comes to multiprocessors).
Where is the documentation?
I am sorry but this is really a problem in the ruby world. Everyone sees how much ruby is struggling right now, yet key problems, such as documentation, are not a focus. Look at rack, ruby-wasm, ruby-opal and many other projects. Too many ruby developers hate documentation. There are a few exceptions (Jeremy Evans projects typically have a strong focus on documentation, for instance), but by and large I don't understand why documentation is always an afterthought of most projects.
I'm confident that you're either an outlier or have simply come across a terribly written or badly formatted Ruby codebase - considering Ruby (and Rails which followed the same principles) was created with the purpose of being highly readable (made for humans [1]).
What is advanced IDE highlighting? Do you mean.. colours? And memorising methods - huh?
I really struggle to see how you can't tell which lines here are methods - https://gist.github.com/davidlares/5d136fa54572ad98e711e3684...
[1] https://news.ycombinator.com/item?id=22090358
Interesting enough the JVM is so much further ahead that my HTTP-server is implemented "in JVM" (the built in "Sun" HTTP server is good enough for production use in our case). Where as in Ruby land there was (and is) always a native HTTP-server in the dependencies of a production app.