We are moving towards having more and more managed programming languages. A lot of software companies are praising these types of languages through the roof, while there is a great downside of simplifying computer languages. By simplifying and making programming languages managed, I would say they are moving towards becoming an over-managed computer language.

Computer languages like C and C++ are native or unmanaged programming languages. They gets compiled to native assembly code and you need to take care of the memory handling yourself. However, managed code like Java or C# are languages where you do not need to write any extra code for memory handling. Of course this is great because we do not have to remember calling delete on our objects all the time. However, there is huge downside. If a person decides to learn for example C# by himself, he often does not need to know anything about memory handling in order to write code. However, this could have a dramatic affect on the code written, since the developer has no clue what a garbage collector is or how it allocates memory. Of course this does not mean much if he makes a simple form-application, however, making for example a multiplayer game, this could have a large affect on the scalabillity of the system. 

Many unexperienced server coders believes the socket decides a large part of the server application performance behavior. On one side they are right, however, it is the overall performance which counts. Yet the socket is a part which many does not get how to use right and then "kills" the performance of the server applications. 

Blocking vs. non-blocking

The largest and most critical point when it comes to socket is determined if you chose blocking or non-blocking sockets. (Often referred to as non-async and async) A blocking send function means that the send function will have to wait for the data it sends to be sent before it is done calling the method. When it is a non-blocking, it means the send function is queued to the .NET thread pool, and when the data has been sent, it calls a callback method. A good example is a server application which is designed to hold tens of thousands of connections and respond to requests. If we had to use blocking methods, we would have to create one thread per individual connection which later on would not make the server application really scaleable. On the other hand, if we used non-blocking methods, no extra threads would have to be created since the .NET thread pool takes care of that for us. In addition to this, we would not have to wait for data to be received on each individual thread since callback objects takes care of that.