back
1 comments
Closures everywhere... why? They make code difficult to reason about and read and only seem to satisfy the FP zealots.
You don't have to be a functional programming zealot to be able to recognize the value of not having to define a function just so you can sort a list using a different predicate.
Except that’s not the extent of how programming with closures is forced on Swift coders.

Essential all major modern languages have collection sorting functions built into the base collection types that accept “by” (or similar) arguments... which is quite intuitive to even Jr. programmers.

OK, what's an actual example of your problem? I don't write Swift, but I'm curious about it - where's a closure used when some fixed logic would've sufficed?
Did you read the parent article? Good examples there.
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) }