> In my experience most codebases have a pure functional subset, and I believe writing that subset in a pure-functional style is nearly always a win for the lon

> In my experience most codebases have a pure functional subset, and I believe writing that subset in a pure-functional style is nearly always a win for the long-term health of the project. I came to the same conclusion ~1 year ago when writing rust. It's pretty common to have some "high level" method in rust then you split it up, some small parts go into other maybe private methods but a lot goes into split out functions (through this depends on the task, and sometimes could be made into methods if rust would support partial self-borrows). The only think which sometimes bothers me with that approach is where to place this split out methods. As long as I don't need their functionality in other places I want them to be keep close to the function because of which they exist. But they are function and not methods so placing them in the `impl` block isn't right. Alternatively making them free functions in the method using them seems better but also isn't quite right as this "blows" up the method...