Read the corrected Go snippet in execution order. The goroutine is created first, and the semaphore acquire happens inside it, in a select against ctx.Done() [7]. So the cap of 500 governs concurrent process() calls, not goroutines: a request carrying 200 subtasks still creates 200 of them [3]. For cheap in-process work that is the right tradeoff, because a parked goroutine costs a few kilobytes and no scheduler time. It is still worth knowing which number you bounded.
The scale figure converts usefully. If the bursts carried 50 to 200 subtasks per request [4], a million goroutines works out to roughly 5,000 in-flight requests at the top of that range and 20,000 at the bottom [1]. The fan-out multiplier set that number, not the arrival rate. It is also one account, published on dev.to and originally on tamiz.pro [14], reporting that scheduler overhead became significant without giving a figure for it [6].
The Python remedy is where I would stop the review. asyncio.wait returns done and pending, and the snippet binds the second to an underscore [11][4]. The timeout does not cancel the pending tasks; the caller just stops waiting for them. The write-up's own diagnosis is that a goroutine leak becomes a token leak [10], and this is the line where that happens, because abandoned work is still billed work. The comprehension also reads r.result rather than calling it, so treat the sample as illustration rather than a drop-in [5].
Then the unit. A semaphore counts calls [11]. The scarce things named are rate limits and token budgets [10], and each of the 20 to 50 calls in a fan-out carries its own context window [9]. Ten slots bound calls in flight while tokens per minute stay free to spike, because a 200k-context call and a 2k-context call occupy the same slot [6]. For max_concurrent=10 to transfer to your service, two things have to hold: your subtask contexts are roughly the same size, and your provider quota is denominated in requests. Mine is denominated in tokens.
The cap also has a price the piece does not name. Fifty subtasks through ten slots is five waves, so plan wall-clock lands near five times a single call even when nothing fails [2]. That is the trade being made: a rate-limit error becomes a latency multiplier, paid by the user who asked for the plan.
Which is why I would import selectively. Cancellation propagation generalises as written, including the invariant that every node in the call tree inherits a context that can be cancelled and that the runtime enforces none of it [12]. Resource budgeting generalises only after you re-denominate it in the unit your invoice uses [2]. The 500 and the 10 belong to someone else's workload.
