Effect: TypeScript più affidabile (davvero) con errori tipizzati, dipendenze esplicite e guardrail

TypeScript provides more reliable code with predictable errors, explicit dependencies, and guardrails. TypeScript is typed, but not enough when it comes to errors: the fact that a function can fail is not part of its type. In TypeScript, a function like `getUser(id)` that queries the DB returns a `User` if it exists or throws an error (invalid ID, user not found, etc.).

The return type remains implicit, relying on documentation, conventions, and team memory. As the codebase grows, this leads to more bugs: unhandled errors, forgotten branches, and ignored edge cases. Effect is designed to fill this gap by making expected failures part of the function's type.

Effect models a function as something that can succeed with a value or fail with a typed error. It returns a richer type: `Effect<Success, Error, Dependencies>`, where:

- Success is the value produced in case of success

- Error is the union of expected errors (the ones you want to handle explicitly)

- Dependencies are the services required (when using the service/DI approach)

Effect encourages distinguishing between expected errors (like invalid input, missing records, missing permissions) and defects (unintended bugs, invariant violations, uncovered cases). Expected errors become design decisions, not incidental path occurrences. The third parameter is explicit dependencies, which avoids "magical" code and facilitates dependency injection.

Function declarations specify what they need in the type, resulting in a clear understanding of what a function requires. If a required dependency is missing, it's not a silent bug but a mismatch that appears immediately when composing the program. Even without full DI adoption, this model promotes a more modular and replaceable structure (great for testing, staging, feature flags, and alternative implementations).

Effect also introduces guardrails: compiler-enforced rules that go beyond typing. Some antipatterns that work in code silently make the architecture fragile or inconsistent. Examples include improper nesting of Effects, breaking assumptions about concurrency or resource management. The Effect toolchain (e.g., `@effect/tsgo`) can replace the standard compiler and raise errors for certain violations.

Beyond error handling and dependency injection, Effect provides a toolbox of primitives for common application problems. This includes retry and timeout for fail-safe operations, concurrency utilities, job queueing and processing pipelines, rate limiting, schema validation (e.g., with Zod), typed configuration for environment variables and runtime settings, and modules with specific guides (SQL, integrations, etc.).

Notably, Effect is dependency-free, which is a practical advantage in today's supply chain concerns. While it may seem complex, the complexity is intentional, making implicit aspects like potential failure points, required resources, and architectural rules explicit. If your goal is to build codebases where "trivial" errors are difficult and maintenance doesn't depend on developer intuition, the explicitness of Effect is worth the price.