OK, to put it another way, looking at the system design as a whole. Now I tried this a long time ago and bought a great big book called "The linux programming interface" but was told that i was wasting my time with that. What I did gather from it is that there are several mechanisms for different programs to communicate (ports/sockets and more). So at what level of complexity do I divide my system up into multiple programs so that each can be written in whatever language best suits that or will the complexity of getting things to talk to each other outweigh the total development unless it is a seriously complicated system?
There is no generic answer, merely a range of possibilities based on the task and your experience.
Having multiple people, or companies, or geographic distribution sometimes indicates sensible boundaries. Those boundaries may, or may not, be boundaries between different languages.
Timing, especially allowable latency between event and response, can indicate boundaries.
Sometimes there is a natural conceptual boundary. For example, given an language neutral comms mechanism, an event could be generated in one language and consumed in another. (Major benefit: also allows easy unit testing upwards and downwards).
Sometimes design concepts are better expressed in one language than another, e.g. complex interacting constraints or statistical processing, or deductive inferencing.
Sometimes it would take longer to reimplement a subset of the application functionality in one language than another.
The application specification is never written in a computer language. Informal English plus domain-specific terminology and concepts is often used. A good design enables those terms and concepts to be directly visible at the top level of the implementation. That tends to push that level to be expressed in a high level language. Where some of the implementation cannot be done in that language, drop to a lower level language for small specific parts of functionality.
So, start by stating non-technical project boundaries, application domain conceptual boundaries, implementation conceptual boundaries, timing boundaries, testability boundaries. Then decide.