Listing of PDC sessions on Windows Azure copied from:

http://blogs.msdn.com/jnak/archive/2009/11/19/videos-of-the-windows-azure-sessions-at-pdc09.aspx

Introductory

• Lap Around the Windows Azure Platform
• Windows Azure Present and Future
• Introduction to Building Applications with Windows Azure
• The Business of Windows Azure: What you should know about Windows Azure Platform pricing and SLAs

Learn to Develop for Windows Azure

• Tips and Tricks for Using Visual Studio 2010 to Build Applications that Run on Windows Azure
• Patterns for Building Scalable and Reliable Applications with Windows Azure
• Developing Advanced Applications with Windows Azure
• Windows Azure Monitoring, Logging, and Management APIs
• Automating the Application Lifecycle with Windows Azure
• Building Hybrid Cloud Applications with Windows Azure and the Service Bus
• Enabling Single Sign-On to Windows Azure Applications
• Bridging the Gap from On-Premises to the Cloud

Windows Azure Storage

• Storing and Manipulating Blobs and Files with Windows Azure Storage
• Windows Azure Tables and Queues Deep Dive

Windows Azure as an Open Platform

• Developing PHP and MySQL Applications with Windows Azure
• Building Java Applications with Windows Azure

SQL Azure Sessions

• Enrich your Applications with Data from Microsoft Project Code Name “Dallas”
• SQL Azure Database: Present and Future
• Using the Microsoft Sync Framework to Connect Apps to the Cloud
• The Future of Database Development with SQL Azure
• Microsoft SQL Azure Database: Under the Hood
• Scaling out Web Applications with Microsoft SQL Azure Databases
• Petabytes for Peanuts! Making Sense out of “Ambient” Data
• Development Best Practices and Patterns for Using Microsoft SQL Azure Databases

Showcases

• Lessons Learned: Building Scalable Applications with the Windows Azure Platform
• Lessons Learned: Building On-Premises and Cloud Applications with the Service Bus and Windows Azure
• Lessons Learned: Building Multi-Tenant Applications with the Windows Azure Platform
• Lessons Learned: Migrating Applications to the Windows Azure Platform

F# leads the transformation

What F# represents is a partitioning of the programming languages. And unlike previous partitions this is a transformative change. General purpose languages are being supplanted by a collection of domain specific languages. These domain specific languages will include a general purpose language but it will not be there to rule them all but rather to orchestrate them all.
F# is a native or natural functional language where objects are possible (but the objects may not feel native or natural). C# is an object oriented language. With the advent of LINQ, some functional capabilities are possible but most C# programmers have experienced the unnatural things LINQ is doing to the language.
So each language has a dominant paradigm, C# is an object oriented language and F# is functionally oriented. Each supports the other paradigm but using that paradigm is for one off or special purpose needs. LINQ allows C# programmers to off load a bunch of data processing tasks that are hard and / or tedious to code in any C derivative language. Likewise objects are available in F# in case you need to maintain state. But the more you need to maintain state the less the task you are working with is a functional oriented task.
Since we are 60+ years into programming, Bare-Naked-Ladies-Fans ("It's all been done") are sure to point out this has all been done before. This is a valid point as C++ and Perl demonstrate. Both languages have adapted and provide these and numerous other features. However both languages have purchased these abilities at ever increasing complexity. As the Ruby creator aptly points out C++ is constantly surprising him. For a hobbyist, surprise is fun. For a guy trying to get something done surprise is bad.
But leaving aside surprise, it is hard to feel like you know either of C++ of Perl in their entirety. All special purpose languages that succeed will share this fate. Every feature the language supports will require some complexity to implement it in the syntax. The future being unknowable will always mean some choices turn out to be less than perfect.
So as the general purpose languages evolve their complexity and internal contradictions will grow as well. The languages scream for a refactoring. But refactoring is the one tool no language can ever use. No matter how ill advised a feature, it cannot be removed because this would break countless programs. And refactoring is not the removal of one feature but the wholesale change of several features.
What history gave us was series of general purpose languages (C, C++, Perl, Java, C# and others) where an attempt was made to refactor to the perfect paradigm. The dot Net platform opens up a new way; several languages can interoperate on the same platform and in the same development environment. F# is the break out example because unlike the C# and VB.net interaction it implements a completely different programming paradigm.
The general purpose languages do not have to implement every hot new feature. They can develop side by side with the F# languages, leveraging their power without corrupting their own syntax.