What if there was a NEW vb6

[Tanner_H]

As an additional comment, I would say that at present, the "killer feature" for C# is .NET native. The performance gains alone would convince me to switch any existing Vb.NET projects over (assuming the project were performance-sensitive, of course).

[szlamany]

As an additional comment, I would say that at present, the "killer feature" for C# is .NET native. The performance gains alone would convince me to switch any existing Vb.NET projects over (assuming the project were performance-sensitive, of course).

I guess if I was ever going to write .Net desktop apps again that feature would matter.

As for it being a de facto cause to migrate...

.Net has other factors that slow it down - not just IL. Based on what you are doing, the GC might be evil to you.

I'm not sure the web method I have in VB.Net would benefit from this feature - building huge JSON strings with StringBuilder is probably all taken up doing just that work.

I am all for C as a better syntax for the business and professional reasons you mention. I would never tell a new coder to go the BASIC path over C syntax - that argument has no support.

But that doesn't turn into a mass exodus to C.

[edit] just playing devils advocate - I personally believe you should have a slew of language choices in your tool belt [/edit]

[Tanner_H]

I guess if I was ever going to write .Net desktop apps again that feature would matter.

As for it being a de facto cause to migrate...

.Net has other factors that slow it down - not just IL. Based on what you are doing, the GC might be evil to you.

Yeah, no disagreement here. But just like multiple languages in your programming toolbox, I'd say that understanding GC behavior is just part of being a modern developer. (Short of C/C++, most relevant languages - Java, Javascript, etc - are all GC.)

I was never trying to say that all VB.Net devs should migrate to C#, per se. Just that - in my experience - most VB.Net devs use VB.Net for the same reason a lot of VB6 guys use VB6: maintaining legacy codebases.

For new projects, I think it's difficult to make a case for any variation of VB, unless you just *really* love the syntax. (But obviously, if someone insists on writing new code in VB, .Net is going to be the right choice 99% of the time.)

[Carlos Rocha]

As an additional comment, I would say that at present, the "killer feature" for C# is .NET native. The performance gains alone would convince me to switch any existing Vb.NET projects over (assuming the project were performance-sensitive, of course).

It's only for Windows Store?

[Tanner_H]

It's only for Windows Store?

For now. From the FAQ:

Desktop apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.

It's hard to overstate how cool this could be if it actually works as promised, e.g. from the FAQ:

Is this just about performance, or does this also allow for building C# code (say) that is natively compiled to Win32/64 and doesn’t require an install of the .NET Framework on the target machine?

That is correct: .NET Native is not just about performance, but also about productivity and a consistent device experience. .NET Native allows you to write code using managed languages and upload MSIL packages as always. However, apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine.

[szlamany]

It's hard to overstate how cool this could be if it actually works as promised, e.g. from the FAQ:

Does using .Net native mean that people no longer have to worry about obfuscating their applications?

[Tanner_H]

Does using .Net native mean that people no longer have to worry about obfuscating their applications?

*Turns on sarcasm detector*

*RESULT INCONCLUSIVE*