As far as I can tell, this is only for the free personal plan, not any of the business offerings (ie not Copilot for M365) and Github Copilot is under a separate set of terms.
“These Terms don’t apply to Microsoft 365 Copilot apps or services unless that specific app or service says that these Terms apply.”
Think of Copilot being a suite of different products under the same overall banner and it starts to make (a bit) more sense.
This is super interesting - aside from the benchmarks are there any good examples of loading and querying data from external sources? Any plans to support other formats like parquet?
I hear you on the opportunity side and I can't see that changing. The good news is in recent releases there's a lot less boilerplate - "dotnet new console -lang F#" results in two files, a short fsproj file and a single line of Hello World.
This is an impressive achievement, given there’s a whole language plus IDE. Kudos to the author. I couldn’t see any indication of what the author plans to use it for - I hope he can share more below?
I would start with a business case - what are the benefits, is it going to generate revenue or reduce costs, when do the benefits start to be realised.
Then look at the cost in starting to develop what you need, and how you’re going to get started.
Are there existing COTS systems (e.g. SAP, Dynamics, Salesforce) that are extensible but can do 60% of the base functionality out of the box? Can you start by integrating two systems or using your low code platform to prove the concept? A couple of engineers/freelancers/external shop for a few months is a lot cheaper than hiring a whole development team… others in the thread have given you a reasonable estimate of that.
Think about what’s the MVP needed to start showing ROI. Maybe do a smaller business case for that.
Look at the payback period internally and ask what hurdle rate is needed to invest from your CFO.
FWIW, I started programming F# during your tenure at MS and in a couple of years it became a really capable cross platform option - partly MS, partly community, but definitely helped out by you. Thanks!
This was me - my first .net language was F# (although I'd dabbled a tiny bit in C#); it was hard to learn the .net standard library as well as trying to learn functional idioms...
Very interesting - thanks! It's an interesting exercise thinking through some of the constraints and some of the engineering tradeoffs. Out of interest, how much development is actually done on device vs being done on another system and then loaded onto the SD card?
As a thought experiment, this got me thinking what would a solution just using .NET core look like? Obviously I don't have all the details but I think you can do all of those things in .NET (with the exception of the embedded stuff probably).
* Bluetooth and maps libraries are available for Xamarin, [1] [2]
* Control server could be written in C# using the .NET core worker template [3] and deployed as a SystemD service and then the SDK deployed as a package to enable local development.
* Cloud bridge deployed as a service or website using raw sockets, SignalR or Azure IOT hub (depending on requirements).
You'd end up with 2 languages instead of 5 and I suspect you'd be able to factor some code out into libraries as well...
It's a diaeresis symbol rather than an umlaut, used (infrequently) to show that it's pronounced co-or rather than coor. Quite archaic, unless you're the New York Times, who use it as part of their house style, but not wrong!
I used to use Visual Studio and VSMac for my F# experimentation. Over the past couple of years, Ionide has got so much better that I've switched completely over to it from VS for all my F# work. The new 7.0 release a couple of days ago looks to have continued this trend.