Somasegar's WebLog

This is an awesome feature. Hopefully it works as expected. Will check it out soon! .NET rocks!

This is exciting, I can't wait to check it out!

You guys keep telling us that VB and C# are equals.

Yet once again we have to vitness another C#-only feature release.

WTF???

Why only C#?

Surely the legions of VB.NET developers also need this?

I for one can think of many really compelling uses for this technology - and I (and my team) prefers VB.NET.

At least make a statement that clarifies the absence of VB.NET, if only to say it will be in the next version, or a service pack, etc.

@Jesper - then don't use such a freakish language and upgrade to C# and avoid being left behind all the time!  Only kidding (mostly!) - I'm actually quite jealous VB seems to be getting initialisers for auto properties, which is something C# devs have been crying out for for ages:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361647

As for STM.NET this does look interesting.  I see it requires a modified CLR though.  The only thing I'm worried about is - are there any performance penalties for existing apps that don't make use of the new features?

Great,

If this works well, I will not longer have to consider multi threaded programming to be more often part of the problem then the solution.   (I am assume that STM will be in ALL editions of developer studio and that it will be make to work with ALL ORM including NHibernate)

For example a web system I am working on today (that was written a few years ago) duplicates a lot of a data in the user’s sessions objects, as we could not face having to debug locking problem.  With STM we could have shared the data between all users and saved many MB per logged on user.

Now can we have support for asserting that objects/methods are immutable in Code Contracts and standard versioned data collections in the BCL to complete the picture.

Soma,

This is GREAT and I am looking forward to hearing a commitment on this functionallity being made available in a supported manner.

The items emerging from Dev Div have simply been fantastic and everyone on the team deserves as big CONGRATULATIONS....keep up the good work.

------

As to Ian's comment.. I have long held the viewpoint that the single biggests barrier to effective parallel execution is changing the developers mindset, and not specific technologies.

From a you age people are taught to think things out "step by step" (a sequential flow) rather than thinking "get all of your friends together and figure out how many things you can do as the same time to accomplish the final goal in the minimum time".

David V. Corbin

Microsoft MVP

President / Chief Architect

Dynamic Concepts Development Corp.

New York, NY

I will try to address some of these questions and comments here but I encourage you to have a discussion of these issues on the STM.NET forum (see below).

DanielSmith: we made a large effort to make STM pay-for-play -- so non STM code will not pay a measurable penalty.  But, this release is experimental, so we haven't spent a huge effort tuning for performance.

Jesper and Louis: I would love to hear about your VB requirements for STM.

Why did we omit support for VB?  The truth is that with a small team, we had to make hard decisions and limit the scope of our release.  We did not have the engineering resources to adequately cover all languages -- so we focused on one.  The goal was to create a STM framework that could, in practice, work for all languages but for this limited experimental release our first target is C#.  

Please feel free to create a thread in the STM forum to discuss your VB requirements and describe how you would like to use STM.  There, we can discuss what limitations we know we have when using VB today.

The forum is at:

http://social.msdn.microsoft.com/Forums/en-US/stmdevlab/threads

Thank you for your interest in our work!

Dana Groff

Program Manager for STM.NET