edmondx

Of all the ways to program with async, I like transparent asynchrony the most. Even though it may seem implicit, it turns out to be the most convenient.

Great article. I like how it presents a realistic view without hype, showing both the benefits and the tradeoffs.

Swoole Compiler v4 introduces a native AOT (Ahead-of-Time) compiler that radically changes the landscape. The AOT compiler abandons traditional PHP interpretation and allows code to be compiled directly into native binary executables. Performance can increase by orders of magnitude compared to the classic interpreter, reaching levels comparable to Rust and Go.

> No actually it's a joy to have no multithreading.

To build CPU-bound applications in PHP, you have to install a bunch of packages, rely on Redis, and try to approximate what Python or Go can do in a dozen lines of code. Can that really be enjoyable?

It seems like you’re talking about something similar: https://true-async.github.io/en/docs/components/thread-pool....

I’ve also wanted parallelism in PHP for a long time. Especially the kind of parallelism that works together with concurrent I/O. That’s when it becomes truly useful, not just a toy.

Asynchrony will always be a complex tool because of the number of states involved. That’s true. But if it’s made convenient and used properly, it becomes enjoyable to work with.

I also feel a shift in what I spend my time on. Sometimes I just don’t feel like thinking about complex things. But is that really a problem? If you’re too lazy to do something, maybe it doesn’t need to be done at all?

Nice to see more native C extensions pushing performance boundaries in PHP. Writing grep as an extension rather than shelling out or using preg_match for large file scanning makes a lot of sense — you skip the regex overhead for fixed-string patterns entirely.

> PHP SDK is in the works and should be out by end of day Glad to hear that! Thank you!

Clean approach. We deal with similar memory lifecycle problems in a PHP async extension (C, libuv-based reactor). Coroutine stacks and their associated state need deterministic cleanup when a coroutine completes or gets cancelled — arenas with scope-based cleanup would be a natural fit there.

The O(1) cleanup claim is interesting. How does it handle cross-arena references? In our case a coroutine can capture a reference to an object owned by a parent scope, and that's where simple arena strategies usually fall apart.

Great timing with this — the LocalStack auth token change broke a lot of CI pipelines. Nice to see a Rust-based alternative with that kind of startup time (~500ms, 10 MiB idle).

The "real PostgreSQL/Redis behind RDS/ElastiCache" approach is the right call. We run PHP integration tests against SQS and S3, and the biggest pain with mocked services is subtle behavioral differences that only show up in production. Having actual protocol conformance validated against Smithy models is a big deal.

One question: any plans for async event delivery for SNS/EventBridge? In our setup we test fan-out patterns where message ordering and delivery timing matter — curious how Fakecloud handles that vs real AWS eventual consistency.

Sounds very promising. Although right now I’m working on a project together with MLIR.

I’m afraid the balance of open source wasn’t broken today. It happened quite a long time ago. It’s just not something people usually talk about. Companies have been using open source code for years to build paid products without giving anything back. Take PHP as an example: a language widely used across the internet, yet with a very limited budget.

I’m working on https://github.com/true-async/php-async and planning to bring it to a production-ready state. It would be great to build a fast HTTP server.