Hacker News Reader

Comment by chrisseaton | Hacker News Reader

> A race condition is a type of programming error

I don't think a race condition is inherently an error. If you can design your program to accommodate races, including even data races, then allowing them and not spending time on protecting against them can be a useful performance optimisation.

It's only a bug if the race causes you to get into a state that you don't want.

View on HN

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.

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

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.

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?

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

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

Reply on news.ycombinator.com