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.
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.
I don't know much of PHP, but reaching "Rust/Go" performance is not simply because they have AOT compiler, but because the semantic of the language itself allows efficient compilation.
Many attempts has been made for an AOT compiler for Python and Ruby, but they don't reach those performance because of this.
> 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?
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.
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.
SNS fan-out to SQS works today with filter policies, and EventBridge is implemented with rule matching and targets. Delivery is synchronous by default (deterministic for tests), but I'm planning a `/_fakecloud/config/sns` API to let you configure delivery delays, ordering, and failure rates per topic. That way you can test eventual consistency scenarios without changing your app code. Also, a PHP SDK is in the works and should be out by end of day.
reply