Lately, I've been seeing heated debates between .NET supporters and opponents on popular tech forums. These arguments typically begin with a misunderstanding and end in vicious trolling, arguments about life, and comparisons of the radii and specific densities of various spherical cones. Both sides strive to prove and argue, but neither is willing to look at the subject matter with a new perspective. Habrahabr is no exception, unfortunately.
The intensity of such discussions would be the envy of religious fanatics. The only thing that saves these opponents from attacking each other with pitchforks and LangSpecs is the internet.
This is no way to live, gentlemen. I wanted to rectify this situation and take a stand for one side or the other. With this post, I will attempt to do irreparable good to the community and address the myths that, unfortunately, consume the debaters' energy, not their mutual self-harm, debating them. And since I once migrated from C++ to C# and everything around it, I'll be debunking negative myths, adding positivity, and embellishing reality in every possible way—of course, that's all there is to it. And—note—it will be completely free for M$. And I want to do it in a Q&A format.
#. C# and the CLR are a kind of VM, i.e., an interpreter, and therefore very slow and sad. I need it to be fast, very fast!
I won't go into the difference between compilation and interpretation here. I just want to point out this: gentlemen, a recent survey on Habrahabr showed that most developers, in one way or another, use "managed" languages, which are compiled not to native code, but to bytecodes executed by interpreters—either direct or compiler-based. TraceMonkey, LuaJIT, and YARV are examples of the latter classification. This means that switching to another platform with a similar architecture will certainly not make the application slower. In this sense, there's nothing to worry about.
However, the CLR is a sort of virtual machine, not an interpreter. I repeat: MS.NET IS NOT A BYTECODE INTERPRETER. A special JIT compiler gradually converts a program's bytecode into native code, roughly the same as that produced by a C++ compiler. Current CLR implementations—MS.NET and Mono—guarantee that ANY code executed is converted to native code. For desktops, the claim is even stronger: any code will be compiled only once. Moreover, the fact that it is compiled "on the fly" theoretically allows for more optimal use of the specific processor's features, which means greater code optimization.
Furthermore, comparing absolute benchmark results shows that the CLR is orders of magnitude more efficient than popular scripting languages like JavaScript and Ruby, which also use JIT technology.
#. Languages with garbage collection lag behind languages like C++ in speed.
True, you're pretty close to the truth here. But, like any holy war monger, you're not telling the whole story. The correct phrase would be: "A correctly written and entirely manually optimized native application without errors, using special memory management techniques, will be faster than an application with automatic garbage collection."
But for more or less serious software, creating such an application requires a huge amount of effort. Significantly exceeding that required for a managed language.
This is precisely why high-level languages were invented—in the long run, on average, the code emitted by the compiler will contain fewer errors and run faster than hand-written code.
And yes, the stupid numbers don't lie: memory allocation in languages with garbage collection is FASTER and _doesn't_ fragment the heap, unlike C++. Exception handling in managed languages is also faster.
And then there's the time factor and the cost of development, including the number of errors. Because a memory corruption or leaked memory error... hmm... when was the last time I saw one in the CLR? At least 10 years ago.
#. CLR programs eat up a lot of memory. They literally eat up everything, leaving nothing behind...
Hmm. A comparable, heavily loaded Ruby-on-Rails application on the server eats up 100-150MB of RAM, about the same as an ASP.NET CLR site. There's not much difference there.
Of course, for small scripting tasks, Ruby is much more efficient. But this isn't about scripting tasks—in real-life projects that generate revenue, the CLR's appetite seems commensurate with other technologies, and I can't agree with the definition of "eating a lot."
#. Okay, okay, GC is good. But the garbage collector is a very capricious beast; it has a huge number of settings. No one can set them correctly—manual intervention only does harm. The GC in my ZZZ works just fine! By itself!
By the way, the CLR has one of the best garbage collectors today. Its first version was written in LISP to more clearly express the semantics of relationships between objects in memory and to perform automatic analysis of the algorithm's correctness, and then rewritten in C++. Much time has passed since then, GC has been tested by millions of developers and an equal number of projects. It doesn't leak, no matter what you do!
The configuration is configured through a single key in the configuration file: gcServer=”true/false”. It enables parallel garbage collection, as well as other optimizations. By default, it's set to false so as not to interfere with the interactive UI mode (GC operation is invisible to the UI) on single-processor machines. CLR 4.0 introduced new settings, but the essence is the same: it works great out of the box, put your pliers away.
#. And my favorite language, ZZZ, has FFI , so I can write extensions to it in C if I need speed. Admittedly, I've never written one, but so what! I can! What about CLR/C#? Should I rewrite everything in a managed language?
I'm very happy for ZZZ. You'll be surprised, but CLR also has the ability to call functions from native DLLs written in good old C. And, of course, pass data there and receive it back. Moreover, unlike most FFIs, you don't need to design the DLL for FFIs—use calling conventions and special data types. CLR is omnivorous; it can be flexibly configured to consume almost any library. COM support is separately enabled and automated for more convenient access to Windows capabilities.
This is called Interop/Platform Invoke
#. Okay, I can write a lot in C. But I'm not going to write everything myself! .NET lacks the necessary libraries; and to work with a database, you need to buy MSSQL for a hundred thousand million dollars!
You don't need to write everything. .NET has an excellent stdlib, called BCL (Base Class Library). It has a lot of what you need: files, sockets/network, http and web, regular expressions, SQL and data manipulation, xml and web services, etc.
If you need something that's not in the BCL, it most likely already exists. Or you can use a native library—that's how wrappers for OpenGL and OpenAL, bass.dll (sound), and much more are made.
Providers for MySQL and Oracle, SQLite, and PostgresQL have been written for .NET; they're stable and work great. And what's more, there's MongoDB and its own object databases, and there's a client for Memcache and RabbitMQ. There are also ServiceBus and MessageQueue, and writing APIs for existing systems is very simple.
You can only write for the CLR in Visual Studio. And only for Windows. Both of those cost money.
Not true. There's SharpDevelop , which is quite good for a free environment; there's MonoDevelop , which is also good and runs on both Windows and *nix. There are Eclipse plugins ; by the way, with IKVM.NET, you don't need Java to run Eclipse; the CLR alone is enough.
The lightweight version of Visual Studio Express allows you to create full-fledged applications in Windows. The free MS SQL Express will last a long time for most projects.
There are tools for debugging, profiling, and setting up Continuous Integration processes, all written in .NET. There are also tools like make/ant, NAnt , and msbuild.
Download and Install!
#. The CLR's place is on the server. And Mono is a terrible, unusable, and unreliable nastiness that hasn't grown out of diapers. MiguelDeIcaza's Labs ©.
Exactly. On the application server and on the web server, the CLR has its own Rails (ASP.NET MVC), its own Hibernate , and dozens of other ORMs. It's suitable for everything. Well, is that scary? We're all gradually moving to the web.
On the other hand, the creators of Unity3D disagree with you. It's a player that hosts the CLR environment right in your browser, and the scripts for it are written in .NET languages. Very fast and beautiful. 3D is already here. No need to wait for Flash Player with GPU support.
By the way, have you heard that Mono apps compile for iPhone and iPad (#MonoTouch)? And Unity3D can do this too.
#. Using the CLR forces me to switch to C#; I don't want to learn it!
And there's absolutely no need. Yes, C# has the most comprehensive access to all the CLR features, but no one is forcing me to use it. The CLR is not just C#; it is an excellent platform and the BCL, providing a high-quality object model and tools. There are a huge number of languages—new ones, such as Boo, Nemerle, F#, or previously known ones: Delphi, Ada, Lisp, VB, PHP—that use the CLR as a backend.
From this point of view, the CLR is similar to LLVM—it provides low-level services, such as IL (bytecode) and JIT, garbage collection, an object model, a common type system, a standard library, a security system, etc.
#. C# is a hoary enterprise language, stuck in the last century, while my language packs in new features every six months!
Yes, C# has firmly established itself in the low-cost enterprise sector thanks to its characteristics: it's easy to write, its static typing and managed environment eliminate a whole class of errors inherent in scripting languages or lower-level languages, the IDE provides access to all the necessary tools in a couple of clicks, documentation is built right into the IDE, and IntelliSense is top-notch.
Thanks to this, C#/CLR solutions are less expensive than Java ones.
C# maintains backward compatibility, but this doesn't prevent new features from being added to the language. There are already parametric polymorphism (that's when Vector is used), lambda functions, and closures. LINQ (Language-integrated queries) based on limited quoting are available for the first time in any language, type inference is present, and a whole layer of the DLR has appeared. Version 5.0 introduces built-in support for asynchronous programming.
CLR/C# isn't as bad as you think, and it's easy to check. But if C# isn't enough for you, there's F# (a port of Caml) and Nemerle (a hybrid of C# and a functional language), there's even CLR C++—take what you need from both worlds and combine them.
#. Oh, aloe, I just remembered something. What cross-platform are we talking about when I have to recompile everything to run it under Mono. It's just like good old C, how is that any better?!
More nonsense. I don't know who told you this, but in general, a fully managed CLR application compiled on Windows DOESN'T NEED TO BE RECOMPILED. You can SIMPLY port it to Linux with Mono installed, run mono myapp.exe, and it will run. The opposite works too. I've checked.
However, this is where linking with libraries comes into play. It's like gems in Ruby—if a specific gem uses native libraries, you need to install those native libraries. But in general, there are plenty of pure Ruby gems.
No magic, really.
#. .NET applications use the registry. Again, the headache of managing software versions, installing and uninstalling programs?
Nope. All managed .NET applications can be distributed using the deploy-by-copy model—copy them to the desired folder and run them from there. They don't access the registry or system folders.
If you want to use a shared managed library, a special mechanism called GAC (Global Assembly Cache), using cryptography, will ensure there's no duplication and that the library you need is the exact one and the exact version you're expecting.
#. But my programmer friends... They said that the Visual Studio IDE and C# developer kit includes a mandatory rectal vibrating probe and instructions for its continuous use!
OMFG
! I declare with absolute responsibility: your programmer friends were deceived. I would recommend you go and help them stop wearing this self-proclaimed probe, but I'm afraid they've already gotten a taste for it and won't be able to... But MS and the CLR have nothing to do with it, right?
Conclusions:
Of course, anyone can object to me. I'd be glad if anyone wants to correct me, add to my thoughts, or perhaps even refute them.
Overall, I've explained the situation, which, I hope, has done a lot of good to my colleagues in the CLR field. I hope now there won't be any stupid questions like "why C# when you have Python, and with it, GC."
Whether you choose this path in life or not is your choice. Nothing prevents you from combining the two. I write in .NET for food and Ruby for the soul.
The intensity of such discussions would be the envy of religious fanatics. The only thing that saves these opponents from attacking each other with pitchforks and LangSpecs is the internet.
This is no way to live, gentlemen. I wanted to rectify this situation and take a stand for one side or the other. With this post, I will attempt to do irreparable good to the community and address the myths that, unfortunately, consume the debaters' energy, not their mutual self-harm, debating them. And since I once migrated from C++ to C# and everything around it, I'll be debunking negative myths, adding positivity, and embellishing reality in every possible way—of course, that's all there is to it. And—note—it will be completely free for M$. And I want to do it in a Q&A format.
#. C# and the CLR are a kind of VM, i.e., an interpreter, and therefore very slow and sad. I need it to be fast, very fast!
I won't go into the difference between compilation and interpretation here. I just want to point out this: gentlemen, a recent survey on Habrahabr showed that most developers, in one way or another, use "managed" languages, which are compiled not to native code, but to bytecodes executed by interpreters—either direct or compiler-based. TraceMonkey, LuaJIT, and YARV are examples of the latter classification. This means that switching to another platform with a similar architecture will certainly not make the application slower. In this sense, there's nothing to worry about.
However, the CLR is a sort of virtual machine, not an interpreter. I repeat: MS.NET IS NOT A BYTECODE INTERPRETER. A special JIT compiler gradually converts a program's bytecode into native code, roughly the same as that produced by a C++ compiler. Current CLR implementations—MS.NET and Mono—guarantee that ANY code executed is converted to native code. For desktops, the claim is even stronger: any code will be compiled only once. Moreover, the fact that it is compiled "on the fly" theoretically allows for more optimal use of the specific processor's features, which means greater code optimization.
Furthermore, comparing absolute benchmark results shows that the CLR is orders of magnitude more efficient than popular scripting languages like JavaScript and Ruby, which also use JIT technology.
#. Languages with garbage collection lag behind languages like C++ in speed.
True, you're pretty close to the truth here. But, like any holy war monger, you're not telling the whole story. The correct phrase would be: "A correctly written and entirely manually optimized native application without errors, using special memory management techniques, will be faster than an application with automatic garbage collection."
But for more or less serious software, creating such an application requires a huge amount of effort. Significantly exceeding that required for a managed language.
This is precisely why high-level languages were invented—in the long run, on average, the code emitted by the compiler will contain fewer errors and run faster than hand-written code.
And yes, the stupid numbers don't lie: memory allocation in languages with garbage collection is FASTER and _doesn't_ fragment the heap, unlike C++. Exception handling in managed languages is also faster.
And then there's the time factor and the cost of development, including the number of errors. Because a memory corruption or leaked memory error... hmm... when was the last time I saw one in the CLR? At least 10 years ago.
#. CLR programs eat up a lot of memory. They literally eat up everything, leaving nothing behind...
Hmm. A comparable, heavily loaded Ruby-on-Rails application on the server eats up 100-150MB of RAM, about the same as an ASP.NET CLR site. There's not much difference there.
Of course, for small scripting tasks, Ruby is much more efficient. But this isn't about scripting tasks—in real-life projects that generate revenue, the CLR's appetite seems commensurate with other technologies, and I can't agree with the definition of "eating a lot."
#. Okay, okay, GC is good. But the garbage collector is a very capricious beast; it has a huge number of settings. No one can set them correctly—manual intervention only does harm. The GC in my ZZZ works just fine! By itself!
By the way, the CLR has one of the best garbage collectors today. Its first version was written in LISP to more clearly express the semantics of relationships between objects in memory and to perform automatic analysis of the algorithm's correctness, and then rewritten in C++. Much time has passed since then, GC has been tested by millions of developers and an equal number of projects. It doesn't leak, no matter what you do!
The configuration is configured through a single key in the configuration file: gcServer=”true/false”. It enables parallel garbage collection, as well as other optimizations. By default, it's set to false so as not to interfere with the interactive UI mode (GC operation is invisible to the UI) on single-processor machines. CLR 4.0 introduced new settings, but the essence is the same: it works great out of the box, put your pliers away.
#. And my favorite language, ZZZ, has FFI , so I can write extensions to it in C if I need speed. Admittedly, I've never written one, but so what! I can! What about CLR/C#? Should I rewrite everything in a managed language?
I'm very happy for ZZZ. You'll be surprised, but CLR also has the ability to call functions from native DLLs written in good old C. And, of course, pass data there and receive it back. Moreover, unlike most FFIs, you don't need to design the DLL for FFIs—use calling conventions and special data types. CLR is omnivorous; it can be flexibly configured to consume almost any library. COM support is separately enabled and automated for more convenient access to Windows capabilities.
This is called Interop/Platform Invoke
#. Okay, I can write a lot in C. But I'm not going to write everything myself! .NET lacks the necessary libraries; and to work with a database, you need to buy MSSQL for a hundred thousand million dollars!
You don't need to write everything. .NET has an excellent stdlib, called BCL (Base Class Library). It has a lot of what you need: files, sockets/network, http and web, regular expressions, SQL and data manipulation, xml and web services, etc.
If you need something that's not in the BCL, it most likely already exists. Or you can use a native library—that's how wrappers for OpenGL and OpenAL, bass.dll (sound), and much more are made.
Providers for MySQL and Oracle, SQLite, and PostgresQL have been written for .NET; they're stable and work great. And what's more, there's MongoDB and its own object databases, and there's a client for Memcache and RabbitMQ. There are also ServiceBus and MessageQueue, and writing APIs for existing systems is very simple.
You can only write for the CLR in Visual Studio. And only for Windows. Both of those cost money.
Not true. There's SharpDevelop , which is quite good for a free environment; there's MonoDevelop , which is also good and runs on both Windows and *nix. There are Eclipse plugins ; by the way, with IKVM.NET, you don't need Java to run Eclipse; the CLR alone is enough.
The lightweight version of Visual Studio Express allows you to create full-fledged applications in Windows. The free MS SQL Express will last a long time for most projects.
There are tools for debugging, profiling, and setting up Continuous Integration processes, all written in .NET. There are also tools like make/ant, NAnt , and msbuild.
Download and Install!
#. The CLR's place is on the server. And Mono is a terrible, unusable, and unreliable nastiness that hasn't grown out of diapers. MiguelDeIcaza's Labs ©.
Exactly. On the application server and on the web server, the CLR has its own Rails (ASP.NET MVC), its own Hibernate , and dozens of other ORMs. It's suitable for everything. Well, is that scary? We're all gradually moving to the web.
On the other hand, the creators of Unity3D disagree with you. It's a player that hosts the CLR environment right in your browser, and the scripts for it are written in .NET languages. Very fast and beautiful. 3D is already here. No need to wait for Flash Player with GPU support.
By the way, have you heard that Mono apps compile for iPhone and iPad (#MonoTouch)? And Unity3D can do this too.
#. Using the CLR forces me to switch to C#; I don't want to learn it!
And there's absolutely no need. Yes, C# has the most comprehensive access to all the CLR features, but no one is forcing me to use it. The CLR is not just C#; it is an excellent platform and the BCL, providing a high-quality object model and tools. There are a huge number of languages—new ones, such as Boo, Nemerle, F#, or previously known ones: Delphi, Ada, Lisp, VB, PHP—that use the CLR as a backend.
From this point of view, the CLR is similar to LLVM—it provides low-level services, such as IL (bytecode) and JIT, garbage collection, an object model, a common type system, a standard library, a security system, etc.
#. C# is a hoary enterprise language, stuck in the last century, while my language packs in new features every six months!
Yes, C# has firmly established itself in the low-cost enterprise sector thanks to its characteristics: it's easy to write, its static typing and managed environment eliminate a whole class of errors inherent in scripting languages or lower-level languages, the IDE provides access to all the necessary tools in a couple of clicks, documentation is built right into the IDE, and IntelliSense is top-notch.
Thanks to this, C#/CLR solutions are less expensive than Java ones.
C# maintains backward compatibility, but this doesn't prevent new features from being added to the language. There are already parametric polymorphism (that's when Vector is used), lambda functions, and closures. LINQ (Language-integrated queries) based on limited quoting are available for the first time in any language, type inference is present, and a whole layer of the DLR has appeared. Version 5.0 introduces built-in support for asynchronous programming.
CLR/C# isn't as bad as you think, and it's easy to check. But if C# isn't enough for you, there's F# (a port of Caml) and Nemerle (a hybrid of C# and a functional language), there's even CLR C++—take what you need from both worlds and combine them.
#. Oh, aloe, I just remembered something. What cross-platform are we talking about when I have to recompile everything to run it under Mono. It's just like good old C, how is that any better?!
More nonsense. I don't know who told you this, but in general, a fully managed CLR application compiled on Windows DOESN'T NEED TO BE RECOMPILED. You can SIMPLY port it to Linux with Mono installed, run mono myapp.exe, and it will run. The opposite works too. I've checked.
However, this is where linking with libraries comes into play. It's like gems in Ruby—if a specific gem uses native libraries, you need to install those native libraries. But in general, there are plenty of pure Ruby gems.
No magic, really.
#. .NET applications use the registry. Again, the headache of managing software versions, installing and uninstalling programs?
Nope. All managed .NET applications can be distributed using the deploy-by-copy model—copy them to the desired folder and run them from there. They don't access the registry or system folders.
If you want to use a shared managed library, a special mechanism called GAC (Global Assembly Cache), using cryptography, will ensure there's no duplication and that the library you need is the exact one and the exact version you're expecting.
#. But my programmer friends... They said that the Visual Studio IDE and C# developer kit includes a mandatory rectal vibrating probe and instructions for its continuous use!
OMFG
! I declare with absolute responsibility: your programmer friends were deceived. I would recommend you go and help them stop wearing this self-proclaimed probe, but I'm afraid they've already gotten a taste for it and won't be able to... But MS and the CLR have nothing to do with it, right?Conclusions:
Of course, anyone can object to me. I'd be glad if anyone wants to correct me, add to my thoughts, or perhaps even refute them.
Overall, I've explained the situation, which, I hope, has done a lot of good to my colleagues in the CLR field. I hope now there won't be any stupid questions like "why C# when you have Python, and with it, GC."
Whether you choose this path in life or not is your choice. Nothing prevents you from combining the two. I write in .NET for food and Ruby for the soul.
