[solidninja]

I'm always fascinated by the amount of comments that devalue separating concerns and reducing coupling by using traits and modules. Maybe if you're exclusively writing serverless functions you don't need much code anyway, but the idea that you can go and read a piece of code that deals with the database separately from a piece of code that deals with your HTTP request encoding (and see how they meet in the middle via a few method signatures) is a pretty powerful one in my experience.

[FridgeSeal]

I don't think anyone here is seriously suggesting that separating IO and concerns is bad.

I think people here are devaluing the "kind of approach" taken in these over-abstracted-architectures. The snippets of "improved" code in TFA have a lot of new line-noise, a lot of boilerplate and half-a-dozen "new" pieces of terminology, all in the quest to essentially separate IO and core logic.

There's plenty of ways to perform this separation, many of them don't require replicating half the design-patterns from C# tutorial. I'm pretty partial to "functional-core, imperative-shell", I think that it achieves all the same advantages, with none of the new concepts, and far less line noise.

[globular-toast]

Thanks for providing an example of how to do the separation in a better way! Many of the other comments are just saying "this is stupid" because they've never built anything big enough to see why domain driven design exists. Abstract classes etc are just a means to an end, they are not the goal. Dependency inversion is the goal. It's good to know there are ways to do it in Rust.