main branch: remove more "Effect<never, never"s (#454)

pages/docs/concurrency/deferred.mdx

@@ -24,7 +24,7 @@ A `Deferred` in Effect is conceptually similar to JavaScript's `Promise`. The ke
 
 ### Creating
 
-You can create a `Deferred` using `Deferred.make<A, E>(){:ts}`. This returns an `Effect<never, never, Deferred<A, E>>`, which describes the creation of a `Deferred`. Note that `Deferred`s can only be created within an `Effect` because creating them involves effectful memory allocation, which must be managed safely within an `Effect`.
+You can create a `Deferred` using `Deferred.make<A, E>(){:ts}`. This returns an `Effect<Deferred<A, E>>`, which describes the creation of a `Deferred`. Note that `Deferred`s can only be created within an `Effect` because creating them involves effectful memory allocation, which must be managed safely within an `Effect`.
 
 ### Awaiting
 
@@ -55,7 +55,7 @@ Here's an example that demonstrates the usage of these completion methods:
 
 ```
 
-When you complete a `Deferred`, it results in an `Effect<never, never, boolean>`. This effect returns `true` if the `Deferred` value has been set and `false` if it was already set before completion. This can be useful for checking the state of the `Deferred`.
+When you complete a `Deferred`, it results in an `Effect<boolean>`. This effect returns `true` if the `Deferred` value has been set and `false` if it was already set before completion. This can be useful for checking the state of the `Deferred`.
 
 Here's an example demonstrating the state change of a `Deferred`:
 
@@ -71,7 +71,7 @@ Sometimes, you may want to check whether a `Deferred` has been completed without
   - If the `Deferred` is not yet completed, it returns `None`.
   - If the `Deferred` is completed, it returns `Some`, which contains the result or error.
 
-Additionally, you can use the `Deferred.isDone` method, which returns an `Effect<never, never, boolean>`. This effect evaluates to `true` if the `Deferred` is already completed, allowing you to quickly check the completion status.
+Additionally, you can use the `Deferred.isDone` method, which returns an `Effect<boolean>`. This effect evaluates to `true` if the `Deferred` is already completed, allowing you to quickly check the completion status.
 
 Here's a practical example:
 

pages/docs/context-management/default-services.mdx

@@ -15,7 +15,7 @@ When we employ these services, there's no need to explicitly provide their imple
 As you can observe, even if our program utilizes both `Clock` and `Console`, the `R` parameter, representing the contextual data required for the effect to execute, remains set to `never`.
 
 ```ts /never/1
-Effect<never, never, void>
+Effect<void>
 ```
 
 Effect takes care of handling these services seamlessly for us.

pages/docs/context-management/services.mdx

@@ -222,7 +222,7 @@ The `serviceOption` function returns an implementation that can is available onl
 To represent this optionality it returns an `Option` of the implementation:
 
 ```ts
-Effect<never, never, Option<Random>>
+Effect<Option<Random>>
 ```
 
 Let's take a look at an example that demonstrates the usage of optional services:

pages/docs/data-types/either.mdx

@@ -86,7 +86,7 @@ The `Either` type is a subtype of the `Effect` type, which means that it can be
 
 In the context of `Effect`, the two members of the `Either` type are treated as follows:
 
-- `Left<E>` is equivalent to `Effect<never, E, never>`
+- `Left<E>` is equivalent to `Effect<never, E>`
 - `Right<A>` is equivalent to `Effect<A>`
 
 To illustrate this interoperability, let's consider the following example:

pages/docs/data-types/option.mdx

@@ -170,7 +170,7 @@ The `Option` type is a subtype of the `Effect` type, which means that it can be
 
 In the context of `Effect`, the two members of the `Option` type are treated as follows:
 
-- `None` is equivalent to `Effect<never, NoSuchElementException, never>`
+- `None` is equivalent to `Effect<never, NoSuchElementException>`
 - `Some<A>` is equivalent to `Effect<A>`
 
 To illustrate this interoperability, let's consider the following example:

pages/docs/error-management/error-channel-operations.mdx

@@ -33,7 +33,7 @@ The `Effect.mapBoth` function allows you to **apply transformations to both chan
 
 ```
 
-After using `mapBoth`, we can observe that the type of our program has changed from `Effect<never, string, number>` to `Effect<never, Error, boolean>`.
+After using `mapBoth`, we can observe that the type of our program has changed from `Effect<number, string>` to `Effect<boolean, Error>`.
 
 <Info>
   It's important to note that using the `mapBoth` function **does not change**

pages/docs/error-management/expected-errors.mdx

@@ -39,7 +39,7 @@ Expected errors **are tracked at the type level** by the `Effect` data type in t
 It is evident from the type of `program` that can fail with an error of type `HttpError`:
 
 ```ts /HttpError/
-Effect<never, HttpError, never>
+Effect<never, HttpError>
 ```
 
 ## Error Tracking
@@ -73,7 +73,7 @@ In this case, we have `FooError` and `BarError` as the possible error types.
 The error channel of the `program` is specified as
 
 ```ts /FooError | BarError/
-Effect<never, FooError | BarError, string>
+Effect<string, FooError | BarError>
 ```
 
 indicating that it can potentially fail with either a `FooError` or a `BarError`.
@@ -149,7 +149,7 @@ We can observe that the type in the error channel of our program has changed to
 indicating that all errors has been handled.
 
 ```ts /never/2
-Effect<never, never, string>
+Effect<string>
 ```
 
 ## Catching Some Errors
@@ -167,7 +167,7 @@ We can observe that the type in the error channel of our program has changed to
 indicating that `FooError` has been handled.
 
 ```ts /BarError/
-Effect<never, BarError, string>
+Effect<string, BarError>
 ```
 
 If we also want to handle `BarError`, we can easily add another case to our code:
@@ -206,7 +206,7 @@ We can observe that the type in the error channel of our program has changed to
 indicating that `FooError` has been handled.
 
 ```ts /BarError/
-Effect<never, BarError, string>
+Effect<string, BarError>
 ```
 
 If we also wanted to handle `BarError`, we can simply add another `catchTag`:

pages/docs/essentials/creating.mdx

@@ -25,11 +25,11 @@ To create an effect that represents a successful computation, you can use the `E
 
 ```
 
-The `program` value has the type `Effect<never, never, number>` and can be interpreted as an effect that:
+The `program` value has the type `Effect<number>` and can be interpreted as an effect that:
 
-- does not require any context (`never`)
-- does not produce any expected error (`never`)
 - succeeds with a value of type `number`
+- does not produce any expected error (`never`)
+- does not require any context (`never`)
 
 ### `Effect.fail`
 
@@ -39,11 +39,11 @@ To create an effect that represents a failure, you can use the `Effect.fail` con
 
 ```
 
-The `program` value has the type `Effect<never, string, never>` and can be interpreted as an effect that:
+The `program` value has the type `Effect<never, string>` and can be interpreted as an effect that:
 
-- does not require any context (`never`)
-- fails with an expected error of type `string`
 - does not produce any value (`never`)
+- fails with an expected error of type `string`
+- does not require any context (`never`)
 
 With `Effect.succeed` and `Effect.fail`, you can explicitly handle success and failure cases and the type system will ensure that errors are tracked and accounted for.
 
@@ -77,7 +77,7 @@ If you're working with synchronous side effects and you're confident that they w
 
 In the above example, `Effect.sync` is used to defer the side-effect of writing to the console.
 
-The `program` value has the type `Effect<never, never, number>` because the thunk returns the value `42`.
+The `program` value has the type `Effect<number>` because the thunk returns the value `42`.
 
 Note that nothing is logged to the console yet when you inspect it.
 This is because `program` represents the action of writing to the console, but nothing happens until you explicitly [run your program](running.mdx).
@@ -123,11 +123,11 @@ If you're working with asynchronous side effects that return a `Promise` and you
 
 ```
 
-The `program` value has the type `Effect<never, never, string>` and can be interpreted as an effect that:
+The `program` value has the type `Effect<string>` and can be interpreted as an effect that:
 
-- does not require any context (`never`)
-- does not produce any expected error (`never`)
 - succeeds with a value of type `string`
+- does not produce any expected error (`never`)
+- does not require any context (`never`)
 
 <Error>
   The `Promise` within the thunk passed to `Effect.promise` should never reject.

pages/docs/essentials/pipeline.mdx

@@ -132,7 +132,7 @@ Many JavaScript / TypeScript engineers are familiar with the term `flatMap` due
 If you have an Effect where result type is a nested `Array`, for example:
 
 ```
-Effect<never, never, Array<Array<A>>>
+Effect<Array<Array<A>>>
 ```
 
 you can easily flatten the array using either the `ReadonlyArray` module exported from `effect`:

pages/docs/observability/otel/metrics.mdx

@@ -64,7 +64,7 @@ Here's a practical example of creating and using a counter in your code:
 
 In this example, we create a counter called `taskCount`, which is incremented by 1 each time it's invoked. We then use it to monitor the number of times certain tasks are executed. The result provides valuable insights into the cumulative count of these tasks.
 
-It's worth noting that applying the `taskCount` metric to an effect doesn't change its type. So, if `task1` has a type of `Effect<never, never, number>`, then `taskCount(task1)` still has the same type, `Effect<never, never, number>`.
+It's worth noting that applying the `taskCount` metric to an effect doesn't change its type. So, if `task1` has a type of `Effect<number>`, then `taskCount(task1)` still has the same type, `Effect<number>`.
 
 ## Gauge
 

pages/docs/observability/otel/tracing.mdx

@@ -44,7 +44,7 @@ You can instrument an effect with a Span using the `Effect.withSpan` API. Here's
 
 ```
 
-It's important to note that instrumenting an effect doesn't change its type. You start with an `Effect<never, never, void>`, and you still get an `Effect<never, never, void>`.
+It's important to note that instrumenting an effect doesn't change its type. You start with an `Effect<void>`, and you still get an `Effect<void>`.
 
 ## Printing Spans
 

pages/docs/quickstart.mdx

@@ -222,7 +222,7 @@ import { Effect } from "effect"
 function App() {
   const [count, setCount] = useState(0)
 
-  // Effect<never, never, void>
+  // Effect<void>
   const task = useMemo(
     () => Effect.sync(() => setCount((current) => current + 1)),
     [setCount]