"faster apps" - I am glad that you have posted the benchmarks that prove that C++ application written using the most bloated framwork are faster than C# applications. Especially the "faster apps" part is really interesting, and well provoking.
"smaller apps" - .NET applications are usually below 100 KB. I have written several bots that were multi-threaded and an amazing gui. Yet they were around 80 KB. So I don't see what you are trying to say here. Don't even try to say that it's bothersome to install the .NET framework. It even comes pre-installed since Windows 7.
"- easy possibility of multi-platform apps (hitting multiple platforms might be a selling point in a niche)"
It might, or might not. So this can NOT used against C#. But anyway, if you didn't know there is Mono, which allows you cross-platform development.
"If all you need to do is coding little TOYS you probably won't support long-term (like most ppl sell on these boards) to make a quick buck be my guest and go with c# or vb.net: they GET the job done. If you take this route and you value your time though you're probably better off learning ubot, imacros, zenno or any other web automation tools."
Let me aware on you the World of Warcraft bot which was called Glider. It was written in C# and the developer(s) made millions from it. Aware yourself on http://en.wikipedia.org/wiki/Glider_%28bot%29. So this is wrong also. Not to mention that most of the SEO tools are written using the .NET framework and have been selling for years. So please, before you try to bash a language because you prefer your own, don't be an annoying prick. And this comes from a guy who has used C++ for years. Every language has its strong points, and bad points. Every developer should be able to write code in multiple languages, not just one. There is no bad language, only bad developers. Use the right tool, for the right job.
Now just a few points, hoping this will be beneficial to OP. Too many things to do to waste my time in a flame war or to reply to generic statements like "use the right tool for the job". It's not kindergarten.
1. I have made a lot of money out tiny little things written in assembly that I won't discuss here. This doesn't make assembly a good, multi-purpose, easily modifiable, easily maintainable or versatile language let alone prove anything about it. It's a royal PITA, but generates a lot of $ if you know what to do. I would never ever pick assembly to make anything that remotely needs constant upgrades or destined to a wide audience. Your point about making money... being? (OK, sorry that was flamy...
)
2.
Most SEO tools ARE toys from a coding standpoint. I understand that a few rookies that have ventured into sockets with a high-level class might suddenly think they are kevin mitnick or some genius out of MIT, but it's not the case.
3. It's not always a matter of opinions. If you have to drag with you a runtime of hundreds of megabytes, well, that's not a language I might want to consider for a large deployment should I venture into a LARGE commercial project. Sometimes the target will be Win 7 sometimes it won't and I can and very likely will encounter a lot of issues. A simple search JUST on this board is enough, no need to go far.
Various .net frameworks will yield to these problems INEVITABLY there's no need for me to waste my time pointing to links to the .net mess as someone else already stressed. Again too many Windows versions still in circulations to take seriously the Windows 7 remarks you make, not to mention the likely possibility of new incarnations of Windows on different architectures like ARM to work on tables or even MIPS (in China tablets on mips are a REALITY and that might be the future of target IM platforms). Other compatibility problems.
And no, projects like mono -as you probably know- are only partial implementations always lagging, always missing something, with the pInvokes that can't be ported so -as I stated above- you need to code something commercially and being x-platform is a selling point .net -again- is NOT a good choice.
If -again like most, but not all of the tools in IM- can afford to basically say "use an emulator of you can screw yourself" that's fine.
But if you -like OP- are in that stage where you have to decide what to INVEST YOUR LIMITED TIME on well you should put a lot of thought in evaluating carefully all the possible use cases. Again .net is NOT a good choice in this scenario and I repeat that using a UI testing framework like uBot or zenno might end up being a better choice for his time.
4. I'm not even wasting time into why a native binary is generally and for a multi-purpose app faster than any byte-code. But just a few considerations. I've been hearing the same argument from some nutjobs 10 years ago and for too many years. Then poof, a benchmark here, one there... Ends up that an entire bytecode app was always slower than a native c++ app for some reason... I wonder why Google didn't write chrome in c# if speed is comparable or mozilla for firefox, or even Microsoft with IE since they had to rewrite their core rendering engine... I'm not saying the kernel, nosssssir, just the rendering engine. Wouldn't that be sort of comparable to any IM app after all?
You know why they didn't do that even with their own .net technology? Because any non-native language is SLOWER in a real environment.
5. Someone asked if there's an opensource rendering engine that can be manipulated with c++. Webkit is totally scriptable (bindings for a lot of stuff too) on QT and it's opensource. Natively with QT you can do what you can do with WinForms. Differently from .net you don't need to carry with you 200MB of runtime that only works on some god chosen machines to make "your 80kb" app work with the "beautiful interface" (god, not even at MS they would dream to make such a pitch for .net lol)...
Just a few DLLs or you can even compile it statically, if you want. And on each platform you target you'll end up with a quasi-native interface with a FAST native binary.
P.S. Delphi is cool and most components can be reused in C Builder almost verbatim.
