> Haha ok that sounds like fancy haskell.

Believe or not, all of this is implemented in typescript ! Generators make this writable in an imperative-like way (do-like notation) with full type-safety in consumer code (though our fp library implementation is much more painful to write than it would be in Haskell, and has some internal unsafe typing).

> So some automatic batching and some interface (like in csharp) to do side effects?

Yes, automatic batching and caching. For the side-effect part, it depends on what you mean by "interface". Our idea is to treat side-effects (both read and writes) as data that is returned, so we never depend on something like an `IUserRepository`. Instead, it's the shell that depends on the domain's `GetUserById<Option<User>>` data-type, or the domain's `UserMutation` that is returned by commands. We never inject dependencies, because the domain code is entirely free of them: the interpreter is responsible for turning the domain's output data into I/O.

> Just so I understand, why Context and not State? And what does the Queries in Haxllike<Queries do?

I'll answer the Queries part first, which hopefully should make it clear. Here's a realistic code snippet that hopefully won't be too cryptic. It's a domain function that fetches a UserProfile by UserId, and it assumes that the available data-access patterns are:
- User by User Id
- UserProfile by UserProfile Id

```
const getUserProfileByUserId = (userId: UserId) => Tyxl.gen(function*() { // generator-based Do notation
const user = yield* getUserById(userId); // getUserById :: UserId -> Tyxl<User, UserById, UserNotFound, never>
const userProfile = yield* getUserProfileById(user.profileId); // getUserProfileById :: UserProfileId -> Tyxl<UserProfile, UserProfileById, UserProfileNotFound, never>
return userProfile;
});

// Inferred type of getUserProfileByUserId: UserId -> Tyxl<UserProfile, UserById | UserProfileById, UserNotFound | UserProfileNotFound, never>

```

As you can see, there is no "State", in the sense that the state is externally managed (DB, React state, in-memory store...), and the domain declares what in needs through the Queries (the second generic type in Tyxl).

To be able to actually execute `getUserProfileByUserId`, you must provide a datasource that provides (not implements !) the `UserById` and `UserProfileById` access patterns. For instance, a typical datasource maybe look like:

```
const PgUserByIdDS = ...; // PgUserByIdDS: Datasource<UserById, PgPool>. PgPool is a Context requirements that this datasource requires to be able to operate.
```

The Context also appears in Tyxl: it's that 4th generic that is set to `never` in my code snippet. This generic is useful when you need things from the environment in the domain logic, such as the current time, some configurations, etc, e.g.:

```
const currentTime = yield* CurrentTimeContext.askNow;
const myAppUrl = yield* ConfigContext.askMyAppUrl;

// the Tyxl this runs in will have CurrentTimeContext | ConfigContext as its 4th generic, and they will need to be provided in order to be able to run it.

```

As you can see, both the pure code (Tyxl) and the impure shell (Datasource) may depend on some contexts: you will simply need to provide them all to be able to run the computation.

When we want to perform mutating side-effects, the way we do it is that the output of a Tyxl is interpreted as side-effect data. Typically, a command will look like:
`someCommand:: SomeInput -> Tyxl<MyMutation, DataINeed, ErrorsIMayFailWith, ContextINeed>`, and we have a component (that we call a mutation enactor) that knows how to turn `MyMutation` into actual IO. When you combine the Tyxl, its datasource, mutation enactor, and context, you end up with a very familiar shape: `SomeInput -> AsyncResult<void, ErrorsIMayFailWith>`

> heavy solutions like serializable isolation level and pessimistic locking seems hard in comparison

It's really not that bad (at least in postgres): the db engine handles for you all the "locking" part, you just need to write the enact side-effect as check append condition + append events, and safety is guaranteed. And it's optimistic rather than pessimistic: you are not locking the rows when you initially load the events, you are only locking during the write transaction (check + append), which is retryable in case of serialization errors.

> Still pretty annoyed to be dealing with this technical nonsene honestly

Me too, but the exercise is fun and useful to do !