The .NET Stacks #19: An Ignite recap and F# with Phillip Carter

Dave Brock -

This week, we’ll review Ignite 2020, talk with Phillip Carter about F# from the Microsoft perspective, and check out what’s going on around the community.

Ignite 2020 is a wrap

Build 2020 seems like so long ago, wasn’t it? I covered it in our very first issue four months ago. This week, Microsoft put on Ignite 2020—virtually, of course. If you’ve followed .NET over the last few months, you didn’t see a lot of surprises from the developer perspective—but there’s still some good stuff to go through.

Let’s see: .NET 5 RC is now available (but as a loyal reader, you knew that), Azure Communication Services is now in preview (with developers asking what that means for Twilio), Visual Studio 2019 support for GitHub Codespaces is now in beta, there’s new capabilities for Azure Logic Apps, and Azure Cosmos DB now has a serverless option. There’s more to see, depending on your focus—so check out the Ignite 2020 Book of News for the full treatment.

You can check out the sessions on-demand now. Here’s some that should be popular with .NET developers:

In case it isn’t completely obvious, these events are sales pitches for Azure—and the long game for developer productivity beats AWS and GCP by a country mile.

Would you like to get started in minutes without worrying about device specs or mind-numbing setup? Try GitHub Codespaces, a containerized environment in the cloud. Would you like to deploy your repo to the cloud in seconds? Easy. When you own the developer tools, the cloud platform, and the de-facto code sharing service in the industry, the “see how easy that was?” model is really paying off.

Dev Discussions: Phillip Carter

Last week, we talked to Isaac Abraham about F# from a C# developer’s perspective. This week, I’m excited to get more F# perspectives from Phillip Carter. Phillip is a busy guy at Microsoft but a big part of his role as a Program Manager is overseeing F# and its tooling.

In this interview, we talk to Phillip about Microsoft F# support, F# tooling (and how it might compare to C#), good advice for learning F#, and more.

From the build system to the tooling, is F# a first-class citizen in Visual Studio and other tools like C# is? If I’m a C# dev coming over, would I be surprised about things I am used to?

For anyone who uses Visual Studio to primarily edit code, then F# may take some getting used to, but most of the things you’re used to using are present. In that sense, it is first class. Project integration, semantic colors, IntelliSense, tooltips (more advanced than those in C#), some refactorings and analyzers, and so on.

C# has objectively more IDE features than F#, and the number of refactorings available in F# tooling absolutely pales in comparison to C# tooling. Some of these come down to how each language works, though, so it’s not quite so simple as “F# could just have XYZ features that C# has.” But overall, I think people tend to feel mostly satisfied by the kinds of tooling available to them.

It’s often claimed that F# needs less refactoring tools because the language tends to guide programmers into one way to do things, and the combination of the F# type system and language design lends itself towards the idiom, “if it compiles, it works right.” This is mostly true, though I do feel like there are entire classes of refactoring tools that F# developers would love to use, and they’d be unique to F# and functional programming.

What’s the biggest hurdle you see for people trying to learn F#, especially from OO languages like C# or Java?

I think that OO programming in mainstream OO languages tends to over-emphasize ceremony and lead to overcomplicated programs. A lot of people normalize this and then struggle to work with something that is significantly simpler and has less moving parts.

When you expect something to be complicated and it’s simple, this simplicity almost feels like it’s mocking you, like the language and environment is somehow smarter than you. That’s certainly what I felt when I learned F# and Haskell for the first time.

Beyond this, I think that the biggest remaining hurdles simply are the lack of curly braces and immutability. It’s important to recall that for many people, programming languages are strongly associated with curly braces and they can struggle to accept that a general-purpose programming language can work well without them.

C, C++, Java, C#, and JavaScript are the most widely used languages and they all come from the same family of programming languages. Diverging greatly from that syntax is a big deal and shouldn’t be underestimated. This syntax hurdle is less of a concern for Python programmers, and I’ve found that folks with Python experience are usually warmer to the idea of F# being whitespace sensitive. Go figure!

The immutability hurdle is a big one for everyone, though. Most people are trained to do “place-oriented programming”—put a value in a variable, put that variable in a list of variables, change the value in the variable, change the list of variables, and so on. Shifting the way you think about program flow in terms of immutability is a challenge that some people never overcome, or they prefer not to overcome because they hate the idea of it. It really does fundamentally alter how you write a program, and if you have a decade or more of training with one way to write programs, immutability can be a big challenge.

We’re seeing a lot of F# inspiration lately in C#, especially with what’s new in C# 9 (with immutability, records, for example). Where do you think the dividing line is between C# with FP and using F#? Is there guidance to help me make that decision?

I think the dividing line comes down to two things: what your defaults are and what you emphasize.

C# is getting a degree of immutability with records. But normal C# programming in any context is mutable by default. You can do immutable programming in C# today, and C# records will help with that. But it’s still a bit of a chore because the rest of the language is just begging you to mutate some variables.

They’re called variables for a reason! This isn’t a value judgement, though. It’s just what the defaults are. C# is mutable by default, with an increasing set of tools to do some immutability. F# is immutable by default, and it has some tools for doing mutable programming.

I think the second point is more nuanced, but also more important. Both C# and F# implement the .NET object system. Both can do inheritance, use accessibility modifiers on classes, and do fancy things with interfaces (including interfaces with default implementations). But how many F# programmers use this side of the language as a part of their normal programming? Not that many. OOP is possible in F#, but it’s just not emphasized. F# is squarely about functional programming first, with an object programming system at your disposal when you need it.

On the other hand, C# is evolving into a more unopinionated language that lets you do just about anything in any way you like. The reality is that some things work better than others (recall that C# is not immutable by default), but this lack of emphasis on one paradigm over the other can lead to vastly different codebases despite being written in the same language.

Is that okay? I can’t tell. But I think it makes identifying the answer to the question, “how should I do this?” more challenging. If you wanted to do functional programming, you could use C# and be fine. But by using a language that is fairly unopinionated about how you use it, you may find that it’s harder to “get it” when thinking functionally than if you were to use F#. Some of the principles of typed functional programming may feel more difficult or awkward because C# wasn’t built with them in at first. Not necessarily a blocker, but it still matters.

To read the entire interview, head on over to my site.

🌎 Last week in the .NET world

🔥 The Top 3

📢 Announcements

📅 Community and events

😎 Blazor / ASP.NET Core

⛅ The cloud

📔 C#

📗 F#

🔧 Tools

📱 Xamarin

🎤 Podcasts

🎥 Videos