Hacker News Reader

Comment by dimitrios1 | Hacker News Reader

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.

View on HN

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

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?

Sometimes you dont need the result.

Right, if you don't need it, you don't need to unwrap it.

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...

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

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...

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.

Reply on news.ycombinator.com