the convention of With is still in discussion and may change in the future, it currently identify a lazy version of a function like T.succeedWith(() => 0) vs T.succeed(0) an alternative that we are considering is instead T.succeed(() => 0) and T.succeedNow(0) the reason being it is more common and usually more correct to use the lazy versions (the eager ones are better in some very specific cases for perf but risky to use).
new and extends, in this we do not agree with what "the bad parts" are, as a language TypeScript is not Haskell, it is a language that encompass both objects and functions as first-class only focusing on some restricted components limit the possibilities a lot, namely classes are extremely helpful as they are the only typescript construct (apart from enums) that both define a term symbol and a type symbol, namely a class is both a type and a concrete blueprint of an object, this enables for DSLs such as the one exposed in @effect-ts/core/Case that simulates data classes with hash+equals+copy methods.
generators this to be honest is trickery and a good degree of magic, the idea was to simulate a monadic do in a way that is native to the language (like an async-await would do for Promise), it turns out to be incredibly powerful as the combination of the generator function with a specialised adapter allows for lifting of a set of natural transformations into the context allowing you to mix and match types, like having a generator of effects that yields Tag, Either, Option, etc out of the box. There is a performance penalty because generators aren't that fast especially if down-level is applied but they are still as fast as async-await (and effect is faster than promise so overall generator+effect is faster than plain async-await) except for multi-shot effects like Array or Stream or Chunk where we have to defensively copy the generator replaying state reconstruction at every element. One of the commonly used patterns is for example to use generators for service construction that usually requires dependencies and flexibility but only runs once at bootstrap time while still use the classic pipe for concrete implementation of procedures.
There is some effort ongoing in making some material of the mentioned kind available and we have started a weekly series on youtube where we discuss all things effect with concrete usage and live coding: youtube.com/playlist?list=PLDf3uQL...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
the convention of
Withis still in discussion and may change in the future, it currently identify a lazy version of a function likeT.succeedWith(() => 0)vsT.succeed(0)an alternative that we are considering is insteadT.succeed(() => 0)andT.succeedNow(0)the reason being it is more common and usually more correct to use the lazy versions (the eager ones are better in some very specific cases for perf but risky to use).newandextends, in this we do not agree with what "the bad parts" are, as a language TypeScript is not Haskell, it is a language that encompass both objects and functions as first-class only focusing on some restricted components limit the possibilities a lot, namely classes are extremely helpful as they are the only typescript construct (apart from enums) that both define a term symbol and a type symbol, namely a class is both a type and a concrete blueprint of an object, this enables for DSLs such as the one exposed in@effect-ts/core/Casethat simulates data classes with hash+equals+copy methods.generatorsthis to be honest is trickery and a good degree of magic, the idea was to simulate a monadic do in a way that is native to the language (like an async-await would do for Promise), it turns out to be incredibly powerful as the combination of the generator function with a specialised adapter allows for lifting of a set of natural transformations into the context allowing you to mix and match types, like having a generator of effects that yields Tag, Either, Option, etc out of the box. There is a performance penalty because generators aren't that fast especially if down-level is applied but they are still as fast as async-await (and effect is faster than promise so overall generator+effect is faster than plain async-await) except for multi-shot effects like Array or Stream or Chunk where we have to defensively copy the generator replaying state reconstruction at every element. One of the commonly used patterns is for example to use generators for service construction that usually requires dependencies and flexibility but only runs once at bootstrap time while still use the classic pipe for concrete implementation of procedures.There is some effort ongoing in making some material of the mentioned kind available and we have started a weekly series on youtube where we discuss all things effect with concrete usage and live coding: youtube.com/playlist?list=PLDf3uQL...