I like the Unix model. Lightweight processes with separate memory spaces, with well-defined interfaces between them. Pipes and signals. Message passing if you want to get fancy. Erlang, with its touted high-availability capabilities follows this model.
Threading is hard. I've written thread-oriented code and process-oriented code. The process-oriented code was far easier to develop and debug. Issues in threaded code are difficult to reproduce and even harder to fix.
I've been on both the OS engineering team and the app development team across several corporations. In a large managed Java environment, the OS team is powerless to stop a runaway process. To the OS, all that business logic is enapsulated in one giant opaque container. The kill -9 and fuser ommands are barbaric ways to manage your sensitive computing needs. Unix broke away from the monolithic style of development, but the Enterprise Java culture embraces it. On the other hand, the app development team can live in its own little world, not trusting the OS and reinventing wheel after wheel.
These days it's apparent that Unix has won the OS wars, at least on the server side. With Unix, you can trust your operating system. Take advantage of it. It has amazing reliability and if you can just work with it instead of against it, you reap many benefits.
Now we just need to convince the app developers that the philosophy of "many small tools working together" is superior to the "one giant tool doing everything". You don't want to be a giant tool, do you?
Erlang is super cool, but... to be picky, it does and it doesn't share the Unix model. It does in the sense that you don't share anything between processes. But it doesn't because all those processes live in one real process, which is why spinning them out is so cheap. It's also why you have to be very careful about linking to 3rd party libs in Erlang - all it takes is one blocking call, and poof, everything grinds to a halt. IIRC, one defense mechanism they've developed against this is to actually start app linkages up in separate unix processes and talk to them via sockets.
Strictly speaking, Erlang processes have a type of shared memory -- ets tables -- but the semantics are somewhat different from other languages that use traditional shared memory. However, when you need synchronization, you just use Mnesia transactions, which make working with this kind of shared memory a piece of cake. Also, Mnesia is distributed, a nice attribute that other STM implementations lack.
Java does involve many small tools (JARs), but they all get loaded into one VM process. The issue is not modularity vs. giants but how modularity is implemented.
Threading is hard. I've written thread-oriented code and process-oriented code. The process-oriented code was far easier to develop and debug. Issues in threaded code are difficult to reproduce and even harder to fix.
I've been on both the OS engineering team and the app development team across several corporations. In a large managed Java environment, the OS team is powerless to stop a runaway process. To the OS, all that business logic is enapsulated in one giant opaque container. The kill -9 and fuser ommands are barbaric ways to manage your sensitive computing needs. Unix broke away from the monolithic style of development, but the Enterprise Java culture embraces it. On the other hand, the app development team can live in its own little world, not trusting the OS and reinventing wheel after wheel.
These days it's apparent that Unix has won the OS wars, at least on the server side. With Unix, you can trust your operating system. Take advantage of it. It has amazing reliability and if you can just work with it instead of against it, you reap many benefits.
Now we just need to convince the app developers that the philosophy of "many small tools working together" is superior to the "one giant tool doing everything". You don't want to be a giant tool, do you?