It's not about the callback at all, the example is poor and the explanation is lacking. In Go, many standard I/O functions use async I/O under the hood. When you call such a function (inside the handler callback, that is), the current goroutine is suspended yielding to other goroutines, so waiting for I/O doesn't block the OS thread inside the request handler. It's basically what you'd do in C# with async/await, except it's implicit and you don't have to mark functions as asynchronous manually. I.e. you write simple synchronous code and Go makes it asynchronous under the hood. There are several disadvantages, though: it's not tunable, and if there's a CGO call (call to a C func) which uses I/O itself it will block an entire worker thread because the Go runtime isn't aware of any of it.

As far as I know, Java's new virtual threads have the same idea.

In the case of a CGO call you could prefix the enclosing function definition with the "go" keyword to manually initiate a new goroutine? Am I understanding this correctly?

Goroutines are multiplexed onto a finite number of OS threads, which is usually a pretty small number. If you launch a new goroutine, a funky CGO call will still block an entire OS thread, it won't change anything as far is blocking is concerned. When all OS threads are blocked the runtime will spawn additional OS threads, so in the worst case it can degenerate to "OS thread per request".

>Nothing there tells you how async or not the server implementation is, and that `os.write()` call might be using a thread pool underneath.

It depends on the contract of the method. If it promises to throw an exception if the call failed, then the current thread of execution can't proceed before the call returns, or it would break the semantics. So even if it uses a thread pool, the current thread will have to block, waiting for some acknowledgement by os.write(), wasting an entire OS thread. As far as I know, Go won't block, the scheduler will just switch to a different goroutine in the meantime. Java's new virtual threads will allow to have mechanism similar to Go's.

agreed. the examples don’t show the real pain. it is when every method returns Future or Promise. and you have to map each result. and many languages don’t have good support for that so you end up with lots of nesting. writing synchronous function signatures is much simpler to maintain.

there’s 2 language level syntax features i see that make this better:

one is scalas for comprehension. this lets you write async code that reads like imperative synchronous lines. the other is async/await, which let’s you write synchronous code that behaves like async

The comparison with Java is awful. Especially the performance comparison since the sun http server isn’t meant to be used and isn’t a part of the language spec.

I thought I was the only one who wasn’t getting it.

> TL;DR The Go standard runtime allows for asynchronous coding while allowing the developer a simply synchronous interface.

I didn't read the article but this TL;DR captures the essence of simplicity of programming in Go when writing IO apps. Go essentially optimizes for the majority case: run these things one after another. All the await/async fluff in other languages is evidence of poor/old language design. Every non-trivial production code you see these days in Javascript is littered with await/async as is the case in Python, etc. Why the heck do I have to repeat a keyword 1000s of times when that's expected in majority of languages.

Yes, Go may not cover every case perfectly (e.g. mentioned by sibling re CGO blocking OS thread), but when you look at real world stats of how often this is an actual issue, you find that it's almost noise (i.e. do a code search across Github for instance for such workarounds).

The writing of response (the write to the socket).

Go: fmt.Fprintln(w, "Goodbye, World!")

Java: os.write(response.getBytes());