You’re testing a new feature in a development environment. You click “Submit,” and a few seconds later, your phone buzzes with a real-world SMS notification. Or worse, a real customer receives a “Test” email meant for a sandbox user. While these aren’t usually “delete-the-database” disasters, they represent a fundamental failure in application guardrails…

Continue reading

We’ve all had that sinking feeling. There are multiple crash reports from production. We have the exact input parameters that caused the failures. We have the stack traces. Yet, when we run the code locally, it works perfectly. If we could simply rewind time and watch the code execute exactly as it did for those failed requests, life would be a lot easier…

Continue reading

In a typical imperative application, business logic and side effects are inextricably linked. For example, when you write await db.checkInventory(…), the runtime immediately reaches out to the database. Our Effect System works differently. Instead of performing the action, our functions return a description of the action. When our code needs to check inventory, it doesn’t call the database; it returns a plain object instead, which will be executed later by an interpreter.

Continue reading

If you look at the source code of a typical application, you will likely find business logic tangled with database calls, HTTP requests firing off in the middle of validation rules, and try/catch blocks sprinkled here and there. The biggest casualty of this coupling is testability…

Continue reading