Always love all the Java hate on ycomb. I'm not sure how a dynamically code hotswapping Ruby app with 10k classes and 1k domain objects works, but I suspect many of the same patterns emerge as have been solved in Java.
Large single programs should almost never exist. There are exceptions, but the typical bloated business app is not one of them.
Managerial idiots like overambitious single-program IT projects because it makes it easier to allocate "headcount" when the programmer-to-program relationship is inverted (many programmers to one program, instead of the right way, which is one programmer working on many programs).
The truth is that every programming approach fails you when you do this. For one example, static typing fails on versioning issues and compile-speed problems, while dynamic typing ends up with silent failures and integration bugs.
There is one case I can think of where large single programs work, and that's in the database space. You have a lot of requirements (transactional integrity, concurrency, performance in a heterogeneous world) and they all have to work together. It has also taken decades for some of the brightest technical minds out there to get it right.
Large networks of small programs fail in exactly the same way: static typing fails on versioning issues (an RPC call carries inherently less type information than a function call) and compile-speed problems (compiling 200 small services can take just as long as compiling one behemoth). We also don't have mature tooling for the "network program" you're talking about.
I don't know what your metric of "large program" is, but AAA games often weigh in at 10-100 million lines and are typically architected as a single large codebase with auxiliary small programs, and doing them any other way is not a sensible approach.
WADR, most enterprise billing, invoicing and accounting systems are also such cases where it is not desirable or practical to sprinkle the business logic across dozens of silos.
In languages like ruby, python, and probably to some degree go, you tend not to need as many classes. Things like Factories, Adaptors, and Proxies tend to disappear or become pretty trivial.
Eventually programs written in these languages can grow huge, but it takes longer, and the preference tends to then be to break a program down into smaller libraries (gems, eggs, etc.) and separate applications that communicate with each other.
Managerial idiots like overambitious single-program IT projects because it makes it easier to allocate "headcount" when the programmer-to-program relationship is inverted (many programmers to one program, instead of the right way, which is one programmer working on many programs).
The truth is that every programming approach fails you when you do this. For one example, static typing fails on versioning issues and compile-speed problems, while dynamic typing ends up with silent failures and integration bugs.
There is one case I can think of where large single programs work, and that's in the database space. You have a lot of requirements (transactional integrity, concurrency, performance in a heterogeneous world) and they all have to work together. It has also taken decades for some of the brightest technical minds out there to get it right.