Exercise 2: Why Two Different Languages Both Achieve Real Concurrency — Possible Solution
====================================================================

WHY FASTAPI ACHIEVES IT
------------------------------
Python's asyncio.gather() starts every lookup_ingredient coroutine essentially at once, and while any one of them is waiting on its own httpx.AsyncClient call to TheMealDB, Python's event loop is free to make progress on the others - the async/await model built into the language is what enables this.

WHY EXPRESS ACHIEVES IT
------------------------------
JavaScript's Promise.all() starts every fetch call immediately when .map() runs, and Node's own single-threaded event loop similarly stays free to progress other pending requests while any one of them is waiting on a network response - the same underlying non-blocking-I/O idea, built into JavaScript's own event-loop model.

THE SHARED UNDERLYING REASON
------------------------------
Both Python's asyncio and JavaScript's event loop are built around the same core idea: a piece of code that's waiting on I/O (a network response, in both cases) yields control back to a central scheduler, which uses that idle time to make progress on other pending work instead of sitting idle. Despite being two syntactically very different languages, both happen to share this same non-blocking, event-loop-based concurrency model at a fundamental level - which is exactly why both courses can achieve genuinely concurrent fan-out using each language's own native tools, without needing threads or any special extra machinery.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains the specific mechanism each language uses (asyncio.gather with async/await in Python, Promise.all with the event loop in JavaScript), and correctly identifies the shared underlying reason both achieve the same concurrent result - both languages are built around a non-blocking, event-loop-based model of handling I/O.