3 ms·

I seriously doubt people writing web software are planning for intentional races in their system designs the way an OS dev does to avoid synchronization overhea

I seriously doubt people writing web software are planning for intentional races in their system designs the way an OS dev does to avoid synchronization overhead.

kube-system 6y ago
I don't await promises if I don't need to. Don't think that's a super unusual pattern.
- rileymat2 6y ago
  I feel a bit ignorant, although you don't need to await on assignment, don't you need to await to "unwrap" it when needed?
  - thecopy 6y ago
    Sometimes you dont need the result.
    - rileymat2 6y ago
      Right, if you don't need it, you don't need to unwrap it.
      - IggleSniggle 6y ago
        As the article is making a round-about way of pointing out, you might need to "block" (unwrap) due to a side-effect in order to make the sequencing correct for downstream logic that touches the same thing. Shouldn't be necessary if things are coded appropriately in the first place, and maybe better to just refactor, but...
  - hexsprite 6y ago
    It’s just a function that returns a promise object. The await keyword triggers the wait and unwrap functionality, but in cases where you don’t care you can just call it as a regular function
- aaomidi 6y ago
  You should however, catch it. If you're doing nothing with a promise (awaiting, or catching), then you have bad code. You can read more about that here: https://palantir.github.io/tslint/rules/no-floating-promises/ https://palantir.github.io/tslint/rules/no-floating-promises...
  - chrisseaton 6y ago
    That guide says that you should do this because it can cause race conditions: > This can cause unexpected and/or non-deterministic behavior depending on external timing factors. But, as this whole thread is about, sometimes you don't mind race conditions. So it can ok to acknowledge but ignore this advice if you are aware of how this race conditions matters to your codebase. Learn the rules, but know when to break them.

I seriously doubt people writing web software are planning for intentional races in their system designs the way an OS dev does to avoid synchronization overhead.

kube-system 6y ago

I don't await promises if I don't need to. Don't think that's a super unusual pattern.

rileymat2 6y ago
I feel a bit ignorant, although you don't need to await on assignment, don't you need to await to "unwrap" it when needed?
- thecopy 6y ago
  Sometimes you dont need the result.
  - rileymat2 6y ago
    Right, if you don't need it, you don't need to unwrap it.
    - IggleSniggle 6y ago
      As the article is making a round-about way of pointing out, you might need to "block" (unwrap) due to a side-effect in order to make the sequencing correct for downstream logic that touches the same thing. Shouldn't be necessary if things are coded appropriately in the first place, and maybe better to just refactor, but...
- hexsprite 6y ago
  It’s just a function that returns a promise object. The await keyword triggers the wait and unwrap functionality, but in cases where you don’t care you can just call it as a regular function
aaomidi 6y ago
You should however, catch it. If you're doing nothing with a promise (awaiting, or catching), then you have bad code. You can read more about that here: https://palantir.github.io/tslint/rules/no-floating-promises/ https://palantir.github.io/tslint/rules/no-floating-promises...
- chrisseaton 6y ago
  That guide says that you should do this because it can cause race conditions: > This can cause unexpected and/or non-deterministic behavior depending on external timing factors. But, as this whole thread is about, sometimes you don't mind race conditions. So it can ok to acknowledge but ignore this advice if you are aware of how this race conditions matters to your codebase. Learn the rules, but know when to break them.