The worst version of this I've seen is when every layer is like four lines long. You step into a function expecting some logic and it's just calling another function with slightly different args. Do that six times and you forgot what the original call was even trying to do. Naming helps in theory but in practice half those intermediate functions end up with names like processInner or handleCore because there's nothing meaningful to call them.

I think I agree with what you're getting at, though I usually phrase it differently: indirection is not abstraction. A good abstraction makes it easier to understand what the code is doing by letting you focus on the important details and ignore the noise. It does this by giving you tools that match your problem space, whatever it may be. This will necessarily involve some amount of indirection when you switch semantic levels, but that's very different from constantly being told "look over there" when you're trying to figure out what the code is saying.

New pasta paradigm unlocked. Sounds like a case of premature optimization, leaning too hard on DRY.

Am reminded also of a discussion of software engineering between John Ousterhout (of whom I'm a big fan) and Robert Martin[0][1].

[0] https://github.com/johnousterhout/aposd-vs-clean-code

[1] https://youtu.be/3Vlk6hCWBw0

Someone has worked too much on corporate Java Codebases.

I feel your pain. Everything is so convoluted that 7 layers down you ask yourself why you didn't learn anything useful...

I’m familiar with spaghetti code and with lasagna code (too many layers) but I’m curious: what’s ravioli code?

I think it’s making a case that normally you shouldn’t even bother benchmarking it, unless you know that it’s in a critical hot path.

This long post is demonstrating that Knuth’s advice, “premature optimization is the root of all evil,” is still one of the first heuristics you should apply.

The article describes a couple of straw men and even claims that they’re right in principle:

> Then someone on the team raises an eyebrow. “Isn’t that an extra function call? Indirection has a cost.” Another member quickly nods.

> They’re not wrong in principle.

But they are wrong in principle. There’s no excuse for this sort of misinformation. Anyone perpetuating it, including the blog author, clearly has no computer science education and shouldn’t be listened to, and should probably be sent to a reeducation camp somewhere to learn the basics of their profession.

Perhaps they don’t understand what a compiler does, I don’t know, but whatever it is, they need to be broken down and rebuilt from the ground up.

I'm not sure Rust's `async fn` desugaring (which involves a data structure for the state machine) is inlineable. (To be precise: maybe the desugared function can be inlined, but LLVM isn't allowed to change the data structure, so there may be extra setup costs, duplicate `Waker`s, etc.) It's probably true that there is a performance cost. But I agree with the article's point that it's generally insignificant.

For non-async fns, the article already made this point:

> In release mode, with optimizations enabled, the compiler will often inline small extracted functions automatically. The two versions — inline and extracted — can produce identical assembly.

One non-trivial problem with async in Rust is that it leads to code that allocates on one CPU and free memory on another. That kills a lot of optimizations that system allocators try to do with CPU local caching and harms performance badly especially on fat servers with a lot of CPUs. When one hits this problem, there is no easy solution.

Ideally using an allocator per request would solve this issue, but Rust has no real support for it.

A workaround that works is to stop using async and just use a native thread per request. But then most crates and frameworks these days use async. So indeed async abstraction us very leaky regarding the cost.

> The programmer needs to understand this implementation detail instead of pretending that async functions work the same way as sync functions.

Async is telling the OS "I'll do it myself" to threading and context switches.

Yeah the author makes a really poor example with the async case here.

Async in rust is done via cooperative scheduling. If you call await you enter a potential suspension point. You're willingly telling the scheduler you're done running and giving another task a chance to run. Compound that with something like tokio's work stealing and now you'll possibly have your task migrated to run on a different thread.

If this is in hot path making another call to await is probably the worst thing you can do lol.

The author demonstrates later with a dead simple inlining example that the asm is equivalent. Wonder why he didn't try that with await ;)

I strongly prefer this sort of code:

```

    fn does_a_many_step_process():

         first_step_result_which_is_not_tied_to_details_internal_to_the_step_implementation = well_named_first_step_which_encapsulates_concerns();



        second_step_result_in_same_manner = well_named_second_step_which_encapsulates_concerns();

  ...etc

} ```

The logic of process flow is essentially one kind of information. All the implementation details are another. Step functions should not hide further important steps - they should only hide hairy implementation details that other steps don't need to know about.

One huge one is so that you can test it in isolation.

There's extraction for reuse and then theres extraction for readability/maintainability. The second largely comes down to personal taste. I personally tend to lose the signal in the noise, so it's easy for me to follow the logic if some of the larger bits are pushed into appropriately named functions. Goes to the whole self commenting code thing. I know there's a chunk of code behind that function call, I know it does some work based on its name and args, but I don't have to worry about it in the moment. There's a limit of course, moving a couple lines of code out without good cause is infuriating.

Other people prefer to have big blocks of code together in one place, and that's fine too. It just personally makes it harder for me to track stuff.

People new to Rust sometimes assume every abstraction is free but that's just not the case, especially with lifetimes and dynamic dispatch. Even a small function call can hide allocations or vtable lookups that add up quickly if you're not watching closely.

Did you read the article? The author makes exactly that point.

1. "Indirection" can be logical, or runtime.

2. Please read the blog. That's literally what is said.

The idea is that performance isn’t a reason not to do it. Other considerations may cause you to choose inline, but performance shouldn’t be one of them.

re-use as a criteria for functional decomposability is a very misguided notion

I don't see anything wrong code-wise, but it's definitely an odd way of making an accumulator. Maybe I'm pedantic

Doesn't seem like AI.

This is an incomplete sentence:

> All cases where you are in a CPU intensive blocking task that, if you’re not careful, could starve all the others.