4 ms·

Don't use a language that doesn't provide you with the tools to handle it? I don't have many issues with concurrent code in Clojure, or C#, or Go. But in pre-

• jbooth 12y ago
  java.util.concurrent has been around since java 1.5
• ArkyBeagle 12y ago
  Ignoring issues like potential non-reentrance of code and other library issues, C++ is perfectly capable of being used to make programs that use pthreads. It's not a bad time at all... Python apparently has threading and I've seen "from miltiprocessing import.." in Python before. Tcl also has threads, or you can just write things to be event driven. I have never used Tcl to implement a multiprocessor solution, but others have. Because sockets are a first-class object in Tcl, that approach is quite fruitful. I use something you could roughly call "coroutines over a network" daily in Tcl.
• deeviant 12y ago
  A huge portion of my concurrent programming experience in the C-realm(not C++, C), and I spent very little time battling the language. I really don't think the language is the biggest aspect to concurrent programming, although it can certainly affect the calculus of level-of-effort. To be honest, and this may just be that I'm somewhat of a C-centric developer, glib gave me everything I needed for concurrent programming, including the development of a massive, successful and fully concurrent power plant SCADA system.