Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Erik Meijer, Immo Landwerth, and Andrew Arnott: Immutable Collections for .NET

Download

Right click “Save as…”

Erik Meijer interviews .NET team PM Immo Landwerth and Software Developer Andrew Arnott. The topic is Immutable Collections, a new set of immutable types for .NET. You can play around with these today as part of a preview release (NuGet link below). Tune in!

Niners asked questions in advance and some of them were addressed. Thanks again for asking and sorry we didn't get to all of them, but many of the topics were covered (what, why, how, etc...).

Over the last years .NET added many features to make writing multithreaded applications easier. This includes the Task Parallel Library (TPL) as well as the new async/await keywords features to reduce the friction when writing asynchronous code. However, it's still challenging to keep mutable state under control when multiple threads are involved. A common approach is to make use of immutable state that can be passed freely between different threads.
- Immo Landwerth

The NuGet package preview includes these types:

  • ImmutableStack<T>
  • ImmutableQueue<T>
  • ImmutableList<T>
  • ImmutableHashSet<T>
  • ImmutableSortedSet<T>
  • ImmutableDictionary<K, V>
  • ImmutableSortedDictionary<K, V>

Interfaces for each of these types are also defined to facilitate exchange of immutable collection types that may be implemented differently to optimize for very specific performance or memory requirements.

See Andrew's blog for more detailed information (on immutable types for .NET and more. Lots of great info...).

Tags:

Follow the Discussion

  • Great discussion.  I've moved away from ConcurrentQueue and ConcurrentDictionary Collections in favor of ImmutableList and ImmutableDictionary collections on a high performance a WCF service that uses TPL extensively.  I noticed a nice performance increase on the larger collections when iterating through larger collections.

    For everyone getting started, the only real gotcha I've found is to remember to take the return result and assign it to the collection like so:

    var tmpCollection = ImmutableList<string>.Empty;
    
    tmpCollection = tmpCollection.Add("Test");

    Overall though, I am very pleased with the new Collections, kudos to your team!

  • I guess we have to thank Roslyn project (at least in part) for these collections Smiley

  • @Jarred: Yep, that's a common mistake when starting to use these new collections Smiley

    @mdonatas: In fact that thank goes straight to Andrew Arnott - he wrote the immutable collections that Roslyn uses. However, you are right from the perspective that Roslyn definitely created a need for bringing a common way to represent immutable collections to the BCL.

  • Bent Rasmussenexoteric stuck in a loop, for a while

    Nice interview.

    There are also some immtuable F# collections and it would be interesting to compare to those.

    I like the builder pattern - not that it's necessary but the optimization it affords. It's also interesting to hear how much defensive coding is inside VS around collections. Immutability where possible just gives peace of mind and static guarantees. It is almost like dependent types where you can express a value constraint statically. 

    The thing about sharing (and deep immutability) was also interesting, it kind of reminded me of smart pointers but it could have been expanded further by Erik.

    It seemed like there was material enough for more talk but this was fun.

    Smiley

  • CharlesCharles Welcome Change

    @exoteric: We can always dig in further.

    C

  • oskarkoskark

    naming....

    I would really like the BCL team to reconsider the naming, this is an log2 version of persistent collections: http://en.wikipedia.org/wiki/Persistent_data_structure I think most agree that the idea originates from Chris Okasaki book (references in the wikipedia page)

    Please do not rename a known CS concept out of ignorance.

  • Dave Van den EyndeDave Van den Eynde

    @oskark If I read that article, it says that these data structures are effectively immutable, and further that they are not committed to persistent storage, an unrelated use of the word persistent.

    So I don't think it would be a good idea to name them Persistent Collections, because that would be confusing, don't you think?

  • aL3891aL3891 kinect ftw

    cool stuff Smiley

    but I don't get the whole Add/AddRange problem, the following code work just fine right? am I missing something?

        public class List<T>
        {
            public void Add(T item){
            
            }
            public void Add(IEnumerable<T> items) { 
            
            }
        }
    ...
    test.Add("hello");
    test.Add(new[] { "world" });

  • Bent Rasmussenexoteric stuck in a loop, for a while

    I do wonder about deep immutability. It seems like freezeable objects and collections are generally a nice paradigm but in particular domain classes are painful to make freezable and edit without some language support. Say you want to either change a.b.c or get a new version of a with a new b with a new c, then you could have operations for that ("example syntax")

    var x = a.b.c <- x // new immutable version

    var y = a.b.c := x // new mutable version

    y.b.c := z // destructive update of mutable version

    a.p <~ b.x + c.x //  a reactive expression propagated to a.p (binq?)

    And how about having time or cardinality buffering constraints on properties... select back in time? See properties as cursors in temporal collections? Automatic persistence to versioned db? Capture and replay user interface session from "tape"?

    Is there a language waiting to be conceived with even tighter integration for time, immutablity, mutability, async, push, pull, dependency properties, etc. with the benefit of hindsight?

    Ahh well at least we now have both great libraries and good language support.

  • woopsiewoopsie

    @al3891

    How are you (is the compiler?) supposed to determine whether the collection is added as a single item or whether to enumerate all the items in the collection and add them individually?

  • @al3891: You're right -- the example I gave in the video is busted. In fact, Erik caught me on this during the interview but he was kind enough not calling it out Wink

    The C# compiler is able to resolve the overload because T is more specific than IEnumerable<T>. In other words, the compiler favors identity conversions over any implicit conversions. Theoretically you could envision that other compilers might handle this differently, but I kinda doubt that;s a realistic assumption.

    However, it's possible to construct ambiguous cases:

    class MyList<T>
    {
        public void Add(T item) {}
        public void Add(IEnumerable<T> item) {}
    }
    class Base {}
    class Derived : Base, IEnumerable<Base>
    {
        public IEnumerator<Base> GetEnumerator()
        {
            return null;
        }
        IEnumerator IEnumerable.GetEnumerator()
        {
            return GetEnumerator();
        }
    }
    var list = new MyList<Base>();
    list.Add(new Derived());
    

    Now is that a big deal? Probably not because you can resolve this conflict easily using a cast and it's not a very common scenario.

    Well, why are we following the existing naming convention then? Because it's an existing naming convention. If you can do (A) or (B) but (A) is already established we favor (A) unless (B) offers a significant improvement. In this case I don't think it does.

  • AmitAmit

    Nice addition! But I wonder for how long they will be relevant? In Win8 apps! where HTML5, Javascript and C++ are first class citizens and .NET has been demoted to second class citizen?

  • Usman ur Rehman AhmedUsman ur Rehman Ahmed

    The BCL blog post http://blogs.msdn.com/b/bclteam/archive/2012/12/18/preview-of-immutable-collections-released-on-nuget.aspx suggests that the release of NUGet package is for .NET Framework 4.5 but during installation I stumbled upon following issue,

    Successfully installed 'Microsoft.Bcl.Immutable 1.0.5-beta'.
    Successfully uninstalled 'Validation 2.0.1.12362'.
    Install failed. Rolling back...
    Install-Package : Could not install package 'Validation 2.0.1.12362'. You are trying to install this package into a project that
    targets '.NETFramework,Version=v4.5', but the package does not contain any assembly references that are compatible with that
    framework. For more information, contact the package author.
    ...

    Any idea what am I doing wrong please?

  • CharlesCharles Welcome Change

    @Amit: Demoted? Second class? Why would you state this? It's not true...
    C

  • The BCL blog post http://blogs.msdn.com/b/bclteam/archive/2012/12/18/preview-of-immutable-collections-released-on-nuget.aspx suggests that the release of NUGet package is for .NET Framework 4.5 but during installation I stumbled upon following issue,

    Successfully installed 'Microsoft.Bcl.Immutable 1.0.5-beta'.
    Successfully uninstalled 'Validation 2.0.1.12362'.
    Install failed. Rolling back...
    Install-Package : Could not install package 'Validation 2.0.1.12362'. You are trying to install this package into a project that
    targets '.NETFramework,Version=v4.5', but the package does not contain any assembly references that are compatible with that
    framework. For more information, contact the package author.
    ...

    Any idea what am I doing wrong please?

     

    Yes -- you are using a NuGet 2.0. Make sure you've updated to NuGet 2.1 or higher. Just open VS and go to Extras | Extensions and Updates | Updates. There is probably a NuGet 2.2 knocking on your door Smiley

  • Nice addition! But I wonder for how long they will be relevant? In Win8 apps! where HTML5, Javascript and C++ are first class citizens and .NET has been demoted to second class citizen?

    First of all I don't think that's true. I was the PM driving the .NET surface area you can use when targeting Windows 8 store apps. Let me tell you: the entire .NET Framework team and large chunks of Visual Studio spend significant amount of resources to make this an awesome experience. As with every technology that is advanced enough by adding a non-trivial set of features, there are rough edges and I'm the first to admit that. However, the same is true for C++ and JavaScript given that Windows Store apps run in a different environment that are new for them, too. We all try very hard to make writing Windows Store apps as easy and smooth an experience as possible.

    Secondly, looking back to the days when Microsoft announced .NET, I think we've learned from that in the sense that we no longer promote a single technology to rule them all. We've made the mistake with .NET which lead to unrealistic expectations what .NET would deliver. I believe the .NET platform is the most productive development platform out there (otherwise I wouldn't work here) but I also believe it's not for everybody. Different tasks require different tools. And someone needs to write the CLR as well Wink

    Rest assured that .NET isn't going away any time soon. You don't need to take my word for it -- just think of all the products Microsoft offers that are written in managed code.

    For platforms like Windows the key is offering choice. Some might have a strong web background with JavaScript. Others come from the native world and prefer C/C++. Others are .NET developers.

    My advice: ignore marketing and choose what you feel comfortable with and what gets the job done best.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.