Ah yes to the naysayers...

"These changes were needed as we started work on our next generation renderer, improved internal messaging, switched over to VC.Net..."

VC.Net. Ah when I recall the beatings and essentially flat out insults regarding programming ability and general understanding I took on these boards even suggesting a managed environment like .Net could contribute to the core of something like SL...well, I had to laugh when I read this in the town hall transcript.

Cuz afterall, it's not real programming if you don't suffer while writing it.

VC.NET is not the .NET Framework. It's essentially Visual C++ 7.0, which "can" use the .NET managed framework, but is not used by SL. They are basically using an upgraded version of Visual C++ 6.0 which generates native code for the Intel processor under 32-bit/64-bit Windows.

you can actualy download the VC.Net 2003 compiler free from MS. Currently using it for it's preprocessor to handle ESL -> LSL conversions. But after my current project is finished i plan to write a semi optimised precompiler for ESL (i'll get those lexx files yet).

I really hope they don't use the .NET framework for the new client / rendering engine. I asked Cory about this at the townhall, but he didn't understand the question.

Sure, VC.NET without using the .NET framework should produce fine results.

Use the .NET framework and suddenly your app uses 3-4 times the amount of memory it did 2 seconds ago.

I absolutely knew these replies were incoming.

VC.Net is very much .Net. Yes, it is. How much of the managed extensions are they using? Dunno. But they are available, and I would find it hard to believe they will decide to forever forego them. Otherwise it is a complete waste to switch.

BTW, all .Net code gets compiled to Win32 code. All of it. Whether you do it at design time or at runtime via the CLR JITr, is a matter of configuration.

3-4 times slower, utter complete fiction. I have four guys, all seasoned devs, reading that post right now who are just smiling and shaking their head. Show me an authoritative benchmark that proves this in more than a lopsided test and we'll all quit our jobs. We have all been developing heavily in .Net since the Alpha of the framework, and understand that since it's all compiled cached Win32 in the end, performance is often faster!

I've been an advocate of .Net for a long time, have stuck to my guns, and one after another, the devs are saying, "yeah I guess it really does work, though I hate to admit it".

I didn't say that. I said 3-4 times higher memory usage.

At least, this is the case with anything I've ever seen done in C# and VB.NET. My experience with managed c++ is limited, but from what I remember may not have that problem.

I code c#.net for a living these days. I'm not bashing it... just saying that it uses so freaking much memory for the simplest tasks, and the more .NET framework components that are involved, the higher that amount goes.

Agreed. I write 100% in C# .net and I too see significant increase in resource utilization.

However, I also wouldn't skip C# APIs and go back to barebones programming expect for certain low level programming tasks. Like - maybe writing a VR rendering engine?

In the end though, we all know it isn't even as simple as that. Every particular project generally has an ideal way of approaching it.

And this ideal way, is dependent on many factors: how much time you have, how much money you have, what libraries are available, what your vendor has developed in, what your team skill set is about, what your own skill set is, what particular bugs are present which affect your particular problems, what the politics are ..

Simply saying dot net is slow or dot net is fast is not the right or the wrong answer.

Good point blaze.