Given Ruby culture of monkey patching, not always.
Besides, many people dev Ruby with a lightweight text editor, like text mate, that can't introspect code.
Besides, many people dev Ruby with a lightweight text editor, like text mate, that can't introspect code.
I haven't seen more than a handful of PRs with monkey-patching in the last decade and even then they are accompanied by long-winded explanations/apologies and plans for removal ASAP (eg monkey-patching an up streamed fix that hasn't been released yet).
Also, ruby classes/methods can tell you all about themselves, so if you haven't got ruby-lsp up and running (and even if you do) you can always open a repl (on its own, in the server process, or in a test process) and ask the interpreter about your method. It's pretty great!
It's definitely the case that the editor's ability to understand code via static analysis is limited compared to other languages, but it's not like we ruby devs are navigating in the dark.
If not, then we should be able to use the type annotations that are being added to also indicate async-ness.
If people decide to code Ruby "blind" (without a smart IDE), then that's their choice. There's no reason why someone using an IDE should have to pay for their decisions. We don't force people to manually and redundantly add names and types of parameters to call sites - it makes equally little sense to do the same for async. If someone decides to use a dumb IDE, then they can read the docs, exactly the same as they do for function parameters.