Back around 1980, I took a seminar class in discrete-event simulation from Nick Lawrence, who used to be THE discrete-event simulation wizard at Texas Instruments. He had saved them many millions of dollars, at a time when a million dollars was still real money.
Nick hammered us on two things, over and over and over again.
The first was purpose. What do you want to know? Why are you doing this simulation? What do you hope to learn, what question(s) do you want answered? If your simulation is not set up to answer those questions, or if it is hardwired to answer them a certain way, you are at best fooling yourself, and you may be harming yourself or your customers, very badly.
The second was validation. How do you show that your simulation is in fact accurately simulating what you want to simulate? If your sim is not quite correct, you WILL get wrong answers.
The classic example of validation failure is the TTAPS "Nuclear Winter" study. The sim designers validated their sim against Martian data, forgetting that Earth, unlike Mars, had oceans, and shorelines, and lake-effect snow. After they'd published, someone re-did the sim with those effects figured in, and discovered that lake-effect snow scavenged the dust out of the atmosphere in about one year. (Something similar happened in 1800-And-Froze-To-Death, The Year With No Summer.)
What I'm driving at is this: Until you can say what you want to learn, and how you plan to validate your sim, choice of programming language is NOT what you should be thinking about.
There's a third point that should be raised, that of scalability. Until you can simulate your system with a handful of nodes, CORRECTLY, and get the answers you need on the small model, there's no point in trying to simulate thousands of nodes.