You can only get around callbacks for async IO with async/await or language-integrated N:M threading, which is a challenging problem (I still trigger ICEs in Rust's implementation on occasion). Java is another language which suffers from this, and C++ only got coroutines in C++20.

I don’t see anything in the example to indicate that the closure pattern for Swift Lambda handlers actually allows true async.

func lambdaHandler(event: Event, context: Context) { // your lambda handler logic... }

What’s wrong with this approach, which is how lambda handlers are written in every other language with the exception of JavaScript - let’s not pretend that JavaScript is a good language design reference.

Look at this Go example In comparison... simple, readable, intuitive:

package main

import ( "fmt" "context" "github.com/aws/aws-lambda-go/lambda" )

type MyEvent struct { Name string `json:"name"` }

func HandleRequest(ctx context.Context, name MyEvent) (string, error) { return fmt.Sprintf("Hello %s!", name.Name ), nil }

func main() { lambda.Start(HandleRequest) }

Here's an example from the official Go documentation on using closures in the same sort of place - https://golang.org/pkg/net/http/#example_ServeMux_Handle

Yes, closures are present in many languages, but they are pervasive and unavoidable in Swift. You’re avoiding addressing the idea that closures actually cause layers of (often unnecessary) indirection, make code more difficult to reason about, and make code harder to read - especially for jr. devs.

No, I'm suggesting that you've not shown they must be used any more than in other languages - and obviously in order to make sense of the examples in Go's documentation you've got to know how they work, and Go is pretty much the language designed for junior backend devs.

What worries me is not so much the somewhat excessive use of closures itself but rather the combination of closures and the potential for circulcar references.

https://news.ycombinator.com/item?id=21919728

I mean, you can do that in Swift too. You can also use closures in Go in exactly the same way, which is what I tend to do for very small functions that don't need a name.

Functions and closures-that-don't-reference-their-environment are exactly equivalent in both languages, from a quick look? It's your choice as a developer which to use.

This particular pattern in the case of Lambda is specifically for providing a closure which is called later and repeatedly - it's not waiting for a request and then calling the closure once and then returning.