Credo is a great tool, which performs many of the functionality you’d use Rubocop for in Ruby-land.
The nice thing about it, is that there are many style-related issues it hints at by looking at what you (and other contributors to the project!) do: If everywhere you use two spaces for indentation but here you use four, then it will warn you about it. But if you use four everywhere, and use two spaces at one place, then you’ll be warned about that line instead.

As for checking for function size: Credo checks at least for cyclomatic complexity (source), which is a matric that is slightly more sophisticated than lines-of-code for a function.

That’s why I think it’s an interesting part of the conversation

I don’t believe Ousterhout is against having (e.g.) small methods. However, he is saying that if you’re going to introduce a new method/class, make sure it will be reducing the overall complexity of the system or that change will be a net loss.

In other words, he advocates making things modular as a way to reduce complexity in our software designs, instead of as a goal in itself. One of his reasons to not blindly follow “functions can only have X lines”-type rules is that by doing so without critical thinking you’re just exchanging complexity within the method (assuming shorter methods are simpler to understand) with complexity in a higher level (because now you need to know a new function signature, a possibly how it is implemented). Kind of like what Rich Hickey means when talking about “guard rail programming” (about 16 mins in): adhering to these rules doesn’t absolve you of thinking about how best to design your software. I.e. your software can still be poorly designed even if you’ve religiously followed all “rules”.

Fundamentally, one of Ousterhout’s points is that if to understand what a function is doing you need to look at the implementation of the functions it calls, you may want to reevaluate splitting out those functions. Because if you need to know about the implementation of sub-functions to understand the main function, you’re not abstracting away anything at all: you’re just adding extra steps to understanding the code (via jumping around to sub-function definitions). In those cases, he says, it might be better to have (some of) those functions inline within the main function, so that everything you need to understand what’s happening is available where it needs to be understood (with the relevant context).

I think the only thing that works reliably is manual code review. Tools that check function length tend to become an obstacle to work around without actually improving the code.

I agree that generally the number of lines should be short but there are use cases where it makes more sense to have longer functions than splitting it up into multiple pieces. In my experience a developer struggling with writing functional code generally will not make the right decisions to make a function shorter and need help to get into the right way of thinking.