Considering Effect for a New Project
Hello everyone!
I've had Effect on my radar for a long time, thanks to @schickling. Luckily, I'm working on a green field project right now, and I'm considering using Effect from the get-go. The ergonomics are stellar, and I'm pretty sure it will make the overall codebase more streamlined and composable. Before investing time into mastering the learning curve, I wanted to bring multiple angles into the evaluation, such as performance.
Therefore, I came up with a super basic example that uses one core primitive: generator functions. Although I'm aware that "back in the day," the
Here is the basic benchmark: https://gist.github.com/akoenig/246878ada22e069e48c74a79376ed713
Based on my basic benchmark, I can say that the generators are not the culprit. Creation and performance are quite good. I figured that the Effect runtime adds some slight overhead, which is quite natural. See my comment below the code in the gist.
I've had Effect on my radar for a long time, thanks to @schickling. Luckily, I'm working on a green field project right now, and I'm considering using Effect from the get-go. The ergonomics are stellar, and I'm pretty sure it will make the overall codebase more streamlined and composable. Before investing time into mastering the learning curve, I wanted to bring multiple angles into the evaluation, such as performance.
Therefore, I came up with a super basic example that uses one core primitive: generator functions. Although I'm aware that "back in the day," the
tsc transpiled async/await down to generator functions as well, I wanted to make sure that today it doesn't introduce a performance hit when relying on it heavily.Here is the basic benchmark: https://gist.github.com/akoenig/246878ada22e069e48c74a79376ed713
Based on my basic benchmark, I can say that the generators are not the culprit. Creation and performance are quite good. I figured that the Effect runtime adds some slight overhead, which is quite natural. See my comment below the code in the gist.
