What problem does it solve? Effect v4 collection combinators like Effect.all and Effect.forEach run sequentially by default, and developers often misuse concurrency options, racing semantics, or coordination primitives, leading to silent sequential bottlenecks, leaked permits, or hung fibers. ## Core Features & Use Cases - Declarative concurrency control: Apply the concurrency option (number, 'unbounded', 'inherit') to Effect.all, Effect.forEach, filter, partition, and validate for bounded or unbounded fan-out. - Racing and fallback strategies: Use race, raceAll, raceFirst, raceAllFirst, and firstSuccessOf for first-success or first-completion semantics with automatic loser interruption. - Coordination primitives: Bound shared resources across call sites with Semaphore, enforce per-key fairness with PartitionedSemaphore, and gate fibers on startup signals with Latch. - Use Case: When syncing thousands of user records against a rate-limited external API, use Effect.partition with a concurrency cap plus a Semaphore in the service layer to bound in-flight requests globally while collecting per-item failures without aborting the batch. ## Quick Start Ask the assistant to parallelize an Effect.forEach over a list of API calls with a concurrency limit of 8 and collect failures without aborting the batch.
