During my usual morning walk today, I went to look for it, and there it was, an interview I had done in 2021 that I had completely forgotten about. I got over the initial embarrassment (it’s always strange to hear your own voice) and resisted the temptation to turn it off, listening to it all the way through. I must admit that it captures that moment in my professional life, and much of the content is still relevant, especially regarding my experience as an open-source author and maintainer and my transition from C# to Python and back.

I found copies of the podcast on many platforms, including a YouTube video (we actually video recorded it, who knew!), but they are all in Italian. I fed the video to MacWhisper, which transcribed it; I then asked Claude to translate it into English, removing pauses and repetitions; and finally, I ran it through Grammarly for a grammatical check. That’s what AI allows today: half an hour to go from an Italian audio podcast to a full English transcript, and that’s including a manual, pedantic review of Grammarly suggestions.

What follows is the full transcript, in English, of that 2021 interview. We touch on a variety of topics, including Python for .NET Developers, functional programming in Python, F#, and C#, the Eve REST framework and Flask, electronic invoicing, my open-source experience as an author and maintainer in both ecosystems, cross-platform development, and advice to newcomers.

I don’t really know how or why Marco found this relic of mine on Spotify, and I’m not brave enough to ask, but I’m grateful he dug it up. Also, many thanks to Mauro Servienti for hosting the interview.

DotNet Podcast - Interview with Nicola Iarocci (2021)

Hello everyone, and welcome to a new episode of DotNet Podcast, the Italian podcast dedicated to Microsoft technologies and more. You can find us on all major social platforms and podcasting services; all links are on our website, dotnetpodcast.com. Today we’re talking about Python and Eve (or Pyrrest) and, why not, electronic invoicing for .NET.

Today I have the pleasure of having Nicola Iaroci with me. I met Nicola at the Italian edition of SoCraTes in Rimini a few years ago. Nicola is the classic jack of all trades: developer, entrepreneur, fitness enthusiast, consultant, open-source lover, Microsoft MVP, MongoDB Master, and probably something else I’ve forgotten, because the list is very long. In the open source world, he’s known primarily for Eve (we’ll have him explain how to pronounce it), a REST framework for Python, and Electronic Invoicing .NET. I almost forgot: if you want to know anything about how Git works, Nicola knows it all.

Welcome Nicola! Did I forget anything?

Hi, thanks, welcome everyone. Well, no, I’d say probably yes, but I can’t tell you what, so I’d say the introduction is perfect. Thanks.

This podcast has always been oriented toward the .NET world, though lately we’re branching out a bit into various technologies and even topics not necessarily technical. But assuming our listeners are primarily .NET developers, briefly, what is Python, and why should or could a C# .NET developer be interested?

Sure, so first of all, Python fundamentally, let’s say from a general point of view, is not that different from the languages we’re used to in the .NET world, particularly C#, in the sense that it’s still a high-level language, object-oriented from its foundations, let’s say, from its roots. The main difference, perhaps, is that it’s fundamentally interpreted, so there’s an interpreter that executes the language and programs, although it’s also possible to do JIT compilation, especially for performance reasons.

I’ll add an important note because people generally think that a dynamic language is not strongly typed, which is not true. Python is a strongly typed language, but it has dynamic semantics, so type checking is still possible. I always clarify this because those coming from C-derived languages often think it’s very similar to JavaScript, when in reality, there are clear differences.

It’s certainly a language designed to be more approachable for a general programmer or even a beginner, and this probably also explains why it’s had such success, I’d say almost incredible success, for example, in the world of scientific research, numerical computing, in the financial world and for those who need to do numerical analysis. Because, among other things, in that particular area it’s a language where performance is excellent, not because Python is a fast language (it’s not at all, being interpreted), but a very beautiful thing about Python is that you can write its libraries in C, with bindings that practically allow you to use libraries written in C as if they were Python libraries.

And this is the trick that allowed all these tools for numerical, scientific, and financial analysis to be written in a language that’s simple to grasp, even for those who perhaps aren’t born developers like us. For example, think of a researcher, a scientist locked in their laboratory who can understand Python, approach programming and immediately have powerful tools available, yet the language remains easily readable and understandable. It’s a perfect language, for example, for learning to program in general.

Then what else? Like our .NET languages, it obviously supports modules and packages. There’s an equivalent to NuGet: PyPI, where you can now find hundreds of thousands of packages to install.

One thing that personally interested me a lot about Python when I started studying it was the fact that it was cross-platform from the beginning. It was a language that, when I started studying, was already twenty years old, so very mature. The base class library, or something like that, so it comes with a lot of included material, a bit like .NET at this point with .NET Core. Practically, whatever you want to do, there’s certainly a standard way that allows you to do it.

The fact that it was cross-platform for me then was very interesting, because I came from the .NET ecosystem, which, when I started looking at Python about 10 years ago, was still absolutely out of the question. Then the world is made to change rapidly; it would also be nice if you let me tell you what happened in those years, but we probably don’t have time. But fundamentally, yes, the fact that it was open source from the beginning, 20 years ago, I really liked a lot.

I must admit that in those years we fundamentally had to port our application, desktop applications, standalone, networked applications, and I was a bit frustrated by let’s say the old Microsoft world, to be clear, which sounds strange coming from a Microsoft MVP, but this is also to tell why I became a Microsoft MVP after having abandoned Microsoft, I must say also quite disappointed, and I moved to the Python world. Then I was noticed in the Python world by Microsoft people, who sort of recruited me into this part of the MVP world.

Then I actually went back to doing a lot of C#, F#, in short, working in the .NET world. Actually, if I have to be honest, nowadays about 75-80% of my work is in C# and F#, and the remaining 20% is maintenance of my open-source Python packages.

So yes, let’s say this: Python, personally, gave me new perspectives to answer your question. You know, when you’re always inside, you always drink from the same source, you always drink the same water, and certainly it’s excellent water, but you don’t know the other flavors, the other tastes.

I’ll give you a trivial example: in C#, historically (keep in mind that I’m a certain age, so I started writing C# really too many years ago), I remember this episode that always marked me. They had always taught me not to use try-catch if possible because exceptions in .NET were performance problems; it was a bad practice. In the Python world, it’s exactly the opposite: you write code without too many guards, you focus on the logic that solves the problem, and you catch and handle errors as needed.

Going back to the C# world, I started using this thing a lot in Python and used it aggressively, even to the dismay of my colleagues who had stayed in the world. And this is simply an example. Then, in the meantime, obviously, in these 10-15 years, try-catch is no longer a problem like it was 15 years ago.

I brought some things from the Zen of Python, a kind of decalogue that Python programmers try to follow, into the C# world. For example, “Explicit is better than implicit,” which is a classic of the Python world. So, rather than write one more line of code, make your intention exactly clear, rather than hiding things behind too many automagical things.

So, all these little things here. Now, yes, the .NET world has given us a lot, it’s not even worth saying. Actually, now they’ll do the same thing here, too. When I moved there, and especially there, I think C# was already very mature. So I found myself… I remember another thing: when, for the first time, I didn’t understand how a REST call worked in Python, and I realized I could go to GitHub to see the source code of the framework I was using, which was Flask.

It’s a bit like if I, 15 or 10-12 years ago, had been able to look at the ASP.NET source code to understand exactly why things weren’t working as I thought they should. That thing for me was, the English would say, paradigmatic. It really opened my heart, and I understood that was the world I wanted to be in. Then you see, many of these arguments are a bit, let’s say, weak today because C# and .NET are now fully open source. But better this way, thank God. A lot has changed in recent years.

Nicola has a t-shirt I couldn’t see well at first; it has the Superman logo, but it’s actually an F with a hashtag, so it’s an F# t-shirt. Is there a relationship between the functional world and Python, or is Python a traditional object-oriented world, let’s call it that?

Well, that’s a good question. Actually, Python was born entirely and purely object-oriented. So anything you use in Python is an object, but it has a strong predisposition also toward functional programming, let’s say. I have to be honest: if I want to do good quality functional programming, F# is a thousand times better than Python, but you can certainly do it.

Let’s say this is probably interesting as well. I wouldn’t have arrived at F# (let’s say) if I hadn’t gone through Python. Always for the discussions I was telling you about before, the approach in Python is to simplify things, break them down into… well, these are good practices used in all programming languages. But there’s a tendency, let’s say, to use functions rather than magic classes that incorporate state, for example.

In Python, it’s quite common, even if not everyone does it, because, being a complete object-oriented language, you can perfectly well maintain state inside objects as you would in a C# class, in a classic way. But you will surely have noticed, and I think the listeners too, that the trend in C#, as well as in recent versions, is toward functional programming in a manner I’d say is almost impetuous, so records, immutables, many other things like enhanced lambdas, etc., etc.

So, coming back to the .NET world from Python, I became much more curious about F # than I had been 10 years ago. So yes, in Python you can do decent functional programming and organize your code in a functional way, but it’s certainly a language that remains object-oriented, let’s say, in its orientation.

And it’s not even, I have to tell you the truth, compared to C#, which has been adopting so much from F# in the last two or three versions, Python is not making this huge effort to become functional, and in this, I have to say I quite agree. I really like the evolution of C#, especially for me, who also obviously does F#. I think I would really like also like to know how to say, I’ve also tried actually in some conferences to do outreach in this sense, to encourage the C# developer to go toward functional, and also to illustrate F#, the principles of F#.

But I also appreciate the fact that in the Python world, they said, “ok, Python at its heart is an object-oriented language and its focus is there, let’s improve that type of paradigm. There are other languages that do well. And in the .NET world, this is very true: there’s C#, and we have the enormous fortune of also having F#.

Now there’s been an attempt at hybridization, let’s say, or rather to bring into the C# world everything that’s beautiful about the functional world, which sure is appreciable. I’m happy, I’m already using it a lot. But I think it can also create a lot of confusion for a newcomer to the language, who perhaps comes from object-oriented programming and finds themselves with many functional things and doesn’t quite understand what to do.

I adore the latest versions of C#, and I’m very happy about it, but what is the specific direction of C#?

Yes, I also have a sort of adoration for the latest version of C#, but I realize that having behind me… I started writing C# code in 1999 with Beta 1 of the .NET Framework. So I’ve been through all of them, so for me, the novelties are small things compared to the twenty years that have passed. I realize that the problem might be that, for a new developer who arrives today, they face, fundamentally, an almost insurmountable mountain to climb.

That’s exactly what I meant, so adding then also, let’s say, this cognitive weight. One could ask oneself why can’t I use a class instead of a record, for example, but the same thing, what’s the fundamental difference? Yes, there are reasons, but one of the really strong things about Python is its ease of access for those starting in programming.

I’ve seen that Microsoft is making huge efforts in this regard, with video series on YouTube and sites to welcome people to C#. And I, in particular, who come from the world, I’m let’s say with feet in both camps, so I’m well known in the Python world too, so much so that I’ve also done presentations where I present Python to the C# programmer and C# and .NET to the Python programmer.

Especially now that C# is finally cross-platform and open source, it becomes much more… before, it was unthinkable to talk to a Python programmer about learning C#, which was only Windows and only .NET Framework, standalone, etc. It was really unthinkable. Now some cracks are opening, I’m trying to slip in there, but it’s very hard because clearly we have let’s say an image, we’re known as dotNetters in quotes for enterprise, for PA… and heavy stuff that’s installed on Windows, the GAC, all these problems that existed in the Windows world.

Many times, making people understand “look, now you can take a Linux machine and run a web application written in C# with the same ease as you would with Node or Python” is really a message that leaves people open-mouthed, and they don’t believe it, you have to show them. So the work to be done on our part is really a lot.

You touched on Python at the beginning of the discussion, saying, if I remember correctly, you used Flask as a framework, which I assume is a sort of counterpart to ASP.NET. More or less? What relationship is there between Flask, ASP.NET, Eve and the REST world in general? And why did you feel the need to write a framework for REST for Python?

Well, that’s an excellent question. When I came to Python, there was a framework called Django, which was very widely used and very famous, and did the equivalent of a modern ASP.NET, an ASP.NET Core. But it was too complex, it was exactly the classic behemoth in the .NET style, because I’m talking about the old way, where you had to take everything that came or what you needed. What I needed was to practically implement the equivalent of a Web API application we have in the .NET world, so the controller… well, there’s no concept of controllers, but it’s the classic REST API concept.

So, Flask actually defines itself as a REST API, but it’s not a true Web API. It’s more of a .NET type framework. When I explain to C# programmers what exactly Eve is, I make this kind of comparison: imagine a Web API .NET, well, Eve gives you that with the addition that there was this attempt to make it very easy to put online when you need an API that’s basically a front-end for a database, so not much business logic but CRUD operations and things like that.

So, in this sense natively, Eve, besides providing the REST interface toward clients which by the way is strongly opinionated (that is, keep in mind that when I wrote Eve it actually was born as an internal project for my company, so we knew exactly that a POST would create a record, a PUT would replace, a PATCH would modify), I didn’t create a framework that lets you do whatever you want, precise choices were made about how verbs work, how modifications work.

And fundamentally, if that’s okay with you, my framework probably lets you work agilely and quickly. If you don’t agree, use Flask or another framework, or build your own. And so yes, I’d say the relationship is this: Flask could be, let’s say, the core of a Web API. Look, it comes to mind now with .NET 6 this new interesting feature, which are the minimal APIs.

If you take the Flask homepage and look at the quick start example, it’s maybe ten lines of code, and you take a snippet that Microsoft is publishing on its social media (David Fowler comes to mind on Twitter; every now and then, he posts screenshots of these minimal APIs), they’re almost overlapping, it’s incredible, right?

And so the work they’re doing now in .NET 6 with minimal APIs is to remove from the logic let’s say MVC and everything that was behind it, remove the routing and those things from verb management and then put it all in your hands so that you can make a pure API without the behemoth, without having to create a controller and so on.

So, Flask practically gives you that base that we’ll now have in .NET 6. So, this, and minimal APIs are something that in my opinion can be very interesting for those who want to start using C# for example to make Web APIs, because when I came from C# I had the whole behemoth world let’s say to manage and I found Flask which gave me the building blocks to build what I wanted, it was exactly the reason why I went to use Flask and Python.

So finally in .NET 6 we’ll have something very similar and it’s really impressive to compare Node code, Python code with Flask and .NET 6 minimal API code and see that the effort is very evident from Microsoft to make it interesting also for those coming from other stacks where all that, sorry if I repeat myself (I call it the behemoth), all that complication… so you have to have a controller, you have to have a view, you have to make a site, you have to have in short the data layer, all these affairs that certainly come from data user, among these and so on, are being somewhat thinned out to make everything lighter and it will be very interesting in my opinion.

Exactly. One thing I noticed is that, finally, for the first time with .NET 6, the empty project template is truly empty.

Exactly, Flask has been like that for me: you just need a .py file with your four lines of API initialization, and then a nice little function that responds to a GET, and you’re done. Now we’ll have this in .NET 6 too, which is really interesting to me. Hopefully, then we’ll be able to make the rest of the world understand that .NET is no longer what it was 10 or 15 years ago, and here I emphasize this is the big commitment, in my opinion, the real challenge to win: communication.

But I have to say that on this I’m optimistic for another reason and that’s performance, that is the performance of .NET Core, multi-framework, cross-platform are really interesting and this is the reason why I went back to doing a lot of C# actually, because with .NET Core I have cross-platform and performance that I don’t have in Python and now I’m also starting to have a language, a stack that’s agile and very similar to what I used in Python, what I use in Python or in Node for example. But let’s not talk about Node, otherwise we’ll have a classic flame war.

Ok, in all of this, how does Electronic Invoicing .NET fit in?

Well, Electronic Invoicing is also here, the result of my Python experience, that is, in Python I embraced open source to the point of becoming the first creator and then maintainer of some open source projects, and I saw the incredible potential that comes with letting’s say, the benefits you have from making your code public.

And so going back to work in .NET (we’re talking about 2014-2015, because electronic invoicing, it must be said, is something that was imposed by law, I think in 2019, now I don’t remember, but actually the technical specifications were already in place for some years for the public administration world). So we had to do this thing internally.

Fundamentally, for those who don’t know the product, FatturaElettronica.NET is simply a deserializer and serializer of electronic invoices that puts in your hands an instance of a class that represents the electronic invoice and that, very handily, also forces you to validate it according to the technical specifications. So you can, before submitting your electronic invoice to the Revenue Agency, etc., already know whether it will be accepted, identify any errors, and tell your user how to correct them. This is the version in a nutshell.

And so when we did this and I started working on this project I proposed to colleagues to try to leave it as open source because it was evidently something that would become useful certainly to a niche compared to Eve or Cerberus which is another project I have, but because meanwhile it’s only dedicated to the Italian public and not to the whole planet let’s say, but also certainly only to those who develop management software etc., etc.

But why not? It seemed to me an interesting little game, also because, I’ll tell you the truth, it may seem a bit naive on my part, but it seemed to me the way to show and make .NET developers understand that open source, even from us peons, is perfectly possible. If you have an interesting project that can be useful, you can do it even if you come from the let’s call it closed enterprise world, like that of .NET, and it seemed to me a way to give an example and encourage others to take the same step.

In short, at the beginning, it remained quiet for two or three years, and we used it only by us and four other unfortunate souls like us. Gradually it gained traction, it clearly became a very important thing when the law then imposed electronic invoicing and I must say we had the advantage, you see there too, of being a project that by then was already a few years old (it was from 2015 I think I left it open source), it was already mature enough to be adopted by those who were panicking because they found themselves with three months to implement something and so after that contributors arrived.

The thing about the whole Electronic Invoicing project that gives me the most satisfaction is the fact that there are .NET developers and it’s evident from how they make pull requests and how they contribute to the code that they’ve never done it before, but with enthusiasm and obviously out of necessity they get to work, they throw themselves into it and they’ve also contributed pieces of code that have proven very important.

So in my small way, in the .NET world, what usually happens in other worlds I come from, or rather that I return to, so Python, is happening.

This is a fascinating thing that recently happened to me too because I have several open source projects, one recently… a guy who I later discovered was Australian started opening issues, then a couple of pull requests and then more and now I’m evaluating within myself whether to make him a maintainer because he’s contributing in a very important way and if the project hadn’t originally been open source because it didn’t need to be open source, originally there wouldn’t have been all the contributions that I honestly had never thought of, they didn’t make much sense.

Absolutely, I confirm and my experience too. To give a practical example on Electronic Invoicing, a guy comes to mind who contributed… I think I implemented serialization in JSON, in addition to XML, for these electronic invoices, but I wasn’t at all interested in deserialization. It’s a guy… moreover, it’s also the contract, the pull request arrived with this feature completely implemented, and so now I support bidirectional JSON or the famous digital signatures, which are a very complex topic.

Electronic invoices can be sent as pure XML or with a digital signature. Actually the large part of those features was contributed from the outside. They’re important features you see that I didn’t work on, clearly, then I contributed to quality control, everything you want, but giving me so much value to the project and obviously to the community.

And among these contributors, there are precisely new contributors who, often precisely because of their enthusiasm, are the ones who in the end contribute the most, with also those more interesting features.

If I have a minute to tell another episode that comes to mind, in Eve, there was this guy. I had already been on GitHub for 4-5 years; it was going very well, and it had widespread adoption, which I was very proud of. After which, this pull request from this guy arrives, with, I remember, something like 800 code changes, so a monster pull request. Going to look at them, they were all changes to comments, what in Python are called docstrings, they’re practically the inline documentation that you put as a comment that then serves developers to understand your code.

They were full of typos and errors because I’m obviously not a native English speaker, so there were grammatical errors, typos, and other issues. It was super embarrassing because I realized that my code with all my errors had been seen by who knows how many tens of thousands of programmers, who knows how many laughs they had at my expense.

But the beautiful thing about this contribution was that he wrote to me, “look, I’m not an expert programmer, so I thought of contributing in this way. And from that day, the Eve documentation has enormously improved, so that a contribution which is not a code contribution, from an absolute non-expert for me personally, for the whole project, has had and still has an immense value.

So this is also a message, I always tell this episode. There are opportunities to contribute in a significant way for anyone, from the super programmer (the famous “10x developer” if you also say it in Italian), but also those who have just started can help and indeed, they should be encouraged because they’re the ones who have so much enthusiasm, among you who then give them confidence, the problem is that after a while being a maintainer becomes very demanding and you start to delegate to someone who I’m not saying replaces you, but maybe even yes.

In fact, the next question is precisely that: if I understood correctly, both open source projects have some relationship with your work, but obviously, the cognitive and managerial load is significantly higher than what your work would generate. So what is your experience in the world of open source governance, and in general, managing projects that start maybe a bit like, I don’t know, what we could call a playground, and then explode in your hands, and you say, “oh my God, now what do I do?”

Yes, it’s a gigantic problem actually because with Eve, thank God, we’ve now reached a maturity and stability of the framework that allows me to live quite on my laurels, but attention, simply because I chose that the project is mature and stable, and I don’t want to take it, say, to a version 2.0. If I were like .NET can be forced every year to make a new major release, it would obviously be my job 24 hours a day.

I also confess that to solve this problem I also tried to make Eve somehow profitable, to have an income from the project itself through donations, like “buy me a coffee”, but not with the objective of becoming full-time living, but with the objective of being able to pay myself half a day of work per week to dedicate explosively to the project, because if I could have dedicated, say, every Friday 8 hours to open source, you would certainly have a project 10 times more beautiful than what it has now, same thing with Cerberus, same thing with Electronic Invoicing.

As you can imagine, this thing didn’t have much success because everyone is very good at installing packages, but when they have to put their hands in their wallets, they’re much less good at it. Maybe there was gratitude for receiving this, which is very pleasant, but the long-term strategy is missing… another topic; we don’t want to discuss now how to maintain…

There comes a moment when the cognitive commitment is really great, you have so much other business and other work types to deal with, and it becomes a problem. The solution, for example, I was lucky because, a bit like what happened to you, one of these contributors, gradually, I really let him, even in a somewhat sly way, I let him take control, but it started with minimal pull requests, then he gained courage, I sort of nurtured him.

In the end when I was certain he knew the codebase very well, he was also an expert, in short fundamentally Cerberus I left in his hands 100%, so I follow it from afar, I receive email notifications, if he has some important modification to make he asks me for advice, but actually he even has the rights to publish updates and so let’s say now for me I’m simply a father watching from afar the child grow, so to speak.

For Eve, I’m still the main maintainer, but as I tell you, the choice of Eve was perhaps made with the idea of being able to continue living and earning, let’s say, my salary. It was ok. The product is mature. From now on, we accept pull requests for bug fixes or mature new features that make sense to incorporate, but I don’t foresee further development in any direction.

Electronic Invoicing, for me, is strategic because we use it every day in the company; we ultimately make management software, so there I remain the maintainer, and I do it gladly because there’s a necessity.

So, in general, hopefully in the .NET world too, we’ll arrive at this… so, many have told me “how nice, I’ll definitely make a donation, we’ll make a donation for Electronic Invoicing because we use it in the company”, I think not even one has arrived. So in this certainly the .NET world still has to mature and become aware of the fact that a long-term investment for a product you use every day and that gives you income in the end somehow (otherwise you wouldn’t use it), it makes sense to think about contributing to the long life of the project to not risk finding yourself at a certain point with the maintainer who took the motorcycle and went to the Himalayas to climb and you have a critical project maybe that’s no longer updated, that has security problems, etc. On this, there’s work to do.

Ok, to conclude, last two quick questions. Still staying in the open source world, if you had to give advice to someone who wants to start an open source project and advice to someone who wants to contribute to an open source project.

Yes. So, for those who want to start, I’d say don’t worry. In the sense that, as you said before, there were projects you had put open source that actually didn’t need to be. “They didn’t need to be open source.” This is, the perception is a problem of really, I can’t translate it into Italian, but it’s a problem of wrong perception, in the sense that actually there’s certainly someone on planet earth who has to solve the problem that you have to solve at that moment.

So even projects, if you want trivial small ones that serve little purpose, thanks to potential algorithms and tools, exposure from GitHub, from Google and so on, rest assured that if you’re doing a project for electronic invoicing, someone else has that problem. So the first thing is that the history of open source is full of projects born as hobby projects, put on GitHub almost like this for convenience, because this way I have a remote backup, which actually exploded in the hands of maintainers because they were successful.

But even if they weren’t successful, it serves you in the meantime to acquire the know-how, which is not small, and to gain experience in doing so and overcoming the shyness of sharing your code and showing it to the public. So, this is the other very important thing. My programming style has evolved a lot, thanks also to seeing what others do.

Sure, it can also be, how to say, sometimes not humiliating, I’d say, but certainly it puts you in your place when you see that your code has been refactored in a much more performant or more elegant way by others, but it’s there that you learn. It’s a bit of the discourse about always drinking water from the same place I was telling you about. So certainly I’d say first thing, don’t be afraid, throw anything on GitHub even if the code is not the best… sorry… don’t stay there to refine it, to clean it up, because maybe someone else will do it for you, who will even be grateful to you.

The other thing, probably, is… for those who want to start contributing instead, as I was saying before, there certainly are projects of the day that you use, even in professional frameworks… I’ll also make here, I’d say, another episode. When I was preparing a talk on Python and explaining how to use Python inside Visual Studio, which few people know, you can use all the Visual Studio features you’re used to to write Python code. I realized that the official documentation on the Microsoft Visual Studio site had some shortcomings in the pages dedicated to Python. And so what did I do? I made a fork of that documentation, which is now finally all on GitHub. I contributed a fix to this documentation.

And now, I don’t know if it’s still like this, but two or three years ago, if you went to the official Microsoft documentation for Python, you’d find my little face among the contributors. So there you go, I made a contribution even to an official Microsoft project. Free, because it’s the tool that I use every day.

I’m convinced that a large part of us developers have this experience of noticing a small error, a small problem, or a specification that doesn’t necessarily require an extremely complicated algorithm to solve. It can also be, as I was telling you in that other episode, a docstring, a comment with a typo. They’re all experiences that add up, that help you gain familiarity with the context, and so don’t start maybe by contributing a Fibonacci optimization, because I don’t know what.

So, really start from the trivial, from the simple, from what you do every day, because you know it very well and you’re already competent. After which, there’s time and a way to gain confidence; many of these my contributors, as I was telling you, start like this. Then, gradually, they gained courage and went to examine the deeper code, to solve the more complicated issues that I myself didn’t feel like going to look at, because I knew it was a hornet’s nest and the willing one arrived who did it in my place, riding the enthusiasm, which maybe I don’t have anymore, but they have it, the positive energy to use, to spend.

Good, very interesting, I agree completely. It’s one of the most common barriers to entering the open source world, precisely because itis tied to the idea that “I have to contribute,” and you have in your head that the contribution must be substantial, when, in the end, it’s often a small thing.

Exactly. The novice contributor, let’s say, is intimidated and thinks they should contribute something fundamental, but it doesn’t make sense to contribute. On the other hand you have a maintainer who is literally at the window waiting for those who contribute the small things to arrive, because they’re those, many small things that then are small things relatively (it’s the perception of the remote developer that it’s a small thing), it’s all work that you take away from the maintainer and that you take away from the community.

So even the very small thing I can’t wait for those more sought-after so-called small things to arrive. Actually, it has great value, as seen in the example of the 800 typos in the Eve documentation.

I thank you for your availability. It’s been a very pleasant chat. I hope to have you as a guest again, and as we shared before we started, we discussed an interesting topic that could be fitness for developers.

If you decide to do it, call me. Thanks so much to you and your whole team for what you do with this podcast. You do an excellent job.

Thanks so much, thanks so much and thanks again for your availability. See you next time, hello everyone.

Bye-bye, bye everyone, thanks.

Exactly one year ago we were here, in this same room, at the same conference, presenting C# 12. Some of you in the audience were present back then. If so, please raise your hands. Twelve months later, here we are again, looking at a new version of C#. It’s the new normal; this has been happening, give or take, since the advent of .NET Core and C# 8 in 2019. Previously, C# had a new release every 2–3 years, so the release rate has doubled or even tripled recently. Is this good news? If you’ve followed forums or social media, you might have noticed some controversy about the topic. The main complaint is that the language is changing too quickly, “chasing trends,” with no valuable addition to its core.

Most of these complaints come from old-timers around my age (maybe even ten years younger because I’m seasoned) and have been in the .NET environment for many, perhaps too many years. There’s always a certain inertia, a form of resistance to change, especially when it’s rapid. But I’m seasoned enough to remember when complaints went in the opposite direction: back then, the .NET Framework (the historical, monolithic, Windows-only version) moved like a dinosaur while the world was racing ahead. New languages were blooming. Old competitors were evolving at double or triple the speed, constantly innovating, and—this is key—attracting hordes of developers. There was a critical moment when this attraction became so intense that more and more developers set aside .NET and C# to explore new directions. I know because I was one of them.

Around 2010–11, I was set to create a new, rather complex platform of REST services, and instead of reaching out for my usual .NET toolchain, I chose Python. That marked the beginning of an adventure that lasted years and included the unexpected release of some reasonably successful open-source Python projects. The reasons I decided to abandon .NET and C# were several—not least the frustration with the lack of transparency and a clear path for the .NET ecosystem, its languages, with oh-so-many frameworks enthusiastically presented and then abandoned, changes of direction, and above all, in my case, it all being closed source, which didn’t allow me to dig deeper and understand why certain things didn’t work as expected. I clearly remember when I was writing my first REST service in Python and realized that in this new ecosystem if I didn’t understand what was happening behind the scenes (in my case, with the Flask framework), I could quickly look at what was going on because the entire Flask source code, like Python’s for that matter, was available not only for consumption but it was also open to contribution. Coming from the enterprise closed-source world, it was an empowering sensation.

The discovery of Flask was an absolute revelation, not for its intrinsic features (which were great) but because it was just one of the many options. In Python space, there were dozens of web frameworks at varying stages of maturity. There was a choice and often many different approaches to solve the same problem. I could experiment freely and decide what was best for my use case. Not only was I facing a vast and diverse world, but I could also use the operating system I wanted. Linux was much less demanding, let alone less expensive, for deployment than Windows, and behold! I could use a Mac for development. Open-source, cross-platform, with a vast community not only adopting the language and the standard library but constantly forging new solutions, making them available to the same community, almost always for free. It was the way forward.

I envied that such a thing was unthinkable in my world. But unbeknownst to many, Microsoft was watching and taking notes. To the best of my knowledge, it was mainly the developers inside the corp —the dev team—who, glancing out of the ivory tower, began a campaign of internal lobbying, initially scattered and disorganized and later increasingly coordinated, which in turn led to endless meetings, discussions at coffee machines, and gradually, slowly and then more rapidly, to the advent of the .NET Core project. The metaphor of a snowball slowly rolling down a slope until it becomes an unstoppable avalanche perfectly applies here.

So, years after my departure (not an actual departure—I still worked in .NET for our legacy products), a new and unexpected .NET appeared on the scene. It was open-source, cross-platform, and open to external contributions. We could and perhaps should have a lengthy discussion on the openness to external contributions, but we can all agree that a revolution occurred and was historic in scale. At the same time, Microsoft opened up to other stacks, mainly because of Azure. I was shocked when I was proposed for a Microsoft MVP Award for my work on Python, not C#, at a time when Python had little to nothing to do with Microsoft. It made sense, as there was an urgent need to speak to developers outside its ecosystem—and perhaps even more so to those like me who had left: Hey, look, we’re back, we’re on track, and we’re not evil anymore.¹ 

And there I was, finding my old stack (which I secretly, I admit, considered only museum-worthy) back to relevance, competing on equal footing with the rest of the scene. The delay was costly, though. Even today, I meet colleagues who think modern .NET is just a new version, if not a simple rebranding of the Windows framework of old, and C# is more or less the same, way behind the new kids on the block. It’s a shame, and there are responsibilities. Some choices could have been bolder and more disruptive, starting with naming the new framework—but that’s another story.

Today, I create REST services with Minimal APIs on my Mac and deploy them on Linux via Docker at zero or near-zero cost, just as I would with Python, JavaScript, Rust, Go, or any other stack. The performance is far better than Python’s (C# REST services make circles around Python’s), and the toolchain is rich and powerful, especially around the command line, while many think .NET is still a GUI/Windows thing. Quick release cycles are essential to compensate for lost time (and there was lots of it) and stay on the cutting edge, sending a continuous signal that the platform is alive, thriving, and constantly expanding.

Aldus Manutius, the renowned Venetian printer and publisher of the Renaissance, adopted the Latin motto Festina lente, which translates to Make haste slowly or Hasten slowly. This paradoxical phrase encapsulates achieving careful, deliberate progress quickly and precisely, balancing urgency with caution. I feel that, consciously or not, the .NET team is on track with Manuzio’s goal: they iterate rapidly to achieve progress, balancing urgency with caution.

Nowadays, both .NET and C# focus on performance and while there’s room for growth, the current achievements are extraordinary. We’re competitive with most stacks, if not significantly ahead of them. Frequent, more minor C# releases allow for quick adjustments. Attentive developers adopt them continuously. Meanwhile, those who aren’t in a rush (probably most of Microsoft’s long-time customers, slow-moving conglomerates and the like) benefit from performance gains and technological advantages (multi-platform deployment!) at a low cost because, while the framework and language evolve, great effort is put into preserving backward compatibility. In most cases, migrating to .NET Core and newer versions of C# requires minimal effort.

C# 12 introduced two significant features: primary constructors and collection expressions, with the latter being predominant in terms of syntactic, semantic, and performance importance. They weren’t the only new features but certainly the key ones. C# 13 innovates further but subtly—there’s less syntax and more semantics, building on last year’s new features. The improvements may be less flashy but guide developers in the right direction, often ensuring better performance at zero cost, sometimes even without us having to do anything. As we shall see, it happens because in recent releases—let’s say the last two or three— features were introduced primarily to improve the framework, which is also written in C#. Our higher-level applications benefit from all of this. It is a pattern we’ll observe repeatedly throughout this presentation.

The scenario goes like this. I have an ASP.NET Core app that authenticates with Open Id Connect. It receives a bearer token from the authentication server. Besides OIDC claims, this token has been forged with additional custom claims for use in the app. However, only ODIC claims exist when I parse HttpContext.User.Identity.Claims in my middleware. If I retrieve the token with HttpContext.GetTokenAsync and decode it, I confirm it contains all the claims I need. Where have my custom claims gone? Or, how can I get User.Identity to provide them along with the OIDC ones?

As it turns out, one must hack them into the User.Identity.Claims collection by hand. That’s done by leveraging the OnTokenValidated event handler like this:

authenticationBuilder.AddOpenIdConnect("oidc", options =>
{
    options.Authority = "authority";
    options.ClientId = "client_id";
    options.ClientSecret = "secret";
    options.ResponseType = "code";

    ...
    options.GetClaimsFromUserInfoEndpoint = true;
    options.SaveTokens = true;
    options.Events = new()
    {
        OnTokenValidated = context =>
        {
            // adds custom claims from the token into Principal.Identity
            if (context.Principal?.Identity is not ClaimsIdentity claimsIdentity) return Task.CompletedTask;
            
            var accessToken = context.TokenEndpointResponse?.AccessToken;
            if (string.IsNullOrEmpty(accessToken)) return Task.CompletedTask;
            
            var handler = new JwtSecurityTokenHandler();
            if (handler.ReadToken(accessToken) is not JwtSecurityToken jsonToken) return Task.CompletedTask;
            
            foreach (var claim in jsonToken.Claims)
                if (claimsIdentity.Claims.All(c => c.Type != claim.Type))
                    claimsIdentity.AddClaim(claim);

            return Task.CompletedTask;
        }
    };
});

Is there a better and less hacky way to achieve the same result? Please let me know.

• I love collection expressions. Like primary constructors, collection expressions will see a significant adoption in the long run.

• Collection expressions introduce a new way to initialize common collection values in a terse, unified syntax.

• This is how we initialize collections today:

var x1 = new int[] { 1, 2, 3, 4 };
var x2 = Array.Empty<int>();
WriteByteArray(new[] { (byte)1, (byte)2, (byte)3 });
List<int> x3 = new() { 1, 2, 3, 4 };
Span<DateTime> dates = stackalloc DateTime[] { GetDate(0), GetDate(1) };
WriteByteSpan(stackalloc[] { (byte)1, (byte)2, (byte)3 });

Notice how the code is diverse depending on the type and the context. It is also verbose. Look at how we initialize an empty int array (second line); it’s lengthy and starkly contrasts with the previous line, where we initialize the same type with some actual values. In many situations, casting is needed; again, take a look at the WriteByteArray and WriteByteSpan calls.

• With collection expressions, it becomes like this:

int[] x4 = [1, 2, 3, 4];
int[] x5 = [];
WriteByteArray([1, 2, 3]);
List<int> x6 = [1, 2, 3, 4];
Span<DateTime> dates1 = [GetDate(0), GetDate(1)];
WriteByteSpan([1, 2, 3]);

We enclose items within square brackets, and that’s all. An empty collection is empty brackets. We can, of course, call functions or use variables.

• In many scenarios, the compiler will perform several optimizations. It can allocate the correct capacity or avoid copying data when unnecessary. The compiler can do that because the supported collection types are well-known and have been for a long time. We get these performance boosts for free when we switch to collection expressions.

• Let’s look at that WriteByteArray call. Let’s say that at some point, maybe months or years after it’s been used in many places, we decide to refactor the method and change the argument type from byte[] to int[]. We’d have to refactor the old-style caller to eliminate the casting, which is now an error. We don’t need to do any fix with collection expressions as they come with enhanced inference that will resolve the casting for us.

• On the first line, we’re initializing a new array (we aren’t calling a method with a signature), so with collection expressions, if we try to use var, it won’t work. In that case, we need to be explicit about the type.

• The spread operator allows us to insert variables and constants and to sort of “unroll” another collection within the new one, and it does so with optimal performance.

int[] numbers1 = [1, 2, 3];
int[] numbers2 = [4, 5, 6];
int[] moreNumbers = [.. numbers1, .. numbers2, 7, 8, 9];

foreach(var number in moreNumbers)
    Console.WriteLine(number);

It would be nice if lambdas were allowed in collection expressions, like in other languages (Python), but that’s not yet an option.

• What about custom collections? But let’s imagine I have built a LineBuffer class that inherits from IEnumrable<chrar>; it offers some custom features over its base class. I get an error if I try to use collection expression syntax on it. It is not a common .NET type, and the compiler doesn’t know how to go around it.

public class LineBuffer : IEnumerable<char>
{
    private readonly char[] _buffer = new char[80];

    public LineBuffer(ReadOnlySpan<char> buffer)
    {
        int number = (_buffer.Length < buffer.Length) ? _buffer.Length : buffer.Length;
        for (int i = 0; i < number; i++)
            _buffer[i] = buffer[i];
    }

    public IEnumerator<char> GetEnumerator() => _buffer.AsEnumerable<char>().GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => _buffer.GetEnumerator();

    // etc
}

// this causes a compile error
LineBuffer line = ['H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!'];

• We can support collection expressions in our custom types, though. It’s a two-step process. First, we implement a builder method, then decorate the class (or struct) with a CollectionBuilderAttribute. The attribute maps our type to the builder method.

[CollectionBuilder(typeof(LineBuffer), nameof(Create))]
public class LineBuffer : IEnumerable<char>
{
    private readonly char[] _buffer = new char[80];

    public LineBuffer(ReadOnlySpan<char> buffer)
    {
        int number = (_buffer.Length < buffer.Length) ? _buffer.Length : buffer.Length;
        for (int i = 0; i < number; i++)
            _buffer[i] = buffer[i];
    }

    public IEnumerator<char> GetEnumerator() => _buffer.AsEnumerable<char>().GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => _buffer.GetEnumerator();

    internal static LineBuffer Create(ReadOnlySpan<char> values) => new LineBuffer(values);
}

The official documentation says the builder must be named “Create,” but that’s false. We can name it however we want as long as it matches the attribute (it’s probably still worth adhering to the suggested practice.)

• Adding collection expression support to custom types is helpful in your codebase, even more so if you’re a library author.

• The syntax of collection expressions is symmetric with that of slicing and pattern matching, a nice touch that keeps the language tidy and coherent. Take a look at this pattern matching switch:

public Grade GPA => Grades switch
{
    [] => 4.0m,
    [var grade] => grade,
    [.. var all] => all.Average()
};

• Visual Studio, VS Code, JetBrains Rider and most other IDEs offer full support for refactoring old-style collection initializations to collection expressions.

• What about dictionary expressions? They are common in other languages (again, Python). When asked, Kathrine Dollard of the C# design team answered that they’re thinking about it, mostly trying to understand the best design, so there’s a chance that we’ll see dictionary expressions in the language in the future.

Also see: C# 12 Primary Constructors.

In a follow-up post, I plan to address Collection Expressions (done) and maybe “type any aliases”; this is about Primary Constructors.

• We can now add a list of parameters to a struct or class declaration. This way, we avoid writing an explicit constructor method, sparing us some boilerplate code.

• What I refer to as ‘primary parameters’ are unique in that they are in scope throughout the type definition; this means they can be used anywhere within the type.

public readonly struct Distance(double dx, double dy)
{
    public readonly double Magnitude { get; } = Math.Sqrt(dx * dx + dy * dy);
    public readonly double Direction { get; } = Math.Atan2(dy, dx);
    public override string ToString() => $"{nameof(Magnitude)}: {Magnitude}, {nameof(Direction)}: {Direction}";
    public double Dx { get; } = dx;
    public double Dy { get; } = dy;
}

• It’s important to note that primary constructor parameters are not class members; therefore, this. cannot be used on them. They can be considered static values, but unlike typical static values, they can also be used in non-static methods, offering a unique advantage (some black magic happens behind the scenes.)

• We no longer need to define and assign a type-level field; the compiler will do that behind the scenes when needed; if a behind-the-scenes backing field is unnecessary, it won’t be created.

• Primary constructor parameters don’t become properties and are inaccessible outside the instance. We can create properties to expose their values if needed. Record types are an exception. Constructor parameters become properties with records, and it makes sense because records are generally used as DTOs, whereas we want the option with class and structs.

• Secondary and parameterless constructors can be added to a primary constructor. They must invoke the primary, passing its values along.

public Distance() : this(0, 0) { }

• With primary constructors, we do not have a method body; how do we handle argument validation? One pattern is to perform validation at property assignation.

public string AccountID { get; } = ValidAccountNumber(accountID)
    ? accountID
    : throw new ArgumentException("Invalid account number", nameof(accountID));

public static bool ValidAccountNumber(string accountID) => accountID?.Length == 10 && accountID.All(c => char.IsDigit(c));

• I like this pattern because it brings property declaration and validation close to each other, making it easier to process and reason about the domain logic. When we perform argument validation in an old-style constructor method, we tend to separate validation and declaration, making it difficult to reconcile the two aspects, especially when we have hundreds of lines between constructor code and property declaration.

• Derived types can have a primary constructor, too; it must invoke the base class’ primary constructor.

public class CheckingAccount(string accountID, string owner, decimal overdraftLimit = 0) : BankAccount(accountID, owner)

• Old-style derived types can still derive from a primary constructor type; a regular constructor will invoke the base primary, as we’ve always been doing.

• Regarding inheritance, we can mix and match primary constructor types with old-style types, making it easy to refactor our libraries to use primary constructors. We know that adopters will have no problem deriving from our refactored types.

• Watch out for “nested captures” of primary parameter values in derived types. If both the derived and the base type capture them, and one (or both) change their captured values, we may end up with non-aligned instance values. Roslyn’s analyzer will raise a warning so we can fix our code or mute the alert with a pragma.

• Visual Studio and Visual Studio code offer built-in support for primary constructors (refactorings, etc.) That’s true for JetBrains Rider or any other IDEs leveraging Roslyn.

• The primary constructor’s original implementation dates back to C# 6 in 2015. It was publicly available in one of those version previews for a short period. Then, it was taken back to the drawing board, only to resurface with record types in C# 9 (?) and custom types in C# 12.

Also see: C# 12 Collection Expressions.

I am thrilled to have the opportunity to present at an international conference once again. On May 9th, I will speak at the ABP Donet Conf'24. My session, titled C #12: What’s New and Interesting, is on a topic I’m passionate about.

With the alignment of C# and Dotnet Core release cycles, the C# release cadence has increased (we’re on a yearly cycle now), while feature quantity has reduced for individual releases, which is good. The faster, smaller iterations allow for quicker course corrections, and introducing fewer new features makes it easier to embrace the changes.

The ABP Dotnet Conf'24¹ will be held online on 8-9th May; the lineup and agenda look great, so reserve a ticket before they are sold out, and see you there!

It is in Italian¹ and you need to login in order to see it (sorry, I don’t have control over it.)

PKCE is an extension to the Authorization Code flow to prevent CSRF and authorization code injection attacks. [..] It was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use client authentication (source).

In a nutshell:

1. The client requests a single-use authorization code to an authorization server. In doing that, it includes a code_challenge with the request.
2. The server responds with the authorization code if the client is recognized and authorized.
3. The client requests an access token in exchange for the authorization code. It includes the code_verifier used to generate the original code_challenge;
4. The server confirms that the verifier is the same one used to generate the code challenge; hence, the client is the same.

Plenty of excellent documentation is online (like here.)

I was interested in code_verifier and code_challenge generation. Here’s my implementation:

/// <summary>
/// Provides a randomly generating PKCE code verifier and it's corresponding code challenge.
/// </summary>
public static class Pkce
{
    /// <summary>
    /// Generates a code_verifier and the corresponding code_challenge, as specified in the rfc-7636.
    /// </summary>
    /// <remarks>See https://datatracker.ietf.org/doc/html/rfc7636#section-4.1 and https://datatracker.ietf.org/doc/html/rfc7636#section-4.2</remarks>
    public static (string code_challenge, string verifier) Generate(int size = 32)
    {
        using var rng = RandomNumberGenerator.Create();
        var randomBytes = new byte[size];
        rng.GetBytes(randomBytes);
        var verifier = Base64UrlEncode(randomBytes);

        var buffer = Encoding.UTF8.GetBytes(verifier);
        var hash = SHA256.Create().ComputeHash(buffer);
        var challenge = Base64UrlEncode(hash);

        return (challenge, verifier);
    }

    private static string Base64UrlEncode(byte[] data) =>
        Convert.ToBase64String(data)
            .Replace("+", "-")
            .Replace("/", "_")
            .TrimEnd('=');
}

Usage is as simple as:

var (challenge, verifier) = Pkce.Generate();

In ASP.NET Core you don’t usually need to mess with PKCE as the framework supports it very transparently, but the project I’m working on right now is bare and to the bones, with no ASP.NET Core in sight, so I had to bring my own implementation. Fun stuff.

    await using var sw = new StringWriter();
    await using var w = XmlWriter.Create(sw, new() { Async = true });
    ...
    await w.FlushAsync();
    return sw.ToString();

Will emit this output:

    <?xml version="1.0" encoding="utf-16"?><...

There’s nothing inherently wrong with UTF-16, but XML is usually UTF-8, so one must do something about it. StringWriter exposes an Encoding property, but it is read-only for unknown reasons. One might think that given that the XmlWriter allows setting its own Encoding value, something like this would work:

    await using var sw = new StringWriter();
    await using var w = XmlWriter.Create(sw, 
        new() { Async = true , Encoding = Encoding.UTF8});
    ...
    await w.FlushAsync();
    return sw.ToString();

But it doesn’t. Over time, I’ve seen a few different ways to get out of this dead end, some more performant and or less verbose than others, but my favorite is resorting to a custom StringWriter:

    public class Utf8StringWriter : StringWriter
    {
        public override Encoding Encoding => Encoding.UTF8;
    }

Armed with this, it is trivial, as it should have been from the get-go, to obtain the desired output:

    await using var sw = new Utf8StringWriter();
    await using var w = XmlWriter.Create(sw, new() { Async = true });
    ...
    await w.FlushAsync();
    return sw.ToString();

    // returns  <?xml version="1.0" encoding="utf-8"?><...

The whole .NET framework has seen fantastic performance improvements, top-class multi-platform support, and remarkable streamlining, but some baffling pitfalls are still hidden in some of its less obvious parts. StringWriter not supporting UTF-8 out-of-the-box is one of them.

.NET 6 and its successors have the method built in within LINQ, but I needed it in a .NET Standard 2.0 class library, so I was out of luck. My implementation is simple, not different from others I found online, and should also work fine with old .NET releases. Here it is:

    public static IEnumerable<TSource> DistinctBy<TSource, TKey>(this IEnumerable<TSource> source, Func<TSource, TKey> keySelector)
    {
        var keys = new HashSet<TKey>();
        foreach (var element in source)
        {
            if (keys.Contains(keySelector(element))) continue;
            keys.Add(keySelector(element));
            yield return element;
        }
    }

In the following usage example, I will get back all unique objects from the original sequence, distinct by their Name property:

    var uniques = mySequenceOfObjects.DistinctBy(x => x.Name);

I later went to check the official .NET 6+ implementation. They support an optional equality comparer , which I don’t need, but their base implementation is similar to mine (they use deferred execution as well).

By the way, years after its open-sourcing, I still get thrills when I realize I can always look at, let alone contribute to, the .NET source code.

Installation went well, but then I turned to the command line only to find that dotnet --list-sdks was still and only showing version 7. Yet, the 8 Preview was sitting there at its canonical location at /usr/local/share/dotnet/sdk, where the v7 was also listed.

Puzzled, I tried a few things, but the quick fix was to simply brew uninstall --ignore-dependencies dotnet and, boom, both versions 8 Preview and 7 became immediately available. I suspect that brew uninstall only removed the symlink from .NET canonical location to the Homebrew cellar, which magically solved the SDK visibility problem.

TL; DR. Homebrew recipes don’t play nicely with .NET canonical installer. To make all my SDK versions visible to .NET, I had to forego the Homebrew installation, which did not uninstall the SDK itself, but simply unlinked it.

Neovim trouble with C# and OmniSharp

When I upgraded my old-ish Neovim (I am using nightly builds now), I started getting a weird error on every .cs file I loaded:

Error executing vim.schedule lua callbaack: /usr/share/[...]/semantic_tokens.lua:342:E5248: Invalid character in group name.

A little investigation revealed that semantic tokens provided by OmniSharp don’t conform to the LSP specification, which triggers the error. I cloned the omnisharp-roslyn repo and dug into the code hoping I could offer a quick fix. As it turns out, however, the issue is actually with Roslyn itself, not OmniSharp. There are tickets on both the Neovim and the OmniSharp repositories, but I fear they’ll stagnate there as non-relevant (note to self: maybe report the problem to the Roslyn folks? Alternatively, propose a patched semantic provider to the omnisharp-roslyn maintainers.)

Anyway, a quick, hacky, and not future-proof fix is to customize Neovim (LazyVim) configuration like this:

-- ~/.config/nvim/lua/plugins/omnisharp.lua (create if needed)
return {
  "OmniSharp/omnisharp-vim",
  init = function()
    require("lazyvim.util").on_attach(function(client, _)
      if client.name == "omnisharp" then
        client.server_capabilities.semanticTokensProvider = {
          full = vim.empty_dict(),
          legend = {
            tokenModifiers = { "static_symbol" },
            tokenTypes = {
              "comment",
              "excluded_code",
              "identifier",
              "keyword",
              "keyword_control",
              "number",
              "operator",
              "operator_overloaded",
              "preprocessor_keyword",
              "string",
              "whitespace",
              "text",
              "static_symbol",
              "preprocessor_text",
              "punctuation",
              "string_verbatim",
              "string_escape_character",
              "class_name",
              "delegate_name",
              "enum_name",
              "interface_name",
              "module_name",
              "struct_name",
              "type_parameter_name",
              "field_name",
              "enum_member_name",
              "constant_name",
              "local_name",
              "parameter_name",
              "method_name",
              "extension_method_name",
              "property_name",
              "event_name",
              "namespace_name",
              "label_name",
              "xml_doc_comment_attribute_name",
              "xml_doc_comment_attribute_quotes",
              "xml_doc_comment_attribute_value",
              "xml_doc_comment_cdata_section",
              "xml_doc_comment_comment",
              "xml_doc_comment_delimiter",
              "xml_doc_comment_entity_reference",
              "xml_doc_comment_name",
              "xml_doc_comment_processing_instruction",
              "xml_doc_comment_text",
              "xml_literal_attribute_name",
              "xml_literal_attribute_quotes",
              "xml_literal_attribute_value",
              "xml_literal_cdata_section",
              "xml_literal_comment",
              "xml_literal_delimiter",
              "xml_literal_embedded_expression",
              "xml_literal_entity_reference",
              "xml_literal_name",
              "xml_literal_processing_instruction",
              "xml_literal_text",
              "regex_comment",
              "regex_character_class",
              "regex_anchor",
              "regex_quantifier",
              "regex_grouping",
              "regex_alternation",
              "regex_text",
              "regex_self_escaped_character",
              "regex_other_escape",
            },
          },
          range = true,
        }
      end
    end)
  end,
}

It overrides the on_attach event to pass an LSP-digestible list of semantic tokens. And voilà, C# files are now loaded seamlessly.

I’m not done yet. I’m having another weird issue with .editorconfig files. I’m still triaging it, and will report back when (if) I sort it out.

1. Performance

Since the initial release of “new dotnet” (.NET Core), performance has always been a critical goal for the .NET team. Starting with .NET 5, performance gains have been skyrocketing. .NET 6 was a lot faster than 5, and now, well, I’m surprised by the remarkable performance improvements in .NET 7. Stephen Toub posted a remarkably long (255 printed pages!) in-depth analysis of the performance improvements in .NET 7. one That was followed by articles dedicated to ASP.NET Core 7 and MAUI 7 performance gains. At .NETConf 2022, a particular slide caught everyone’s attention.

I recall seeing the same slide at the .NET 5 release, so this one is must be updated version. I’m more impressed with the gRPC graph than the big “11x faster than Node” one. Being faster than Node doesn’t break the news these days, but being quicker than Go, C++ and Rust? That’s one bold statement you have right there.

An exciting article surfaced a while ago on this specific topic. In it, Dustin Moris Gorski presents an in-depth analysis of the ASP.NET Core 7 code used for the TechEmpower Framework Benchmark referenced in the above slide. The results are… fascinating. That code is undoubtedly not what mere mortals tend to run in their production systems. It is super-performance-optimized, often ditching canonical, built-in, and wildly adopted features in favor of low-level, high-performance and precisely hand-crafted alternatives. Dustin’s article is a masterpiece for several reasons; I suggest you invest your time reading it.

But yeah, despite this glitch, the takeaway is that .NET 7 is speedy, faster than previous versions, and on par with, if not (far?) superior to, most stacks and frameworks. The Stephen Toub’s article is a testament to the massive work done and the achievements obtained.

Most importantely, we get most of these speed benefits for free, just by upgrading to .NET 7. And the good new is, the upgrade is as easy as changing the framework moniker from, say, net6.0 to net7.0 and upgrading the Microsoft dependencies to v7.0.0.

2. C# 11 required modifier

As a consequence of the C# release cycle alignment to that of.NET itself (which is much faster), recent versions of C# see fewer features announcements than in the past. A good thing in my opinion. Of the several appreciable new features coming with C# 11, a remarkable one is the required modifier.

When you enable nullable checks in a project, non-nullable string properties are flagged with warning that they should be initialized with a non-null value when exiting the constructor:

A common workaround has been these properties them with a null! value. That is like telling the compiler that we know they should be initialized with a non-nullable, but well, let’s initialize them with a null value first, just in case. It’ll all be sorted later in the code. Somewhat awkward and prone to errors. Also, battling the compiler like that is a tedious task.

Enter the required keyword. When you flag a property with required, the IntelliSense engine will report an error if the property value is not set at initialization, not at declaration.

When someone initializes our class instance, he/she’s required to set an explicit value for our property. Notice how we went from a warning (which will compile) to an error (which won’t compile). Once you start using this feature, it feels so obvious and natural that you wonder why it wasn’t there right from start.

3. C# 11 raw string literals

In C# 11, wrapping a string with triple-double-quotes makes it a raw literal. Its main benefits are that no escaping of double-quotes is necessary, and newlines are allowed within the string.

var xml = """
          <element attr="content">
            <body>
            </body>
          </element>
          """;

The code looks natural, and no runtime costs for specialized string manipulation are required. One caveat is that string literals naturally remove the indentation when producing the final literal value. The snippet above prints as:

<element attr="content">
  <body>
  </body>
</element>

We can disable indentation removal like so:

var xml = """
          <element attr="content">
            <body>
            </body>
          </element>
""";

String interpolation is also supported:

var json = $$"""
             {
                "summary": "text",
                "length" : {{value.Length}},
             };
             """

In hindsight, like the required modifier, raw string literals appear as obvious.

4. Built-in container support

.NET 7 has built-in container support, meaning that dotnet publish can now output to a container image instead of a directory. We control image names, tags, and other settings (like the base image) via dedicated .csproj tags. Two requirements:

• Docker must be running when we issue the publish command;
• The Microsoft.NET.Build.Containers package must be added to the project as a package reference.

In my demo, I had a small console application that I published to a docker image by simply issuing the following command:

$ dotnet publish --os linux --arch x64 /t:PublishContainer -c Release

I did not mention a Dockerfile, and that’s because it is not needed anymore. All my projects deploy to docker containers and are already migrated to .NET 7. I’m currently using Dockerfiles, but I’ll be experimenting with this alternative in the coming weeks, both with builds and remote CI builds.

5. Native AOT

Native AOT produces a standalone executable in the target platform’s file format, with no external dependencies. It’s native, with no IL or JIT involved, and provides fast startup time and a small, self-contained deployment.

In my demo, I just needed to add a <PublishAot>true</PublishAot> tag to the .csproj, and then the dotnet publish -c Release command produced a single-file, macOS native executable. You can set the destination platform at build-time like so:

$ dotnet publish -r win-x64 -c Release

Native AOT will be determinant in a number of use cases, like multi-cloud-deployments, lambda functions, and, in general, hyper-scale services. ASP.NET Core is currently not supported, so we’re limited to console apps.

6 and 7. Rate-limiting and output caching

Ok, these are two, not one. Luckily, my pal Ugo, who was demoing ASP.NET Core 7 parts after me, took charge of showing these.

I briefly mentioned that rate-limiting and output caching are key features in mature production systems. Until today, we had to bake them in-house or rely on third-party packages. I’ve been using LazyCache and AspNetCoreRateLimit myself. The latter recently acknowledged the arrival of rate-limiting in .NET 7 and embraced it in a new package that offers Redis as a rate-limiting backend. Rate-limiting and output caching are now part of the ASP.NET Core framework, and that’s where they belong.

8. Minimal APIs group routes

I know I said 7. I don’t use minimal APIs in production yet, but group routing is beautiful and something I’ll be employing on the first occasion. During the meetup, an interesting (and much-expected) discussion ensued on the usefulness of minimal APIs. Veterans of many battles don’t deem them necessary, especially in real-world use cases, which is actually accurate: one can keep relying on the canonical MVC approach. The sentiment was that Minimal APIs are mostly targeted to newcomers, which is probably true². As someone coming from the Python REST ecosystem, I dig them a lot. They evolve rapidly and I’m sure we’ll soon see them in action in complex, real scenarios.

In a nutshell, they want to spare us a lot of boilerplate. Code like this:

public static void M(string s)
{
    if (s is null)
    {
        throw new ArgumentNullException(nameof(s));
    }
    // Body of the method
}

Would be abbreviated by adding !! to the parameter name:

public static void M(string s!!)
{
    // Body of the method
}

Code will be generated to perform the null check. The generated null check will execute before any of the code within the method. For constructors, the null check occurs before field initialization, calls to base constructors, and calls to this constructors.

My initial reaction was, we don’t need this; we got Nullable Reference Types. NRTs however help at design time, to know whether a null is possible, while parameter null-checking is meant for runtime.

According to Kathleen Dollard, the .NET Runtime itself removed nearly 20,000 lines of code using this new null-check syntax. That’s one heck of a lot of boilerplate removed.

I don’t think I like the syntax, though. It’s super concise, which is good, and I appreciate putting the !! on the parameter rather than the type since the parameter’s value is being checked. Still, the two-punctuation character seems a bit clumsy. Someone suggested adopting notnull instead:

public void M(string s notnull) { // code }

I like this suggestion. I wouldn’t want notnull on the left of the parameter name. To the right? Count me in.