Whether the language has async/await at all, how it represents a not-yet-ready value, and the sharp foot-gun of calling a blocking function from inside async code.
Go is the deliberate odd one out in this section: it has no async/await keyword and no Future/Promise type in its standard library, by design -- goroutines and channels already give you the same non-blocking-from-the-caller's-perspective behavior without a separate syntax. The other four all have async/await, but the underlying value-not-ready-yet type differs (CompletableFuture, Deferred, coroutine Task, Promise), and all four share the same sharp edge: calling a blocking API from inside 'async' code silently defeats the entire point.
Go is the one language in this manual with neither async/await syntax nor a Future/Promise type in its standard library -- and this is a deliberate design choice, not a missing feature.
// No async/await, no Future/Promise type in the standard library at all.
// A goroutine + channel gives the same 'runs concurrently, get the
// result later' behavior with completely ordinary function calls:
resultCh := make(chan User)
go func() { resultCh <- fetchUser() }()
user := <-resultCh // this IS the 'await', just spelled as a channel receiveThis is a genuine, deliberate design decision documented across Go team talks: rather than adding async/await syntax and a Future type, Go gives you one general concurrency mechanism (goroutines + channels) that already composes with completely ordinary, un-colored functions. There is no 'async function' vs. 'sync function' distinction to propagate through your call stack the way there is in every other language in this section -- any function can be run in a goroutine, full stop.
// No Future/Promise type at all -- a channel of exactly one value
// (or a struct{ Value T; Err error }) plays this role when needed:
type Result struct { Value int; Err error }
resultCh := make(chan Result, 1)
go func() { v, err := compute(); resultCh <- Result{v, err} }()Go code that specifically needs a 'future' shape (a single eventual value, possibly with an error) typically models it by hand as a single-capacity channel carrying a small result struct -- there is no standard-library Future type, and reaching for one is rare enough in idiomatic Go that most codebases just use channels directly instead of building a Future abstraction on top.
// 'all': WaitGroup, shown earlier. 'race': select on multiple channels --
// this is precisely what select was built for:
select {
case r := <-chA:
fmt.Println("A won:", r)
case r := <-chB:
fmt.Println("B won:", r)
}
// Neither goroutine is automatically cancelled -- pass a context if you need that.select is Go's native 'race' primitive, built into the language itself rather than a library function -- whichever channel has a value ready first is chosen (pseudo-randomly if multiple are ready simultaneously). Like Java's anyOf and JS's Promise.race, the losing goroutines are not automatically cancelled; that requires explicitly passing and checking a context.Context.
This is arguably the single most common real-world bug across every async/await-flavored language: one accidental blocking call inside async code doesn't error, it just silently stalls everyone else.
// A blocking call inside a goroutine is completely normal and fine --
// the Go scheduler detects a goroutine blocked in a syscall and hands
// its OS thread to another runnable goroutine automatically:
go func() { rows, _ := db.Query(sql) }() // safe by designGo's runtime scheduler specifically handles this case: when a goroutine blocks in a syscall (file I/O, network I/O, etc.), the scheduler detaches the OS thread and lets another goroutine run on a fresh or existing thread, similar in spirit to how a virtual thread unmounts in Java. This is a genuine structural advantage over async/await languages -- there's no 'wrong pool' to accidentally block, because there's only ever goroutines.
Java's virtual threads are worth a dedicated callout because they solve the exact problem async/await solves, via the opposite approach — and this contrast is a genuinely good senior-level talking point.
suspend fun, async def, or async function is explicitly a different kind of function than a regular one, and that difference propagates through every caller ("async all the way up") — you always know, from the signature, that a function might yield control.Being able to state this trade-off out loud — not just that Java 'added something like async' — is a strong signal in a senior/staff interview.
The pre-virtual-threads composable-future API, and its thenCompose/thenCombine/allOf combinators.
async/await, sequential vs. concurrent composition, and lazy vs. eager coroutine start.
async def, await, Task, and asyncio.gather -- the full core vocabulary.
Promise states, chaining, and Promise.all/any/race/allSettled.
Representative of the Go team's broader design philosophy of preferring one general mechanism (goroutines) over separate async syntax.