The .NET Stacks #59: 🎇 When your Copilot is mostly right

Dave Brock -

Welcome to another week, all. I hope your Monday is off to a good start.

If you follow me on Twitter, you may have heard I got attacked by six bees last week. I'm fine but appreciate some of you reaching out with comments about whether I'm still "buzzing around somewhere" or "minding my own beeswax" or "ooh, that stings" or even sending memes of a guy with a beard made of bees.

Here's what hive I've got for you this week:

  • One big thing: Thoughts on GitHub Copilot
  • The little things: A new source generator for JSON serialization, F# getting some love
  • Last week in the .NET world

One big thing: Thoughts on GitHub Copilot

Have you caught all the buzz about GitHub Copilot? It's been out in private preview for about a month and I've been checking it out. Marketed by GitHub as "your AI pair programmer," it provides predictions for your code—either as a single line or even an entire function. It's based on GPT-3, a "deep-learning model that uses deep learning to produce human like text."

To quote Colin Ebehardt:

Copilot is based on Codex, a new model which is a derivative of GPT3, which has been trained on vast quantities of open source code from GitHub. It is integrated directly with VSCode in order to generate suggestions based on a combination of the current context (i.e. your code), and the ‘knowledge’ it has acquired during the training process.

There's a ton of examples online from amazed developers. For example, you can enter a comment like // Call GitHub API and Copilot will create a function that calls the GitHub API for you. Of course, this led to some snarky comments about AI taking our jobs. If you're concerned about that, I'd ask you to look at some of the code Copilot spits out. It isn't perfect, but it learns from you ... and does an OK job. To quote philosopher Brian Fantana: "60% of the time, it works every time."

Copilot has massive potential to improve developer workflow and efficiency. For example, how many times do you have to ask Google how to do something you haven't done in a while? Let's say you haven't called HttpClient in a while, or you want to read from a CSV file. You search how to do it, find official docs or Stack Overflow, and go back to your editor and do your best. What if you can cut out all that manual work and generate that code in a few keystrokes? You can focus on the problem you're solving and not on "how do I" tasks. As a smart and experienced developer, you'll know that you'll need to understand the code and tweak it as needed. I do worry about those who won't. It's been easy to blindly introduce code since the invention of the Internet, of course, but doing it from your editor cranks it up a few notches.

From Matthew MacDonald's excellent piece on Copilot:

As long as you need to spend effort reviewing every piece of suggested code, and as long as there is no way to separate a rock-solid implementation from something fuzzier and riskier, the value of Copilot drops dramatically. Not only will it save less time, but it risks introducing elementary mistakes that a less experienced programmer might accept, like using float for a currency variable.

This offering—which will eventually be sold by Microsoft—spends a lot of the reputational capital Microsoft has been building with developers since they started embracing open-source software. While it fits with Microsoft's mission to own the developer experience—from GitHub and NPM to Azure and VS Code, just to name a few—I've seen some Microsoft skeptics viewing this as the company cashing in on the goodwill with the community. While you can't be shocked to see a company mining its free service's public data for eventual profit, there are quite a few licensing and legal challenges that need further clarification (saying "the code belongs to you" in its FAQs might not get by a company's legal department).

Even so, I think Copilot will eventually turn into a powerful tool that can help to automate the painful parts of programming.

The little things: A new source generator for JSON serialization, F# getting some love

While it's easy to highlight the new .NET stuff like hot reload and AOT compilation, it's just as important to write about the stuff we do every day: like serializing and deserializing JSON. Is it exciting? No. It is fun? Also no. It's something we do all the time, though—so it was nice to see Microsoft roll out a new System.Text.Json source generator.

We've talked about source generators before, but a refresher: its code that runs during compilation and can produce additional files that are compiled together with the rest of your code. It’s a compilation step that generates code for you based on your code. It creates a lot of possibilities. This provides an alternative for expensive reflection code, which traditionally leads to slow startup and memory issues.

This new source generator works with JsonSerializer (and does not break existing implementations, don't worry). From the post on the topic:

The approach the JSON source generator takes to provide these benefits is to move the runtime inspection of JSON-serializable types to compile-time, where it generates a static model to access data on the types, optimized serialization logic using Utf8JsonWriter directly, or both.

In the end, moving much of this from runtime to compile-time will help with throughput, memory, and assembly trimming capabilities. The trimming is a big one. The generator can shed a lot of unused code and dependencies.

I think the post does a good job of outlining the capabilities and the rationale for introducing yet another set of APIs.

It's been nice to see F# getting some love lately. Microsoft's latest .NET Conf will be Focus on F#, which will take place on Thursday. Last week, the .NET Docs Show held an F# AMA and Microsoft introduced its first F# Learn modules. Even if you're a C# lifer, it's hard to argue against the impact of functional languages such as F#. As C# has spent the last few major releases introducing constructs like pattern matching, records, and features that focus on immutability, these are features languages like F# have enjoyed for years.

As for Focus on F#, there's a lot of nice stuff on the agenda. I'm looking forward to seeing F# creator Don Syme teaching Python creator Guido van Rossum F# from scratch. For more information on F# and its context within the C# ecosystem, I recommend brushing up on my interviews last year with Isaac Abraham and Phillip Carter.

🌎 Last week in the .NET world

🔥 The Top 3

📢 Announcements

📅 Community and events

🌎 Web development

🥅 The .NET platform

Mike Hadlow creates an Microsoft.Extensions.DependencyInjection object graph writer.

⛅ The cloud

📔 Languages

🔧 Tools

📱 Xamarin

🏗 Design, testing, and best practices

🎤 Podcasts

🎥 Videos