Mono 2.11 Release Brings Many Changes

[BlackStar]

What he didn't say is why it takes so long to implement in C++.

Ciplogic covered this better than I could myself.
- GC by default, manual memory management only if necessary
- Proper ABI (modularization)
- Better standard library (XML, sockets, globalization, timers, threads, processes, math)
- More expressive syntax (linq, lambdas, generic constraints, enumerators, delegates, interfaces, strong enums)
- Less undefined behavior (e.g. primitive sizes, sign expansion, mod with negative numbers)
- Faster compilation times, shorter debugging cycles
- Reflection and runtime code generation

On its own, each feature might not be too impressive, but add them together and they make a very tangible difference. I would say that I can write C# code 30-50% faster than C++, on average.

Boost tries to solve some of these problems and bring some form of sanity to the language - if you are ok with adding 500MB worth of dependencies to your project. C++1x is much better, but still fails to fix the core issue of C++: its insane compilation system ("write everything twice", "recompile templates on every use", "each compiler has its own ABI, so you can't use .so files - unless you write everything three times", "each platform has different conventions, exact behavior is undefined, have fun".)

What all this amounts to, is that if I can finish my C# project 30% faster than C++, then I can use this extra time to identify and optimize the real bottlenecks (I/O, core algorithms.) The language is rarely the performance bottleneck nowadays. Disk accesses, high-level logic and data layout is where the real optimization potential lies.

[Ansla]

Boost tries to solve some of these problems and bring some form of sanity to the language - if you are ok with adding 500MB worth of dependencies to your project.

Where did you come up with that? Do you mean the debug symbols? I don't think you can really call those dependencies. Otherwise, boost 1.46 on AMD64 is a whooping 6.4MB dependency, 13MB if you count both mt and non-mt versions. Compare this with ~100MB for mono or a lot more for Microsoft's .net

du -shc /usr/lib/libboost_*mt-1_46.so.1.46.1
88K     /usr/lib/libboost_date_time-mt-1_46.so.1.46.1
140K    /usr/lib/libboost_filesystem-mt-1_46.so.1.46.1
364K    /usr/lib/libboost_graph-mt-1_46.so.1.46.1
112K    /usr/lib/libboost_iostreams-mt-1_46.so.1.46.1
112K    /usr/lib/libboost_math_c99-mt-1_46.so.1.46.1
112K    /usr/lib/libboost_math_c99f-mt-1_46.so.1.46.1
112K    /usr/lib/libboost_math_c99l-mt-1_46.so.1.46.1
224K    /usr/lib/libboost_math_tr1-mt-1_46.so.1.46.1
252K    /usr/lib/libboost_math_tr1f-mt-1_46.so.1.46.1
224K    /usr/lib/libboost_math_tr1l-mt-1_46.so.1.46.1
72K     /usr/lib/libboost_prg_exec_monitor-mt-1_46.so.1.46.1
460K    /usr/lib/libboost_program_options-mt-1_46.so.1.46.1
16K     /usr/lib/libboost_random-mt-1_46.so.1.46.1
949K    /usr/lib/libboost_regex-mt-1_46.so.1.46.1
477K    /usr/lib/libboost_serialization-mt-1_46.so.1.46.1
88K     /usr/lib/libboost_signals-mt-1_46.so.1.46.1
16K     /usr/lib/libboost_system-mt-1_46.so.1.46.1
116K    /usr/lib/libboost_thread-mt-1_46.so.1.46.1
805K    /usr/lib/libboost_unit_test_framework-mt-1_46.so.1.46.1
1.4M    /usr/lib/libboost_wave-mt-1_46.so.1.46.1
344K    /usr/lib/libboost_wserialization-mt-1_46.so.1.46.1
6.4M    total

I can give you that C# allows for somewhat faster development for small projects, but don't try to claim it requires less resources, be it CPU, RAM or disk space. That's just ridiculous.

C++1x is much better, but still fails to fix the core issue of C++: its insane compilation system ("write everything twice", "recompile templates on every use", "each compiler has its own ABI, so you can't use .so files - unless you write everything three times", "each platform has different conventions, exact behavior is undefined, have fun".)

I'm not sure I understand what you mean by writing everything twice or 3 times, or where the compiler ABI comes into play. At least gcc did not break it's C++ ABI since version 3.4 that was released in 2004.

P.S.

- GC by default, manual memory management only if necessary

By manual memory management you mean mixing managed and unmanaged code? Because when you start doing that about all the "sanity" of C# vanishes. And I have yet to see a large C# project that does not require unmanaged code.

[ciplogic]

And I have yet to see a large C# project that does not require unmanaged code.

Just to see, I think you just need to look just a little.
SharpDevelop, its compressed source is 37MB (37224 KB). Check here and download the source of version 4.2. It has support from Syntax Highlighter, to code analysis, to multi-language IDE, and so on. MonoDevelop is the same.
Pinta is just 1.5 MB compressed source (and are not so many pictures inside it), and as I know the source code, I don't know any native code inside it.

In Java, the list is huge too (if us about unamanaged), and as C# is very close to Java, at least on matter of language semantics, shows that can be done with C# (at least as matter of possibility). As for Java big systems, Eclipse, Idea and NetBeans come to mind, but are a lot other, but they are more server-side.

Mono class libraries are mostly written in C# (I don't know if are fully written in it), so applications don't need to write the same logic twice, so their logic can be smaller (hence, their binary can be smaller too), at the end providing a richer experience than some other same-sized native language platforms.

[ciplogic]

By manual memory management you mean mixing managed and unmanaged code?

He means: Pointer arithmetic. You can do it using unsafe code (which is a "free to shot yourself" set of C#). Also he may mean IDisposable, where you can write your code to free predictable your code by having:

using (var instance = new MyType()) { 
} //guaranteed to be called instance.Dispose() that you may override