So many promises and claims in both the post and the README, yet I have no seen any evidence. I don't want to nitpick things out because it doesn't add much to the conversation, but it's assuming a lot of things about me
"the majority of developers don't give a second thought to writing code with I/O tangled in business logic"
This is a very fuzzy intro
- "the majority of developers dont do X", is something that needs to be easily verifyable
- "writing code with I/O tangled in business logic" seems like just SoC, I doubt devs have never heard about this.
The solution is a library that adds a bunch of FP with... tests? Hard bugs require session replays, not FP. FP has nothing to do with "reproducing bugs on your device". These seem like two things loosely wired together.
If you're trying to make something alike Effect-TS, then sure, this looks like a cool library, but it took a while for me to get to that conclusion.
Also, the five AI generated articles provide little value to the conversation. They don't even have a topic, other than you talking about your own library.
The concept of developing on a system which does not closely mirror your production environment died with virtualization and containerization over a decade ago. You will experience unforeseen consequences if your development environment does not emulate your production environment as closely as possible.
I agree that this isn't communicated well, but I think the idea he's going for has nothing to do with virtualization or containerization. It's reducing all application level actions to a sequence of events, complete with the data that would get passed in. That way, you can replay production events, complete with production data, locally for debugging purposes.
Unfortunately, that also makes this a PII security nightmare.
You may have been lucky or privileged in working in high competency environments where the essence of containerization is truly captured in the dev practices. The vast majority of mediocre eng shops do "dockerize everything" but would still end up with leaks everywhere, artifacts in s3, endpoint dependencies, mounts that depend on the helm chart etc.
IMO containerization as a principle has failed the test of making mediocre teams productive. Such teams cargo cult ape on this term and think because they've done it theyre now webscale.
I personally like to still start with "this code should run anywhere" principle. On python especially with uv now this seems like a safer bet. At the least this forces the engineers to explicitly list out stupid dependencies in the reader.
I mean, to be honest, I'm the one who sets the precedent for most of the teams that I work with; that's one of my roles.
And personally, I don't necessarily follow a hard line with this. My Python API services run foregrounded in a terminal with uv run, but that doesn't mean that I'm using SQLite instead of Postgres. Any of the backend services I need that don't make sense to be foregrounded still run the same versions as prod containerized. And front end teams will tend to run a containerized API service since they're not modifying it as often.
Point being there is some conscious leeway here, but it's bounded and well-defined.
Things like this have existed for awhile. The challenge is always rolling it out to peers. It's confusing to them, and kills their velocity. Just like functional programming paradigms themselves - objectively better, but also objectively more difficult to hire for.
> you can assert on what the code intends to do without executing any of it
is that not just bending the meaning of mocking? Nulling things out and not executing them is a form of mocking (and the default behaviour for mocks in most languages)
I have the feeling that the author is really onto something: the explicit boundary between symbolic intent and real-world execution.
Type systems don’t cut it always, you sometimes need something in-between imperative code - which is hard to test all edge cases - and pure type system chasing. The sweet spot maybe lies in having a DSL (in this case "building business mutations") and have good building blocks.
> Effect-TS is the full-featured option in this space and has a large ecosystem. Pure Effect offers a different tradeoff. It covers the 80% case: testable pipelines, dependency injection, retry, and OpenTelemetry hooks, all in under 1 KB with zero dependencies and no new vocabulary to learn. Effect-TS is a framework you build around. Pure Effect, on the other hand, is a pattern you drop into existing code.
Been kicking around a similar idea in the back of my mind from the first moment "functional core / imperative shell" [0] and "sans-IO" [1] infected my brain. I've been chasing that high ever since.
Unfortunately, whenever I try to apply this pattern 100%, I hit all kinds of walls: language isn't expressive enough to support what I want; the amount of wiring/glue to support it becomes a burden; the resulting code is spaghetti because the "declaration of intent" lives too far from "implementation of the intent"; "oops I invented my Nth leaky DSL"; and so on and so on. Part of the problem is certainly my own capabilities as a developer as well.
I can't help but fantasize about the platonic ideal of a "perfect" system where all that nasty evil I/O is banished to the Shadow Realm and I can frolic in the Fields of Idempotency and Reproduciblity -- one of these days I'll bite the bullet and try Haskell.
Nowadays I aim for 80% "perfection", and only in the areas where it matters. In addition, instead of effects I rely more on "reduce complexity as much as possible", which is (frustratingly) much harder to put into practice than "use X library/pattern to solve all problems". Though if I can model the system as a state machine and proptest it [2], that usually gets me where I want to be.
Though my soul feels like I just woke up from a dream where I was perfectly content, and now I'm back in the real world with all of its imperfections [3].
---
As for your specific project, it heavily reminds me of the Crux [4] model, which is itself inspired by Elm [5]. Also Flawless [6]. I wish you the best of luck with it.
So many promises and claims in both the post and the README, yet I have no seen any evidence. I don't want to nitpick things out because it doesn't add much to the conversation, but it's assuming a lot of things about me
"the majority of developers don't give a second thought to writing code with I/O tangled in business logic"
This is a very fuzzy intro
- "the majority of developers dont do X", is something that needs to be easily verifyable
- "writing code with I/O tangled in business logic" seems like just SoC, I doubt devs have never heard about this.
The solution is a library that adds a bunch of FP with... tests? Hard bugs require session replays, not FP. FP has nothing to do with "reproducing bugs on your device". These seem like two things loosely wired together.
If you're trying to make something alike Effect-TS, then sure, this looks like a cool library, but it took a while for me to get to that conclusion.
Also, the five AI generated articles provide little value to the conversation. They don't even have a topic, other than you talking about your own library.
The concept of developing on a system which does not closely mirror your production environment died with virtualization and containerization over a decade ago. You will experience unforeseen consequences if your development environment does not emulate your production environment as closely as possible.
I agree that this isn't communicated well, but I think the idea he's going for has nothing to do with virtualization or containerization. It's reducing all application level actions to a sequence of events, complete with the data that would get passed in. That way, you can replay production events, complete with production data, locally for debugging purposes.
Unfortunately, that also makes this a PII security nightmare.
You may have been lucky or privileged in working in high competency environments where the essence of containerization is truly captured in the dev practices. The vast majority of mediocre eng shops do "dockerize everything" but would still end up with leaks everywhere, artifacts in s3, endpoint dependencies, mounts that depend on the helm chart etc.
IMO containerization as a principle has failed the test of making mediocre teams productive. Such teams cargo cult ape on this term and think because they've done it theyre now webscale.
I personally like to still start with "this code should run anywhere" principle. On python especially with uv now this seems like a safer bet. At the least this forces the engineers to explicitly list out stupid dependencies in the reader.
I mean, to be honest, I'm the one who sets the precedent for most of the teams that I work with; that's one of my roles.
And personally, I don't necessarily follow a hard line with this. My Python API services run foregrounded in a terminal with uv run, but that doesn't mean that I'm using SQLite instead of Postgres. Any of the backend services I need that don't make sense to be foregrounded still run the same versions as prod containerized. And front end teams will tend to run a containerized API service since they're not modifying it as often.
Point being there is some conscious leeway here, but it's bounded and well-defined.
Things like this have existed for awhile. The challenge is always rolling it out to peers. It's confusing to them, and kills their velocity. Just like functional programming paradigms themselves - objectively better, but also objectively more difficult to hire for.
> Testing without mocking
> you can assert on what the code intends to do without executing any of it
is that not just bending the meaning of mocking? Nulling things out and not executing them is a form of mocking (and the default behaviour for mocks in most languages)
I have the feeling that the author is really onto something: the explicit boundary between symbolic intent and real-world execution.
Type systems don’t cut it always, you sometimes need something in-between imperative code - which is hard to test all edge cases - and pure type system chasing. The sweet spot maybe lies in having a DSL (in this case "building business mutations") and have good building blocks.
Why not just use Effect? https://effect.website/
He comments on this in the Hackernews post text:
> Effect-TS is the full-featured option in this space and has a large ecosystem. Pure Effect offers a different tradeoff. It covers the 80% case: testable pipelines, dependency injection, retry, and OpenTelemetry hooks, all in under 1 KB with zero dependencies and no new vocabulary to learn. Effect-TS is a framework you build around. Pure Effect, on the other hand, is a pattern you drop into existing code.
We have effect.ts, also this was here on HN with not real improvements just with changed marketing I think.
Been kicking around a similar idea in the back of my mind from the first moment "functional core / imperative shell" [0] and "sans-IO" [1] infected my brain. I've been chasing that high ever since.
Unfortunately, whenever I try to apply this pattern 100%, I hit all kinds of walls: language isn't expressive enough to support what I want; the amount of wiring/glue to support it becomes a burden; the resulting code is spaghetti because the "declaration of intent" lives too far from "implementation of the intent"; "oops I invented my Nth leaky DSL"; and so on and so on. Part of the problem is certainly my own capabilities as a developer as well.
I can't help but fantasize about the platonic ideal of a "perfect" system where all that nasty evil I/O is banished to the Shadow Realm and I can frolic in the Fields of Idempotency and Reproduciblity -- one of these days I'll bite the bullet and try Haskell.
Nowadays I aim for 80% "perfection", and only in the areas where it matters. In addition, instead of effects I rely more on "reduce complexity as much as possible", which is (frustratingly) much harder to put into practice than "use X library/pattern to solve all problems". Though if I can model the system as a state machine and proptest it [2], that usually gets me where I want to be.
Though my soul feels like I just woke up from a dream where I was perfectly content, and now I'm back in the real world with all of its imperfections [3].
---
As for your specific project, it heavily reminds me of the Crux [4] model, which is itself inspired by Elm [5]. Also Flawless [6]. I wish you the best of luck with it.
[0]: https://www.destroyallsoftware.com/screencasts/catalog/funct...
[1]: https://fasterthanli.me/articles/the-case-for-sans-io
[2]: https://sled.rs/simulation.html
[3]: https://xkcd.com/224/
[4]: https://github.com/redbadger/crux#architectural-overview
[5]: https://guide.elm-lang.org/architecture/
[6]: https://flawless.dev/