i would suggest, if you try to teach something, you should avoid any distractions from the core topic to make it easier to concentrate on the stuff you want to show. its cute that visual studio code can now also handle F# mostly,but if its obviously unfinished in a way that every second minute it misunderstands the language in the editor and shows errors that dont exist or claims everything is fine although it isnt...just use visual studio for the demo where it works correctly and add as a comment that visual studio code can also more or less already handle it. by using VS-code you just distract from the F#-demo by fighting the editor all along the demo.
further- dont make type-annotations a thing of taste that different "camps" do or dont, in the shown case its a thing of quality thats easy to explain. you can translate "the compiler infering the type" by "the compiler guessing the type". in many cases the compiler can only guess...if you have no numbers at all in a simple equation, it will likely assume int for the type, once you write a number with a comma it will assume its float, same if you use a sine or cosine where it knows the return type. so if you create a library with a function inside, thats only consumed by others using that library, it is extremely easy that some time later you slightly modify the function, and accidentially make the compiler infere another type for the return value. you wont even notice, your library will compile perfectly fine. it will then only explode in the face of the consumer of your library once he tries to compile and in his code all over the place red lines start to appear. so simply annotating your return type in a function is a very helpfull safety feature that helps you prevent breaking your code without even noticing it.
its great you finally address the problem of inter-process-communication. i just cant really appreciate the "awesomeness" of all of that as i know all this was already possible since 1997 with COM in a MUCH easier and elegant object-oriented manner. even plain old vb6 applications could do exactly that in just 2 lines of code with every com-enabled component like word,excel,powerpoint,hundreds of COM-libraries and other com-applications ....even the much older "object linking and embedding" was a ton more powerfull than what we have here today.from a technological perspective we really have turned back the clock to around 1996 with those mechanisms we have now for Apps. its better than nothing, but really not much better...sadly.
@simontao:thanks for your reply, took me a while to realize you wrote back! :)
regarding the math-library-topic, yes something like DirectCompute or Cuda would be great. Problem with Cuda is its tied to one manufacturer if i'm not wrong, so it depends if Nivida or AMD made the GPU. DirectCompute seems more hardware-agnostic, but i wouldnt know of a nice math-library for .Net that gives access to DirectCompute yet...except maybe SharpDX does and i just didnt know. But as you are quite likely aware, there is quite a difference to what a c++ developer considers a nice API and what someone used to .net-framework would like to use, and thats why a am not immediately excited if i would find out SharpDX has some way of accessing DirectCompute :)
also Direct2D is accessible by some wrappers and what Win2D does could theoretically be done via SharpDX, but still what you offer now with Win2D is another liga, because you managed to really transform this into the mindset of .Net.
so ...just what immediately crosses my mind (if my idea is straight stupid just please dont feel offended *g*), a math library could have all kinds of matrix-operations for huge matrices, doing all computation on the gpu, or like making a lambda chaining calculations together and the lambda gets transformed to GPU code on the fly. i know all sorts of "but you should do this in c++ for performance-reasons"-guys will immediately pop up, but its quite often some code might profit from handing off calculations to the GPU, but the amount of work necessary to dive into the tools currently available makes it seem too unattractive to even try.
and regarding 3D- your example with the teapot having your Win2D graphics as texture was amazing, but just imagine all the stuff necessary for making the teapot appear and rotate would as well be as easy as your code needed for making the textures in realtime in Win2D. just imagine if you were now used to having Win2D as your primary way of doing graphics, how would this story need to continue to have the same elegance of coding for creating 3D graphics :)
i believe for many 2D-games Win2D will be a very welcome alternative and viable option as replacement for XNA-Framework. with 3D support i guess you could find lots and lots of new friends in the area of indie-game-developement that still seem upset quite a lot on uservoice about microsoft letting XNA framework die :)
great talk, but sadly it shows in win10 even on desktop UAP is not usable for some categories of applications where the OS deciding when an app is suspended is not tolerable. even i as the user would absolutely prefere to be in charge which of the applications i started keep running on my machine instead of having the OS overruling my decisions. an off-switch for that behaviour would at least be something i would expect.