5 ms·

I don't like colored function for obvious reasons, but fully colorless for async means you don't know when things are async or not. There are a lot of things I

I don't like colored function for obvious reasons, but fully colorless for async means you don't know when things are async or not. There are a lot of things I dislike in JS, but I think the I/O async model is just right from an ergonomics point of view. The event loop is implicit, any async function returns a promise, you can deal with promises from inside sync code without much trouble. It's just the right balance.

throw10920 2y ago
> fully colorless for async means you don't know when things are async or not The IDE can tell you.
- BiteCode_dev 2y ago
  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.
  - mp1mp2mp3 2y ago
    > ...culture of monkey patching... 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.
  - goatlover 2y ago
    Can't the text editor open a shell where you can run the repl to do the inspection?
  - throw10920 2y ago
    If you monkey patch, you get what you paid for - and an annotation at the call site or definition wouldn't help anyway! 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.
- lmm 2y ago
  > The IDE can tell you. The only way the IDE can tell you is if the language tells it, or it guesses - and if it guesses then it will get it wrong sometimes. Which things are async or not is exactly the kind of thing that needs to be part of the language definition, so that all tools will agree about it and you won't have functions that are async in one IDE and not another, or async in a profiler but not an IDE, or...
- wiseowise 2y ago
  I’m all ears how IDE will determine that function is blocking 20 layers deep into third party library I don’t even have source code of.

throw10920 2y ago

> fully colorless for async means you don't know when things are async or not The IDE can tell you.

BiteCode_dev 2y ago
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.
- mp1mp2mp3 2y ago
  > ...culture of monkey patching... 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.
- goatlover 2y ago
  Can't the text editor open a shell where you can run the repl to do the inspection?
- throw10920 2y ago
  If you monkey patch, you get what you paid for - and an annotation at the call site or definition wouldn't help anyway! 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.
lmm 2y ago
> The IDE can tell you. The only way the IDE can tell you is if the language tells it, or it guesses - and if it guesses then it will get it wrong sometimes. Which things are async or not is exactly the kind of thing that needs to be part of the language definition, so that all tools will agree about it and you won't have functions that are async in one IDE and not another, or async in a profiler but not an IDE, or...
wiseowise 2y ago
I’m all ears how IDE will determine that function is blocking 20 layers deep into third party library I don’t even have source code of.