Thanks so much to all that have contributed to this blog and community, it has definitely made an impact in my excitement for software. To whom it may concern, please make every effort to preserve this fantastic archive of content.
A note that the default interface implementation can still cause a breaking change as there's a chance you'll step on another interface's toes, requiring explicit implementation by the consumer.
Love the new pattern matching features, feels like we're slowly moving toward structural typing so looking forward to seeing what gets implemented next there.
Extension everything would be very nice, especially for operators. For example, would we be able to define an extension "+" operator on two int arrays? Will we ever get a way to do this generically (i.e. IAddable static "interfaces"/contracts)? We do a lot of multidimensional math at work, and have moved away from C# for many of these tasks which are just too cumbersome to script with.
@dcuccia: Thank you! Immo Landwerth has a great blog post covering the challenges associated with porting from the .NET Framework to .NET Core. For now, we have dotnet-apiport that will help identify what libraries are compatible and what will need more work put into them. Keep in mind, many APIs will be added to .NET Core 2.0 that will make porting even easier with .NET Standard 2.0. Currently, .NET Core 2.0 and .NET Standard 2.0 are planned for Q3 2017.
Thanks for your reply and for the timelines. I'd seen that dotnet-apiport hadn't been worked on for a while, so I assumed it wasn't supported/recommended for the 1.0 tooling release. I'm just one voice, but it would sure be nice to have this baked in to the shipped tooling, and "dotnet migrate" sure sounds relevant to this class of compatibility assesment.
Regarding "dotnet migrate," is the plan to use this same tooling/framework to assist migration from .NET Framework as well? If so, what's the timeline on that? It's great to have assistance for people that used project.json, but obviously the much bigger cohort are those of us who have waited for 1.0 tooling to migrate over from the full framework. Something along the lines of the MoMA/Xamarin tools for checking compatibility against different profiles will be crucial for this.
@degloff VERY exciting. This has been a holy grail for quite some time (e.g. see Brahma, C$ aka "C Bucks", Tidepowered GPU.NET). I look forward to learning more about Alea, and I hope that many of the wins and lessons learned from these previous efforts, as well as importantly C++ AMP, have been integrated into the design.
Looking at your overview docs, all I see are single-line GPU code examples, but I presume multi-line methods work, too. What are the restrictions for the GPU method body?
Many applications will require operating along one dimension of a multidimensional array, e.g. transforming RGB images along the color axis, reducing to scalar intensity, etc. Does Alea work natively with multidimensional arrays? How can one perform gather operations (e.g. gaussian blur)? Using user-defined indexers, or Alea constructs (ala C++ AMP)?
To quote Agent Fox Mulder, "I want to believe." Just being able to checkout code from a NuGet package w/o setting up an old version of VS to work with CUDA will be a joy. Look forward to looking in-depth at your code samples.
Thanks for the video, this sounds like a great tool that probably should have been there from the beginning. Not to sound too cynical, but can you confirm that Visual Studio and Office can and will use this someday soon? That certainly would build confidence.
Thanks for the video. Functions looks quite powerful! Looking forward to the improvements in usability that were discussed here, particularly enhancement to tooling (specifying nuget packages in online editor, VS integration, more languages, etc) and on-prem function execution. Regarding the comment @ 38:24 "we won't give you an SLA for that" - do you mean that on-prem execution will only ever be supported/allowed for testing purposes?