Fun fact, Ruby as a single-threaded language is probably the only way how most people experience it, but...
Ruby has a rich cooperative multitasking called Fibers that hopefully is getting more exposure, in amongst a bevy of competing implementations and other also-ran concurrency primitives (besides the usual contenders like Threads, Process fork, foreman that just runs several processes alongside one another...)
If you want to use debugging and multi-threaded or multi-fiber Ruby at once, you can! You just have to get a bit creative. I always refer back to this thread on the Ruby `debug` gem (though the advice applies to any other REPL you can use) about applying a Mutex. You can use the built-in Fiber.blocking to prevent other fibers from running at the same time as yours, or you can use a Mutex to just ensure that you don't hit the debugger multiple times in the same process IO that would mean you've got multiple REPLs all grappling for the StdIO at once (but that other fibers can proceed, in case you were trying to debug something - you know - actually concurrent - and you really don't want for the world to stop and wait on your debugger!)
For a long time Ruby dev who almost never did concurrency unless it was facilitated by the OS, or before being exposed to it directly in other languages like Go, the Ruby "super power" remains intact, it's just a bit more mysterious with the concurrency stuff added. Ruby has amazing diversity in its concurrency tools, which is a nice way of saying "the language authors decided not to pick a king concurrent runtime/winning gem whilst all of the competing implementations were all a bit nascent and un-fully-formed!"
I like the bruno/fiber-scheduler but it looks like it is not the winner. It should be easy to switch to another fibers implementation, I think async is the crown champion now, but I still haven't been motivated to switch - the fiber-scheduler that is named fiber-scheduler has been good enough for me, despite shortcomings!
Ruby was my first language, I was sorely disappointed when I realized this "super power" wasn't the norm in most languages. ahh to be a junior developer again. :)
Doing the same with pry ALL THE TIME. It basically became my standard programming workflow. Especially you can also do `ls` to inspect objects and classes.
Is there any other language which can do that? And I don’t mean unergonomic debuggers.
Another wonderful helper in Pry is `show-method`. If you type in `show-method Foo.bar`, it will pull up the source code for that method, or class, or whatever you pass to it. Great for looking something up when you don't understand what's going on behind the scenes, especially since it works on code from gems as well.
I’ve been there too, just don’t forget to remove it! Also would never tell anyone else to do this, unless I trust them not to come to me about “everything getting all weird”
Another pro-tip in this vein is `object.methods` to see a list of the methods to which the object you're messing with will respond. I use this all of the time when I'm diving into something trying to figure out what's going on.
While this was true for a long time, Ruby's built in irb and debug gems have improved dramatically in the past couple of years. To the point that I've switched to them from pry+byebug that I've been using for years.
One advantage of byebug is that if you do a sleep in something with theeads like capybara tests, the browser becomes functional again. Which is not the case with irb/debug. I couldn't find a way to reproduce this behavior in recent debuggers.
pretty new to this but I thought that irb was a dependency of rails, so when they say "not a gem," it's still a dependency somewhere...
using `binding.b` via the `debug` gem appears to be the path that most of the industry is going since I think it has 100% of these capabilities and more. I might be wrong. Curious what others think
Ruby has a rich cooperative multitasking called Fibers that hopefully is getting more exposure, in amongst a bevy of competing implementations and other also-ran concurrency primitives (besides the usual contenders like Threads, Process fork, foreman that just runs several processes alongside one another...)
https://github.com/ruby/debug/issues/486#issuecomment-157531...
If you want to use debugging and multi-threaded or multi-fiber Ruby at once, you can! You just have to get a bit creative. I always refer back to this thread on the Ruby `debug` gem (though the advice applies to any other REPL you can use) about applying a Mutex. You can use the built-in Fiber.blocking to prevent other fibers from running at the same time as yours, or you can use a Mutex to just ensure that you don't hit the debugger multiple times in the same process IO that would mean you've got multiple REPLs all grappling for the StdIO at once (but that other fibers can proceed, in case you were trying to debug something - you know - actually concurrent - and you really don't want for the world to stop and wait on your debugger!)
For a long time Ruby dev who almost never did concurrency unless it was facilitated by the OS, or before being exposed to it directly in other languages like Go, the Ruby "super power" remains intact, it's just a bit more mysterious with the concurrency stuff added. Ruby has amazing diversity in its concurrency tools, which is a nice way of saying "the language authors decided not to pick a king concurrent runtime/winning gem whilst all of the competing implementations were all a bit nascent and un-fully-formed!"
I like the bruno/fiber-scheduler but it looks like it is not the winner. It should be easy to switch to another fibers implementation, I think async is the crown champion now, but I still haven't been motivated to switch - the fiber-scheduler that is named fiber-scheduler has been good enough for me, despite shortcomings!