[shuckforjustice]

Hey! I'm the writer of the article. I'm not a fantastic writer but am trying to improve and felt I needed to start somewhere, so I started with something I'm passionate about. Truth be told I do not know as much about Python as I do about Ruby, I think I was probably responding to its comparative popularity and not in fact if it is discussed about or not, so that's on me.

I'd like to know more about what you would have liked to see in an article like this, it is a bit of a fluff piece; the goal wasn't to provide a super technical explanation. The goal was to get people talking about Ruby 3 and I am happy to see so much discourse here! But yeah, I was asked by the maintainer of the blog to try to provide "layman's explanations" when I could, which I think may have kneecapped me a bit in retrospect - but obviously layman's explanations usually are best when they are succinct and accurate. Is there anything else, particularly in the layman's examples for parallelism and concurrency, that felt inaccurate or misleading? I want to make sure I am communicating the concepts and implications correctly.

From my perspective, the goal of the article is provide an explanation of concurrency/parallelism, so that when I begin to describe the features in Ruby 3.0 we have appropriate context to understand why fibers/ractors matter, so if I didn't do that I really bungled it!

[singhrac]

I saw you edited your post, which is great. Happy to chime in from the Python side: people complain a lot about the GIL but in practice a lot of the truly parallel logic happens in C extensions, which are lately quite easy to write. This is where all the heavy lifting for machine learning happens; the I/O parallelism that one might see in e.g. a scraper is a different kind of thing (e.g. fibers). I don't know much about ractors but it's neat to see a GIL being lifted!

Small nits: the image with fibonacci performance numbers needs a maximum number of significant digits. I think "implement" usually applies to an algorithm or idea; you might mean "use" Sidekiq? The thing I'm most curious about is how easy it is to write an extension in C/C++/Rust for Ruby (in comparison to cffi, pybind11, etc.).

Best of luck! It's not easy to write a technical article and face criticism, but I appreciated reading it.

[shuckforjustice]

Cool. Thanks for the feedback and the Python context!

[ComputerGuru]

Hey, so I would've taken a few more seconds to be less blunt if I thought the author was reading this - sorry about that. Also, you say you're "not a fantastic writer" but I think you're being way too hard on yourself: the writing was just fine and I had no problems with it; it was the teasing of technical content without followup that led to my comment.

That said, for me the issue was that the introduction read like "this is going to explain the technical reasons why Ruby 3 rocks" and each section/bit thereafter was ostensibly "technical reason x/y/z why this is better" but then no section really followed up to the promise of actually providing any hard technical details (this is aside from the inaccuracies about other languages).

So, for me at least, it was about expectations not matching the content. I'm not a Ruby dev, but I am a programming language internals fanboy and I was excited to get a technical peek into what a hard-core Ruby user was saying had changed but found myself really stymied/disappointed that it seemed like the same bullet points were being repeated but with no technical content getting delivered.

TBH, it's really hard to write for nerds like us. I'm sure if I'd organically discovered your post, perhaps while Googling something you wrote about or if shared from a Ruby devs' group, I think I'd have come away with a different conclusion from the article. But seeing it featured here on HN played a role in making me think it would have juicy technical content which kept being referenced but then kept just out of arm's reach.

Thanks for trying, though! Sorry for being grumpy.

[jrochkind1]

I think it's important when writing an article like this to stick to what you know about. If you aren't sure what is going on with the GIL in Python or v8 and whether it's discussed or how it's relevant, either research to learn more, or don't mention it. Instead of assuming things or implying assumed things, to make the article flow.

Articles I trust are where I trust the author knows what they're talking about and doesn't assume things they don't know.

[shuckforjustice]

Totally, I understand. I've since changed the language to not assume anything, simply stating that they exist, which is all I know. I was concerned that I was painting a picture of GIL being a Ruby concept, which isn't the case and is why I included it originally, but you're absolutely right. Thank you for the feedback, really appreciate it!

[Abishek_Muthian]

One of the questions we had for python developer interviews in my previous startup was regarding implementing parallel/concurrent tasks in Python and we expected the candidates to tell the limitations with GIL to do justice to the parallel/concurrent tasks.

Honestly anything to improve performance with large python applications seemed like a hack - gevent, Gunicorn, uvloop, switching libraries to cython etc. It delayed our product rollout and increased costs(incl. cloud infrastructure). Hence I switched to Go for anything where performance matters.

Good to know that Ruby3.0 has made some improvements regarding concurrency/parallelism.