Where concurrency shines

I think that it can almost be stated as a fact that concurrency in languages that weren’t designed with concurrency in mind tends to be poor.  The languages I have in mind here are Python, C, C++ and similar.  I have come across a few people who disagree with this statement however after questioning I have found that they have A) Not done much of anything complex with threads B) Never used a concurrently oriented language.  Needless to say, I don’t take their opinion very seriously.  Now, obviously, you can take the time to write an application that uses threads and works well.  But, with enough time, you can do just about anything, and in the time it takes to make that application one can deffinatly develope an equivalent program faster in concurrent orientated (CO) language.
Because writting decent threaded applications in other languages is so difficult there are a number of frameworks available that try to make it easier to write applications in a single thread.  One of the reasons I think these frameworks will fail in comparison to a language such as Erlang for most developers is the amount of work it takes to integrate other libraries into it.  For anyone that has used a framework such as Twisted, they have probably run into a situation where they have a third party library they want to use however the problem is, it blocks.  For an asynchornous framework this is murder.  So one has two choices.  Either to run the third party library in its own thread.  Obviously this is generally not what we want to do since the whole point of using the framework is to avoid threads.  The other solution is to rewrite the library to integrate it into the frameworks event loop.  Depending on the situation, this might be acceptable but it sure is a pain to have to do extra work to use this library.  Now, a language which supports concurrency does not have this problem so much.  The first solution, of running the library in a thread, works perfectly fine.  You probably have 300 or 400 threads going already so it is no big deal.  This makes it easy to distribute libraries for the particular language.
For a simple example.  Imagine you make a really great http client in python.  You can’t really make a general http client because you need to take into account the various networking frameworks they might be using.  If they are using twisted then it needs to integrate into the twisted event loop to be really useful.  If they are using asyncore it needs to integrate into the asyncore event loop, and so on and so forth.  Now take the same situation in erlang.  Just throw the client in a process and you are all set.  You don’t have to rewrite anything.  The obvious benefit of this is increased development speed.

I think it seems pretty clear that our processors and applications are moving towards more concurrent environments.  Languages that can take advantage of this environment are most likely going to be the ones that make it.  However I’m no fortune teller, so there is a good chance I could be wrong.

I think I tried to put too much into this one post so it might not make sense.  Hopefully I got my ideas across.

Comments

Add comment