Are you coming to Python from another language and ecosystem?
It can seem a bit daunting at first, but Python is very welcoming and has a massive array of tools and libraries.
In this episode, I speak with my friend Cecil Phillip, who does both Python and .NET development.
We discuss what it's like coming to Python from .NET, as well as a whole bunch of compare and contrast across those two ecosystems.
This is Talk Python to Me, episode 363, recorded April 13th, 2022.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy, and keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.
Hey folks, I want to share a cool opportunity with you.
Many people reach out to me and ask about getting a job doing full-time Python rather than, say, Java in the day and Python on a hobby basis.
If you're in the market for a proper Python job with adventure right in the description, then check this out.
The Intelligence and Space Research Division at Los Alamos National Laboratory is seeking some smart and talented developers to help them blaze new galactic trails across the solar system.
They're located in the American Southwest, so you'll also have time to explore earthly trails in the beautiful mountains of northern New Mexico.
You could use your amazing Python skills to write software for satellites orbiting the Earth, design systems and interfaces that help protect America's security interests, process data from Mars, or even explore a host of other fascinating space research projects.
Does that sound like an adventure?
Well, you won't be alone.
Your team will be filled with experts in software, engineering, and space science all working together.
Just visit talkpython.fm/Los Alamos and shoot them an email.
That link actually opens your email client, by the way.
The folks at Los Alamos can't wait to hear from you.
The link's right in your podcast player or on the episode page.
Transcripts for this and all of our episodes are brought to you by Assembly AI.
Do you need a great automatic speech-to-text API?
Get human-level accuracy in just a few lines of code.
Visit talkpython.fm/assembly AI.
Hey, Cecil.
Hey, what's going on?
It's going to be fun to just chat about past, future, present.
I see you're wearing the C-sharp shirt.
Yeah, I decided to wear this today.
Also, this is a vintage shirt.
Like, you can't get these anymore.
I think this was from, I want to say, Xamarin Evolve.
Back before Xamarin was a Microsoft company, they had a conference called Xamarin Evolve, and they used to give out, you know, swag and bags and stuff.
And I got this shirt.
And I try to only wear it on special occasions because I want to preserve it for as long as I can because I know I'm not going to get another one.
So, I figured today was a special occasion.
I'll wear it today.
Yeah, for sure, for sure.
I got my Vivaldi shirt on today, which is, should have brought my Python ones.
Anyway, I'm super excited to have you back on the show.
You've been on the show a couple of times.
We talked about live streaming of all things.
And, you know, some of my live stream setup is actually thanks to you because you blazed the trail, which is awesome.
You and it was Brian Clark, right?
Who had been doing your Python live stream, right?
Yeah, yeah.
Back when Brian and I were both at Microsoft, we were doing a Pi Weekly Live is what it was called.
Or we were just kind of looking at Python from a perspective of people that don't do Python for a living.
Or, you know, I don't push Python's production or I don't maintain Python open source libraries.
But it's still a cool language and we wanted to learn it, right?
And we wanted to learn in public.
And I think as advocates or pretty much just as anyone, I think now like learning in public is a great way to not only help yourself, but also help the community too.
It is.
And putting yourself out there in that way.
I think it's scary, especially when you're brand new.
You're like, oh, I've been doing this for a few weeks.
I'm going to look really bad.
But at the same time, you learn that people want to help you.
And other people who are also having the same problems really appreciate that.
So that was a really cool episode.
And we also talked about developer relations and what the heck is that with you and Paul Everett and some other folks as well.
So anyway, welcome back.
This time we're going to be talking about what may seem initially like a bit of a weird topic for the Talk Python show.
And that's somewhat .NET.
So what we're going to talk about is really reaching out to folks who are experts in C# and .NET, hence your shirt, saying, look, Python is this excellent language as well.
And it seems really like such a different ecosystem, such a different language, such a different tool chain, like are almost all the axes.
It looks really weird from a .NET perspective, right?
And I think it's going to be super fun to explore those.
But I want people listening to take this from a slightly different perspective.
Obviously, if you're a C# or .NET person, you know, that's a really focused conversation.
But what about the teams who are doing Java and they're looking at Python or the teams who are doing C++ and look at it?
I think this could be a sort of a stand in or a prototype for how people coming from other technologies coming into Python might evaluate it and perceive it and think about it.
Yeah, I think so, too.
Like, so first of all, I want to tell folks like this is not like a my language is vetted in your language kind of conversation.
You know, we fight.
We're girlfriends here.
You know, we all like each other.
But I always find that, you know, if you kind of look through like the history of programming languages, like we all kind of evolve together, right?
Like we all borrow features from each other, whether it's libraries or, you know, actual language core features or whatever the case is.
And, you know, it's always interesting to see folks when they're like, oh, your language can do that, too.
So can mine.
And so now that kind of just makes them a little bit more relatable, right?
Because you're like, OK, well, I know how that works for me.
So now I'm maybe I can pick up your language a little bit easier because I already know like that particular concept, you know?
Yeah, I totally agree.
And it's not a one way street either.
Yeah, exactly.
For example, we in Python have async and a wait.
Thank you to C#.
But C# has generators and yield return.
Thank you to places like Python.
Right.
So there's like this sort of give and take.
Yeah.
Which I think is quite interesting.
Another thing that C# has.
I don't know if you know, I think it was in C# 9.
I might be a mistake.
I think it was C# 9.
C#, by the way, if you're not following it, has many versions.
This is actually an interesting thing to discuss as we'll get into it later.
Yeah.
So C# 9, this is like a lot of releases.
Yeah.
I think C# 9 was two years ago.
Right.
So last year's version was C# 10.
And then C# 11 is going to be released in November of 2022.
Yeah.
So yeah, like Michael said, there's a lot of versions.
But I kind of want to follow up on that last point you made about async await because another
feature too, which is one I actually really appreciate, is records.
And so when I think about records, I almost think about like data classes in Python.
Yeah.
They're very similar.
Yeah.
I think about like these immutable classes, these immutable types that I have.
And essentially like their job is really just to pass information back and forth.
But I want to say I feel like Python had that first.
Right.
Again, .NET got that like two years ago.
I'm not sure how old data records are.
Or data.
Oh, yeah.
Data classes, I believe, are older than two years.
But yeah, I'm pretty sure.
But yeah, I don't totally remember the exact release number it was.
Yeah.
We have a lot of releases too.
We just put them as point releases, 3.7, 3.8, 3.9.
Now, let's start this conversation from a perspective of a C# developer.
Now, imagine you don't know a lot about Python.
You do know a lot about both languages, just to be clear.
And that's why I actually have a ton of experience in .NET before I got into Python.
But let's imagine that you don't know a lot about Python.
And you're thinking about, you know, maybe I just really need to either I'm going to get a new job.
And it's not the same technology I was working in.
This is a Python place.
And I've been doing .NET at my company.
Or you're just thinking, you know, more like I was.
It's like, gosh, I kind of need to diversify my technology and my career experience and not put all the eggs in one basket sort of thing.
And really actually love that change.
But think about what are the things that you really love about working in C# and .NET.
And you're like, I just, if I had to leave this feature or this language thing behind, it would nearly kill me to do so.
Yeah, I think for me, and it's almost not so much so for me about like the language.
Because like you mentioned before, like we've had the opportunity to play around with like a lot of different languages and kind of see how the world works.
For me, it's the tooling, right?
From a .NET developer perspective, it's the tooling.
And the libraries.
The tooling and the libraries.
The tooling, the libraries and the integrations with like some of the other ecosystem that kind of surrounds .NET that makes it really useful for me.
So I'll give you an example.
Like, so for .NET developers, you may already know this, but, you know, we have project types that are based on CS projects and solution files and things of that nature.
Where I know some folks might look at and be like, oh man, why did my project have all of these different files?
And like, there's so much stuff just to do like a hello world or a simple project.
But then I look at that as, okay, well, I know where the root of my project is, right?
And I know there's a very standard way to define like what are my dependencies and what are the different projects that denotes, I guess, sub projects in like that larger solution, right?
Whereas one of the things that, you know, hurt me a little bit as you look at other languages and not just Python, but if you look at JavaScript and Go and some of these other ones, I'm like, okay, well, how do I know where's the roots?
And then how do I have multiple projects?
Or I guess you could call them multiple components for that same project or multiple pieces, but I want them in the same folder.
And I want when I hit build or run that all of them run or like the right subset of them run.
Like, right, right.
I maybe have a web front end and some API back end and they both need to be running that type of thing.
Right.
So for me, like one of the things I love about Visual Studio back when I was on Windows, because I don't use Windows as much anymore.
I used to be able to like select multiple projects to start, like when I started debugging session so that whenever I hit F5, famous F5, you know, start and run and do all that types of stuff.
Now I'll have like multiple projects running.
So it could be, like you said, like my web API or my back end, or I have a Xamarin thing that's running or whatever the case is.
But now they're all running and debugging at the same time in the same solution.
Because again, the editor knows what projects are part of this.
It knows what the dependencies are.
It knows what ports they're running on and all that types of stuff.
Whereas, again, if I walk away from that world a little bit, I feel like now that becomes like a manual process and I have to write like scripts or YAML files or something like that.
Yeah, yeah, yeah.
Well, let me riff on that for a minute.
So, so often what you'll see in the tutorials and stuff, the getting started stories in the Python space is create a blank Python file called app.py, main.py, whatever, and write this bit of code.
Yeah.
And the sort of starting structure that is presented to you is, it's almost wholly absent, right?
If you're going to build a web app, you have to figure out, well, where do the static files go?
Where is the JavaScript?
How do I align that?
What do I do with my view templates versus like just, it's completely unstructured, right?
And I think that that is the world that's presented to a lot of people and keeping with my opening theme, if you're coming from a place where there's a lot of guidance through the tooling, you may see that and want to just run in horror and go, I've been shot back to the 80s.
What has happened to me?
I don't want this.
Like, I don't need this.
Why am I here?
But as you dig deeper, if you want to opt into those things, they do exist in a much more sort of decentralized, you know, by choice, go hunt them down way.
And that's like, if you want a lot of structure, you could use cookie cutter to generate very structured projects.
So much so that I think a lot of the cookie cutters are overly specific.
You end up like, you know, I don't really need two layers of Redis.
One layer of Redis was enough.
Like, why is all this stuff here?
People get carried away with it.
But you can generate those types of like, here's the pieces and it's really structured how they fit together.
You can use things like PyCharm to create a project that might have a little bit of structure.
They very rarely have much, but a little bit.
But none of that is presented to you in a way that is discoverable in the first week.
Right?
If you're brand new, you're like, I'm here at this one file.
That's what the tutorial says.
Why is it all in one file anyway?
Shouldn't this be broken up?
Yeah.
And to that point, there's like pros and cons to each of those approaches.
Because like you mentioned before, one of the things that I could say I love about Python is the fact that I could just get started with one file.
Right?
Yeah.
And that getting started experience and that evolvability of the language, I think is important.
Right?
I think that's one of the reasons why people like latch onto it so much.
Because my barrier to entry is like extremely low.
It is literally like a file and, you know, whatever Python runtime that you have on your machine.
You know what I mean?
Yeah.
And that's a huge attraction for many people coming into the ecosystem from what I can see from talking to a lot of people is, right?
I'm a biologist.
And I learned that if I write these five lines into a text file, I can now do magic.
Whereas if you've got to learn about public static void classes, namespaces, compiling, linking, you're like, wait a minute.
I'm not a programmer.
This is not for me.
Yeah, exactly.
And when I think about that, right?
Like if I think about like the structured nature of Visual Studio style projects and .NET projects and C# projects.
And like you mentioned, like the Python projects and even the cookie cutter stuff and whatever the case is.
I have to kind of look at the history and see like, oh, well, what space did these ecosystems kind of evolve in?
Right?
Like when I think about that .NET ecosystem, you know, for folks that are listening, that's mostly where I spent a lot of my time in terms of like my career coming forward.
You know, I think about like schools and enterprises and big companies that need like structure.
Like give me the structure and then now I'll add the bits and pieces that I kind of need going forward.
Right?
When I think about Python, and again, if I'm wrong, please correct me.
When I think about Python, I think about, okay, folks that are doing like a lot of scientific experiments, like numeric computations.
And hey, I just want to do these things really quickly.
I don't really need structure, but I want to like execute experiments.
Not experiments from the perspective that the code is not important.
The code is important.
But like it's the task is more important than the code is, if that makes sense.
Sure.
Yeah, that makes a lot of sense.
And that's not always true, but that's often true.
And I would say there's different areas in like certainly the scientific area, maybe the data science exploration area, but even like the DevOps or just the automate stuff with Python rather than bash.
Right?
Like I need to copy these files over here and then rename them and then put them on S3.
Right?
So that's not a super structured experience, but Python's really good at it and often it's used for it.
Yeah.
And I agree with you when we look at where both of these languages have come today.
So if you kind of look at, okay, now .NET is what?
.NET is like 16, 17 years old, something like that.
20.
I think it's 20.
I think because, yeah, I think there was the whole, yeah, Richard Campbell and crew have been going on about like the anniversary and stuff.
Right. So if you look at languages 20 years later, right, like your initial intent was this.
As the world evolves, as the world of software development evolves, and then now we're, as developers, like we're looking at attaching on to new, you know, new work types.
And, you know, you're hearing about Kubernetes and mobile apps and all these types of things.
Now, like our languages kind of have to evolve with us.
Right.
And like we have to evolve with the industry.
And so now some of those initial use cases have like expanded and multiplied.
Right.
And now we got to take care of all of these other things now as well.
Yeah.
Well, that's a big shift, honestly, that the whole .NET side has had to sort of come to terms with over the last 10 years is the open source, the open sourceification of this whole sort of commercial side of things.
And let's maybe explore that for a little bit, because I think there's a lot of interesting variations and differences and stuff.
Right.
So Python, in a sense, was open source before open source was a thing.
Right.
It was just, here's the source code.
Right.
There's no GitHub and PRs and all of this sort of formal open source structure.
It was just released on Usenet and other places.
Whereas Python, I'm sorry, whereas .NET has been a product from quite a long time.
Right.
It was a way to build things in the early days for like Windows servers and for Windows and the Microsoft tooling.
And like, let's make it really good for developers over there.
Right.
But that was not released by a bunch of people contributing in different ways.
It was way more structured.
Right.
Yeah.
This portion of Talk Python to me is brought to you by Cast AI.
Cast AI is the number one Kubernetes cost management and automation platform.
Get on top of your cloud costs, streamline DevOps processes, and remove the complexity that slows down software delivery.
Cast AI uses automation to eliminate manual tasks, provision your infrastructure, and keep it optimized at all times.
It selects the right resources at the right time and for the best price.
So you can focus on things you want to do, like building new features and writing code.
Teams using Cast AI see an average savings of 50% and more.
Your friendly cloud giant is making tons of money.
Don't send them more than you need to.
So why not scan your cluster and discover how much you could save with Cast AI?
They have a special offer for Talk Python listeners.
Just visit talkpython.fm/castai or click the link in your podcast player show notes and get a free optimization report.
Thank you to Cast AI for supporting the show.
Again, like when we look at the history of things, right?
Like for me, the initial intent or one of the initial intents of .NET was to make it easier to build apps on Windows specifically.
So you think about like, well, who's building Windows applications, right?
Like at that time, you know, you go back to like 2001, 2002, right?
That's what we're talking about.
And at that time, mostly we're talking about like desktop applications, right?
Like we're thinking about Windows forms.
This is the successor to Visual Basic 6 and all of its glorious.
Right, like the drag and drop UIs and like all that types of stuff, right?
And then eventually that evolved into WinForms and those types of things.
But still from a very Windows specific perspective.
And then now we forward on to like, I don't know, let's say 2013, 14, 15.
And even up until today, now like the cloud has become a major thing.
And I'll be honest with you, I'm not a business person and I wasn't in the room, but I can tell you, anyone that wants to compete in the cloud computing space, you have to be cross-platform.
And you almost have to have a more open community, be able to work with different types of folks and interoperate with different types of technologies just because of the nature of the landscape of cloud computing, right?
Like you mentioned Redis earlier, right?
Like how do we plug into Redis?
How do we plug into RabbitMQ?
How do I plug into Docker and Kubernetes, right?
Like, you know, a lot of these things have their best experiences on non-Windows machines, right?
So how do we now plug into that ecosystem and evolve to kind of follow along with where the rest of the industry is going?
And so that's why you'll see now, like now .NET is, now it's open source.
Now it runs on ARM devices and it runs on, you know, what's that?
The M1 Macs and all of these.
Yeah, it runs on our Mac, right?
Right, like it runs everywhere that you could potentially want it to run.
One's on, I'm sure, I'm pretty sure it runs on like Apple watches and on your fridge if you have a Samsung fridge and like all these different places, which is really crazy to think about.
Again, like looking back at the history of what this thing was intentionally, you know, initially intended for.
Sure.
To me, the biggest, maybe two biggest, the two big things that are sort of tied together that are affected by this different origin story of Python and .NET
really have to do about what I'll refer to, I guess, as the one true way versus a thousand flowers blooming and some of them growing in, you know, maybe in the tall trees or whatever.
And then people's perception of using open source content versus like what is blessed by the project organizer, right?
So maybe we can think about that for a little bit, right?
So when you're a .NET person, you go traditionally, I think this is actually fading a lot, but traditionally you would go into Visual Studio and it has a list of projects.
What do you want?
I want a web project.
I want a UI GUI type of project.
I want an API.
And then you click it and it goes whoosh and a ton of files come out and a bunch of linked libraries off to the equivalent of PyPI.
And those are certain frameworks, right?
It says you will use this web framework, ASP.NET, some variety.
You'll use this data access framework, entity framework, probably of some variety.
Now go.
Like those, you start from the assumption of, well, I'm using these frameworks.
Now I get decisions about architecture and other things I bring in and how I build, whereas somebody coming from that world into the Python space, I think they're going to have almost a rude awakening, both in a beautiful way, but also not so great, like a paradox of choice.
So you want to do a project that's a web app?
Okay.
First, you begin the web framework selection story.
Flask, Django, Pyramid, FastAPI, Tornado.
So like just, and then the next layer down, now we begin the data access layer exploration, right?
Is it SQLAlchemy?
Is it SQL model?
Is it some MongoDB thing?
Like you just, every step is a, is great in that there's a ton of choice and variety.
You don't like one, you pick another one, but to get started as an experienced person, that feels like a great option.
As a brand new person, I think that feels like an impediment and not quite a problem, but almost a problem.
What do you think?
Yeah.
I think it definitely gives you a lot to think about, right?
Because now you have to wonder, am I making the right choice?
Right.
Yeah.
And not only am I making the right choice, am I making the right choice today?
And is this choice going to grow with me as whatever I'm building hopefully grows because hopefully all of our projects are successful, right?
And hopefully it will grow with me.
And so if you kind of go back again to like that Microsoft thing that you were talking about, like you said, .NET was not originally open source and .NET is a product that was essentially created to make it easier to build things on Windows.
And now, again, over time, it's become open source.
And now it's in the cloud and runs on different devices and all those types of things.
But I keep going back to this because the origin story is important, right?
Because like you said, Python was almost open source by default from the beginning, right?
And so like its intent from the beginning was already like, hey, I have a community of people that are going to come and latch on to us.
And then we're going to kind of just grow organically together versus like I have big company X that's going to throw millions of dollars in developer time and research and all these other things to tell you this is the right way for me to do this.
Now, I don't think there's a good or a bad way for either one.
I think at that point it comes down to us or you as a developer to kind of sit down and think about, well, what's really important to me?
Like, how do I really want to build applications?
And it's such a funny thing because I like to look at building software like writing a book or like drawing a picture.
Like you can tell me to write the same app that you write, but you might write it in a different way.
You might have a different style or different patterns or different tools that you like to do.
But ultimately, maybe it solves the same problem, but like it looks different because it came from different people.
Just like, again, like telling a story, drawing a picture, whatever the case is.
And so for some people, the way that they work and the way that their organization is set up, you might prefer to be able to pick each and every single piece of your stack, right?
And make it look exactly how you want it to look with the pieces that you want, the frameworks you want, the databases, all that type of stuff.
Or you can go to Microsoft and do a file new project that you can get ASP.NET, an ADD framework and a right click publish to the cloud.
And then you could just be like, okay, well.
And by the way, when you publish to cloud, how many vendors, cloud vendors do you get?
Usually it's Azure, right?
I mean, if you're talking about Visual Studio out of the box, it's, you know, published to Azure, right?
Just being like that, that's another thing that's sort of like strongly encouraged as like one more choice.
Yeah, that's another thing you have to think about, right?
Yeah.
And so now for people that are in that space, like if you're in a space of, hey, I just need the template.
I need you to tell me like how this thing is structured and like where my dependencies go, how they're defined and how the build process works.
And all I want to do is just write code and publish, then sure.
Again, like I said, there's nothing wrong with that.
But then if you're in a space where you want to control every minute detail of the development process and the libraries and how they plug in,
maybe you even want to write some of your own libraries, right?
To like augment some of those additional things that are in there and do some of that type of stuff.
Then, you know, maybe again, you want to make some different choices.
You know, one thing that just occurred to me, I think is pretty interesting as a difference here is you talked about the benefit of all these, the tooling, you know, like file a project, boom, it gives you all these things.
And for people who haven't played with it, you can get like these database visualizers for designers for say the classes that are backing entity framework and things like that.
The presence of those tools is also kind of a limiting factor.
Well, you wouldn't choose some other database way of working because you're going to lose access to all those good data integration tools, right?
Whereas in our space, we don't have those to nowhere near to the same degree.
And so it doesn't matter so much which tools we pick, whether or not they fit exactly together in that way, because they're not really available.
So we have more flexibility, I guess, to say like, actually, I like the API of this one better.
The performance story of this one or maintenance, how lively the GitHub project is, you know, is better on this one, even though it wasn't traditionally like exactly.
Yeah, I think there's definitely something to be said if you walk into a world where the entire stack is unified.
And when I say that, I mean, you know, I can go into a place and the programming language runs on the operating system that they built, that runs in the IDE that they built, that runs in the cloud that they built, that runs on the DevOps pipeline, security, whatever, whatever that they built.
And it all plugs in together.
And so with that integration, like you said, like you can get a different level of visualization, a different level of reporting and metrics on all of that types of stuff with a lot less work.
It's not that you can't get it from other places, but it's just a little bit more work to get it, you know, to kind of kind of put those puzzle pieces together to make the world look like how you want it to look.
Every level is like a decision you have to make and an integration you have to consider as opposed to it just by default clicking together.
Right. Just like cloud computing. I'm going to bring this up because I have a talk where I talk about something I like to call like the microservice matrix.
Yeah. And I do. Before you get into that, I do really quickly want to point out last time you were on the show, you were developer relations on the Azure team at Microsoft.
And now you're at Stripe.
Now I'm at Stripe.
Right. We didn't, we didn't point that out. Right. I want to point out that you're not actually at Microsoft anymore.
Yeah. I'm not at Microsoft anymore. So there's no backgrounds baseball happening here. Like, you know, I'm not sharing anything that, that I know more about than anyone else at this point.
Yeah. Kind of going back to, if you think about the world of like microservices, because I kind of look at that as like everything that we've already done, just like existing on another level.
And I'm using that as an analogy when I talk about this microservice matrix, because with everything that you do, you have to make a choice. Right. So like I mentioned before, like, where am I going to store my state, my database? It's like, I have to make a choice. Right. Like, how am I going to do metrics and monitoring? I have to make a choice. How do I know what my services are? How does my DNS routing situation work? I have to make a choice. How does ingress work? I have to make a choice. How do I do publish, subscribe? Like I have to choose a thing. Right. And so now you're going to make a choice.
So you're sitting down having to like make some of these decisions about what's the right way for me to compose my app. And then also what are the right combinations of tools that I'm going to compose them with?
So if we come back now, now to the level of just talking about Python and .NET, again, it's a very similar thing where you could just say, hey, just give me the menu, right? The GUI, like file new block. And there's a thing. Or I can sit down and I could fine tune and optimize my application to perfection.
Or what we consider to run and work and have the right integrations of things that I wanted to have. And like I was saying, like, there's no wrong way. It's just a matter of like, for your business and what you're trying to do, like, what do you think makes the most sense?
Yeah. It certainly is an interesting difference. Now, I do think there are more opinionated paths, we would call them in the Python world that you can choose. For example, you could say, and many people do, like, let me just use Django.
Sure.
Right. And you choose Django, it's very much this sort of holistic, click together stack that we spoke about, right? Like the data access layer is the Django ORM. The database is relational. You put it in something that could be SQL server, but more likely it's Postgres. There you go.
Yeah.
Right. But I personally very much appreciate the ability to look at all those options and go, no, no, for this one, I want to use FastAPI and Beanie rather than Django and Django ORM.
And that's what I'm saying, like, depending on what your goals are. So I know for you, you have your top Python websites and your courses, and I believe you all have a mobile app too, right?
Yeah, we do. That's actually Xamarin. Shout out to the shirt, man.
I didn't know that. That's cool.
The APIs are all Python, but the front end, like, mobile app itself is Xamarin.
It's all Xamarin.
Okay.
Yeah.
So, like, for your web experiences, like, you already know in your mind what your objectives are. So you're like, okay, I'm going to use this database and this caching thing and this thing because I need them to work this way, right?
Because the thing with having opinions, it's always great to have opinions, but when sometimes someone's opinion just doesn't line up with what you're trying to do.
But then on the other side, you know, sometimes there's just too many opinions, right? And so now you're like, oh, man, can I choose this or this or that or the other?
Yeah.
Like, what's the right puzzle piece for me?
There's opinions and then there's opinions within a context, right? And there's a very popular article that keeps getting passed around and around. And I'm sure I'm somewhat to blame for this. It's like the title goes something like, you're not Google, you're not Facebook, you're not LinkedIn, you're not Instagram.
So subtitle, don't design your software like they do.
Yeah.
Right. And opinions often mean, I believe this is how code should be written. If this is your general use case, right? And if your use case is really different from that, then those opinions might not just be someone else's opinion.
They might actually be wrong because they were formed for another situation. I, I believe you're having a relational database and around 100,000 or fewer users a day. But if, if it's significantly different in some other direction, then maybe you should make different choices. Right. And having that flexibility is awesome.
Yeah, for sure. For sure. And then kind of going back to like what we were talking about a little bit earlier with the tooling, like, like once you've made those choices, now you have to make a choice of like, well, what's the thing that I'm going to build it with?
So again, on the Microsoft side, you have Visual Studio, which is like a kitchen sink of stuff. So I could, I could look at my databases, I could look at my deployments, I could build, deploy, debug, analyze memory dumps and all these types of things. Right. Again, like big thing.
Or on the other side, we probably might want to do like some more command line tools, or we might want to grab like a bunch of different tools and kind of put them together. Again, all depending on like what we're trying to do with our use cases. And I think with that too,
what you notice is that like the culture of either side of those of those languages is a little bit different. So I will tell you as a .NET person, automatically, it is ASP.net. It is any framework, and in a SQL server, automatically. I mean, I'm not going to say 100% of the people do it. But I want to say,
a lot of people do that, right? That's the default. But I'm sure on the Python side, like the culture is probably different, right? It's probably a little bit of Mongo or Postgres is probably a little bit of
Blask or Django and probably now FastAPI, because I know that's another popular thing.
And, you know, whatever other tool they put on top of that, whether it's PyCharm or VS Code, or I know a lot of you, people love them, right? I know you've had a lot of them folks on the show, right? So it could be that too, right?
But that culture is different. You know what I mean? And so like the expectations about like how software is built is going to just be totally different.
Yeah. When I opened this segment, I said there were two things that were closely tied together. We covered the one, I think a very similar related parallel here is developers often in the Microsoft space, my experience I've had interacting with them is like, if it's not recommended by Microsoft, or the .NET team or whatever, I don't want it.
If it's not the product story or the company story that you should use this framework or that, then even if the other one might be better, might not, like it's just, they just don't want to consider it.
Yeah.
Which I think is an interesting angle. Like it's very much at odds with the, you have a thousand choices.
Yeah. For me as a .NET developer, before and during and now after Microsoft, like that's one of those things that's such a hard habit to break.
Yeah. Do you agree with my assessment?
I agree with your assessment 100% for sure.
Okay.
And I think it's something that particularly when you're living in an open source development world, like all of us are, you know, majority of us languages and tooling and stuff are open source.
We have to be able to, like developers still have to develop.
You know what I mean?
Like, and you can't really expect things to always be given to you all the time.
So when I say that, I mean like, just because company X doesn't create a thing for you, doesn't mean that there's not a ton of other great options available.
But again, the culture or the way that .NET developers have been raised, right? If you think about them as, you know, evolving over time.
Growing up through their career.
Growing up through their time.
And the way that they have been raised is that like, I'm going to open Visual Studio on Windows and whatever's in the box. I'm going to use that. I might be one or two or other two other things that like, I'll use. But those things are usually recommended.
When we think about like JSON.NET as an example, those things are usually recommended from the box.
And then not going to use that.
Right.
They might actually be third party, but they end up getting installed anyway.
Exactly.
Right.
Like a pip dependency effect.
Like a pip dependency or something like that.
Or I don't know if you remember back when ASP.NET MVC was a thing.
Like the first version of it, like it shipped with jQuery.
And so anytime you did found new project MVC, like you automatically, you had jQuery, you had jQuery validation.
And I think there was a couple other libraries that were in there.
I think jQuery UI maybe might've been in there or something else like that.
Right.
Yeah.
But again, like these are the things that like just come out of the box with that, that style.
And I think what happens with that now is that, and again, this is my opinion, I think it hampers innovation.
Because now when I look at the Python side, we joke about, oh my gosh, like there's a new Python web framework like every other year or every year or whatever the case is.
But I could also look at that and seeing, wow, like people are so invested in this ecosystem that they're constantly trying to make it better.
And they're constantly trying to like pull resources together to create new experiences to improve developer productivity.
Not to say that people are not trying to do that on the Microsoft side.
But what I'm saying is that like, if it's not in the box, people are like, I'm not messing with it.
Versus on the background side, it's like, we'll just make it.
Sure.
The realm of possibility is wider.
Yeah.
We'll just make it.
Well, we'll make it together.
We'll open source.
And if people like it, now we'll start a community around it.
And now it's a thing, right?
Again, like FastAPI and Pedantic and Sanic and like some of those other things that have come up recently.
Absolutely.
Okay.
So one of the things I did want to talk to you about here, I think that's really interesting.
And FastAPI is a good example of it.
FastAPI basically exists because as you mentioned,
Pedantic and some of the new language features of Python 3, 5, 6, 7.
You know, the somewhat enforced typing information, data classes, those kinds of things.
The async and await.
So these are now possible.
These are these new experiences that can be created from the language.
But one of the really interesting things about languages, places like C#, or we could just as well say Swift and Apple or other languages, is there's a team of people whose job it is to work on the language.
Which I think is really interesting.
It has some very good positives.
Like there's people who are constantly focused on it.
I mean, we have the core devs, but they're kind of more broadly focused.
And sometimes that means the language.
But in the .NET space, that means the language is always changing.
Maybe if it doesn't even need to.
That's my statement.
You don't have to stay behind that if you don't want.
But I feel like there's people who are working there.
And every year there's a new version of the language.
If there's no new keywords, then what's their job about?
Yeah.
So for folks that don't know, .NET as an entire product and family of things has gone through changes over time.
So when Michael and I first started doing .NET, it was .NET framework.
And then over time, it became like...
Back in early 2000s.
Yeah, for sure.
And then it evolved into what today is known as .NET Core.
And I think .NET Core went from 1.1 to 3.1 or something like that.
Right?
And then after that, we skipped a number.
We skipped 4.
Right?
I don't know why we skipped 4.
But we skipped 4.
And then we went to .NET 5.
Not .NET Core 5, but just .NET.
Right?
So we had .NET Framework.
We had .NET Core.
And now we just have .NET.
Nothing else after it but the number, right?
.NET 5.
And what's happened over time now with .NET 5 and 6, 7, and until they decided to call it something else,
what's happened right now is that it switched to like this yearly release cycle.
And I'll be honest with you, I don't know how I feel about it yet.
We're looking at .NET 7 coming up in November.
So it's really only been, you know, 5 and 6.
We've had two versions that have been on this yearly release cycle.
I don't think that's enough time for me to like feel like, you know, see how I feel about it.
See what the actual effects of that are for sure.
Well, my initial thoughts are, I don't think we really need to release that quickly.
Because like you said, one, how many people are going to update every year or even every two years?
You know what I mean?
And then as you're pulling out these new features, I often have to think about, well, who is this for?
Because if one of the goals of your language is adoption or if it's growth or if it's how do I bring new people in by adding new features,
I can tell you regardless of how many features you add to make it easier, when they go to work,
they're going to end up in a code base that's going to be 10 years old.
With three flavors of Lambda expression, that three flavors.
And it's going to look different and it's going to feel different.
And their experience is not going to be hello world or a to-do application.
And so now like the minds, like the mental efforts.
So now you kind of like have to exist in multiple worlds.
Like, oh, here's the new cool stuff.
And if you're lucky, maybe you start in a company that's doing the new cool stuff.
Or here's like the framework stuff or the older tooling or here's this older version that's, you know, still kind of new,
but still doesn't have like the things from like six or seven.
And it's like, well, if I am considering myself a language X developer,
how many of these new language features do I need to know?
It's a really good question.
I mean, let me just give a little bit of background for people who obviously most people listening probably don't work in C#.
But C#, like Python, has a way to express properties.
Honestly, C#'s way is way better than Python's.
There is a way to do Lambda expressions that's very similar across both languages.
But if you look on the C# way, there's how many ways are there to do properties?
There's at least four.
There may be five different pieces of language syntax to accomplish effectively the same thing.
And there are benefits to argue on some of the newer ones,
but so much so that there needs to be a fourth, not just three ways to do it.
You know what I mean?
Like there's a lot of overhead.
And my feeling is that the language looks that way because it's a product and there's a team whose job it is to continue to work on that product.
Whereas like in Python, if it doesn't make sense to add it,
there's nobody whose yearly review doesn't look so good because they didn't add a new way to do properties.
Yeah.
And I agree with you.
I think that's another thing that I feel like I ever really appreciated about the Python ecosystem.
Because Python also has like a scheduled cadence of release.
It's not like, yeah, yeah.
And it's yearly as well now.
And it's not like Python hasn't updated the language in like six years or whatever the case is.
Like you said, like there's async await and, you know, there's new operators and things of that nature.
But I always find like the additions to language, I think with the exception of maybe type hints, I think that might be a little bit more in your face for a lot of folks if they decide to use it. But if you look at some of the other language features, a lot of the times it happens in the core library and not so much so on the language surface. And then the few that happen in the language surface.
Yeah, or some package, but you don't have to know about it to consume it, something like that.
Right. And then the things that happen on the language surface are usually very subtle, right? Like we'll have a whole version and they might add like one operator, right? Or you might add like, again, like a sink away, like we've just added. I mean, it's not really one keyword. It's kind of one keyword. It's one feature. But like, I've added this one big feature, but there's tons of other little fixes in the library and not necessarily like what the syntactic structure of my application looks like.
And so I kind of feel like, like if you're on modern Python, I'm going to use a term you use, right? If we're on modern Python, and you're, you know, 3.4 or 5 and above, I'm sure when you hit Python 3.9, it's going to look the same, it's going to feel the same, it's going to work the same.
Yeah.
Might be some extra things, but you could probably ignore it if you don't, if you don't need it. But then, you know, you should be able to be functional and not have to think too much about like, oh, okay, how do I like plug this thing into this thing? And then, oh, my thing is not compiling anymore because I don't have the old, I don't have the new version, even though I'm not using the new version features and all of that.
Yeah, it's interesting. And I think that, you know, we use a language as an example, but I think that influence happens across different many things, across like the web frameworks, across the database, across the tooling and so on. All right. A couple of thoughts from the audience here.
Oh, yeah.
A lot of people.
Mr. Hypermatic says, hello, looking sharp. See what I did there? It's loving the shirt. And then Christopher Tyler has a more actual question here. Are the contributors to .NET primarily people who work at Microsoft? Is that the same for C#? Like, what's the open source story on that? So we know in Python, like, there's the core devs, and then there's the sort of everyone else layering, but that's not nearly as extreme as employee, not employee.
Yeah, I can't talk to the percentages in terms of like, what percentages is Microsoft and what percentage is not. But I can tell you that now that it is open source and it's on GitHub. I mean, there's a tremendous amount of folks that do not work in the company, that not only contribute fixes, but also submit proposals for new features and like all these types of things.
So I think if you go to, let me see if I can open it up. I think if you go to GitHub slash .NET, and I think if you go to .NET slash C#, I'm not mistaken. No, it's not .C#. It's a, there's a language proposal thing. I don't remember what it's called.
Runtime, maybe?
It might be in the runtime. There's a repo in here that you can essentially, you can essentially like submit proposals whenever there's a new version of C# that's coming out. Or, you know, if you want to know, okay, well, I want to, maybe we should change how interfaces work or how do we add records or whatever it is.
Like there's, there's a repo in here that you can do that. I don't remember what it is at the time. I probably should.
But what I'm saying is that like, as a person that does not work in the company, you can have like that level of influence and you can have a whole discussion about, hey, this is why I think this is a great feature.
This is how I think it should look and behave. And this is how I think it would work with some of the existing features that are ready in the language today.
I love that because that means that now you don't work there. I don't work there. We all don't work there, but we can have like a very open and honest discussion in the public because again, it's on GitHub unless they delete it. But they don't, they don't do that.
They don't do that.
It's not like they own GitHub. Oh, wait a minute.
Uh-oh, uh-oh.
Well, you see what I'm saying, right? Like you can have that open discussion about like, okay, well, these are some of the things I think make a lot of sense.
That's really good. And it's certainly a big change that's happened over the last five years there.
I found it. It's .NET's has C# Lang. So it's not just C#. It's C# L-A-N-G. Yeah. So if you go there, you should be able to, again, it's the language design repo.
Oh, yeah. The active C# language feature proposals and meetings. And yeah. Interesting.
Yeah. And I mean, some of those meetings are, they're public on their online. I know Emo. Emo is one of the folks that work on C# in the runtime. Like they do API reviews and all these types of things, live stream it. I don't know if you've ever said that in an API review.
It's not the most page churning thing to sit down in a lot of computers. But you could have. You are.
But if you wanted to, like if you're interested in that, if you're interested in language design and compilers and API surface design and those types of things, I think those are great things to do.
Because I honestly can't think of any other ecosystem that really does that.
From the perspective of like reviewing the actual API in the public, which I think is a great thing.
Yeah. One of the things that's interesting about in the public is I try to listen to all sorts of different podcasts and try to keep my finger on the pulse of sort of where technology companies and programming languages and stuff are going.
So I listen to some Apple podcasts, some Microsoft podcasts, and of course, Python podcasts.
One of the things I find interesting is when you hear the Apple podcast people talk, it's always about speculation and rumors.
And there was this leak and there's this thing.
And what will we get?
You hear the Microsoft people talk and like, oh, there's a hint of this code word, this project.
And I think this is happening.
If that's absent in the Python world, right?
There's none of this like sort of fortune telling surprise of what's going on.
I think that's also a big thing that people coming from either the .NET or the sort of Swift space over to Python is that we know really far in advance what's coming and what's not.
And the more of the fortune telling side happens to land on, well, of these thousand flowers that represent web frameworks, which one do you think is going to continue to gain popularity?
Right.
Yeah.
In that sense.
That's a pretty big difference to the ecosystem.
Yeah.
I think it kind of goes back to what we were talking about before, right?
In terms of culture, right?
Like the culture of Python has always been like an open project that we all kind of work on together versus, okay, here's a product from Apple or Microsoft.
And I'll date myself a little bit.
Like I remember when you used to have to wait until like magazines came out to like learn about like beta features that have like the little CD in the back.
Yeah.
You might go to a conference or I don't know, go, I don't know, Barnes and Noble or whatever.
And there'll be a CD.
Macworld or MSDN or any of these things.
Right.
Like there'll be CDs in the back of magazines.
And that's how a lot of developers back whenever used to be like, oh, okay, this is what's coming out.
Like, and you'll read about it, right?
That there wasn't like a YouTube, like YouTube wasn't a thing for like developer videos and, you know, live streaming, all these things that we do now where we can get more immediate feedback.
Like, you know, it was the magazine's going to go out.
But then think about it.
Like how long does it take to print the magazine, press the CD and put it out?
Like how many things have changed in the product?
Does that act?
Right.
And how far, far back is the editorial schedule versus the writing versus that's months.
Right.
It could be months, right?
So by the time you get that CD, what's actually in the product on that day might be like two months difference, right?
Like you could have changed all kinds of stuff.
But what I love, again, about like the culture of where Python has started, like the feedback mechanism is so much faster.
And it's been like that by default.
Yeah.
You know, we're talking about .NET and Microsoft, but like you said, it could be Swift, it could have been Java or whatever the case is.
Now as these things become open source, now they're understanding, okay, well, like let's shorten the feedback mechanism.
Let's get more immediate responses on things.
You know, let's allow folks to like download them and try them out.
Let's have students that are doing language design and programming language theory, like try our bits out and like work with us and talk about like, oh, okay, well, I learned this in class.
Now I'm seeing it over here.
I understand how this works.
Like let's kind of collaborate a little bit closely together.
Yeah, it's certainly is a different way of working on it.
You don't have to wait until the one thing has been released.
Yeah.
I was contacted by a guy who was interested in making some proposal around APIs and Python and said, here, I want to propose this PEP, this way of changing Python officially for a new API.
What do you think about this proposal?
Well, this is cool, but really, I think the best way to do it would be just make a package that accomplishes the same thing, show that there's traction around it.
And then you could talk about bringing it back in and sort of like grow it up through the community.
And if it shows enough value, then all of a sudden you should have this conversation about should it be officially a part of the thing, which is almost the reverse of what you're saying.
Yeah.
Again, the thing about projects and products, right?
Like when you have a product, I'm going to assume you probably have a PM and your PM is probably going to do user research.
And they're going to do it.
I bet your PM has a PM.
Your PM probably has a PM, right?
To manage all the other PMs.
Right.
But what I'm saying is like when you're a product, you have resources financially to be able to do user studies and talk to customers directly and set up meetings and gather analytics and like all of these really cool things, which is great that you could do that.
But when you're a free open source projects, like what, like your resources, your community, right?
So like you said, like sometimes you just have to kind of like build up that culture of, hey, well, hey, we're going to release a new version to do switch statements in Python, right?
Or pattern matching or whatever the case is.
Yeah, exactly.
Like let's make it a library first and evolve it into something a little bit more substantial.
And if people are like, yo, we love this, maybe now like that could become a feature.
But the downside of that being, again, we don't, you know, there's no money engine behind of it.
That might take a little while.
That might take like two or three or four versions before that actually happens.
Or it might never happen if no one cares enough.
Someone who's actually a contributor to the project doesn't really, you know, they don't care enough.
But somebody who's using it, they might really care.
But it's not going to get there because there's sort of a mismatch and capability of changing it.
You know, I think one of the big things that's changed recently for us over in Python is that we've had this thing called the developer in residence.
Which Microsoft, Google, I think also Facebook, which I call the meta.
I think those three groups, hopefully that's right and exhaustive, have contributed a bunch of money through sponsorships to actually fund one or currently one, but possibly more than one person whose job it is to just sort of work on Python around all the rough edges.
And that might sound like the language rough edges, but what I mean is like people are submitting PRs or feature requests and nobody has time to really review the PR.
Like sort of almost project management plus development to just kind of like be the glue that keeps the community working together.
And I think that that's actually making a big difference.
That brings it a little bit closer to these things.
There's somebody whose kind of job it is to bring these features in.
Yeah. When you think about, again, a project evolving into something really substantial, right?
Like, and I look at Python as an extremely substantial project.
At some point, like you're going to need support, right?
Because now there's like a lot of things that need to get reviewed or fixed or discussed and talked about.
And like, whose time is that?
Right? Like who's going to do that?
Right. But like now when the project is at the point where, well, my business needs this thing to run.
So you better figure it out kind of thing.
At that point, like that's why it's so important for like, you know, not even just major corporations, but all of us that use it to find a way to like contribute in whatever way that we can.
You know, obviously for bigger companies, like again, they could, you know, they could sign the check.
But for us, can we go ahead and have those discussions and talk about, well, hey, well, these are really useful features that it's useful because of this reason or because of these use cases.
Or these are scenarios that would help us be more productive, right?
And again, not just say I want stuff.
Well, let's have a practical conversation about like, how is it going to make everyone better?
Right?
Right.
There's a whole spectrum of that, right?
Like it could be just communicating with the project over issues and stuff to say, this is really important.
Here's our use case.
It could be, hey, I could actually make a PR on this and contribute a PR to a project you care about.
Or it could just be, I'm going to write a tutorial because this is really hard to get started with.
Right?
There's not, or even just documentation with examples.
Yeah.
And you bring up a great example of documentation, right?
Like I know this is such a cliche thing to say because we've been saying it for years.
But documentation is such, I don't want to say easy, but it's such a great way to get started in open source, in any open source project.
Because I'll tell you the folks that are writing the code probably don't have a lot of time to write documentation.
Yeah.
And they might not have gotten into the project because they love documentation.
They might have got in because they really wanted to write the code.
Right.
You know, when we think about projects, like just like how every language is good at specific things, people that work on projects are all good at very specific things.
Because I'm a good engineer doesn't mean I'm going to be a good manager.
And just because I'm a good engineer doesn't mean I'm going to be a good docs writer and vice versa.
You know what I mean?
I might be able to tell you how to do it.
But the way I communicate that to you, you might be like, yo, dude, I don't have a PhD.
I don't understand anything you just told me.
Right.
Versus like, okay, someone that could kind of sit in the middle and translate.
Not that we're translating languages, but like, you know, hey, how can I package this in a way?
How can I put this forward in a way that just makes it more digestible by whatever particular audience of folks that I'm trying to reach out to?
So again, if we're talking about students or folks in startups or big enterprise companies, like what are the things that are important to them?
And then how can I communicate that to those people?
Yeah.
But again, absolutely.
You know, when you're a big company, like you could pay for that.
Like you could pay people to do that.
Like when you're not.
You say it's now your job to do this thing and you better do it because you have a manager.
Yeah, exactly.
Exactly.
Yeah.
All right.
We're getting short on time here, Cecil.
But I do want to talk about one thing that I really admire about the .NET space.
And I think the reason I admire is I, among other reasons, is I think it really has a lot of relevance for Python people.
And that is the whole Blazor thing.
Oh, yeah.
It's Blazor.
Is it Blazor.net?
So one of the things that they did over at the .NET side is they came up with this idea of like a standard core.
And I've sort of taken a little, an inner essence of .NET that like this is the thing that we should have available everywhere.
And then there's a bunch of stuff that's irrelevant in certain situations.
Like, do you really need a UI GUI framework when you're on like a fridge?
Maybe do that.
Or, you know, like you're running just as a backend service on Linux.
You really need a UI framework for that, right?
And so out of that, to some degree, came Blazor, which is basically the runtime plus the language in the browser.
And we have that really, really close in things like Pyodide and the core developers have been building CPython really recently for WebAssembly, which is amazing.
Difference here is this framework has a front-end framework on top of it that is like Vue.js or React, but in C# on the browser.
And do you want to just riff on that a little bit?
I think if we had something like this in Python, I mean, this is basically how do you not have to write JavaScript on the front-end and have something really cool in your language and your runtime.
Yeah.
So kind of like what Michael just said.
So Blazor is the equivalence of React or Vue or Angular, but it's .NET for .NET developers.
And the cool thing about it, so I guess just a little bit of a backstory.
So Steve Sanderson, I believe is how you say this last name.
Yeah.
So he did a talk at NDC, right?
One of the NDC conferences where he showed how you can compile the .NET's runtime, right?
The actual, you know, thing that runs in a virtual machine, right?
Kind of like what Java does.
The .NET runtime to actually execute a WebAssembly, right?
And most modern browsers have like, you know, WebAssembly enabled today.
So again, assuming that you update your browsers, put them on auto-update, like you shouldn't really have to do a lot to just get that kind of stuff to work.
And so now that means, okay, well, if I can ship the runtime into the browser, that means I can run the language in the browser, right?
Which is really cool.
And so what Blazor Canada is, if you're familiar with .NET and you know what Razor syntax is, like from MVC days.
It's like a Jinja for us.
Right.
It's like a templating language, right?
Like if you understand how that templating language functions, which is essentially C-sharp in code.
Just like you said, like Jinja is Python and code, right?
It's Python and HTML, right?
So once you understand how that world works, now you can take those existing skills that you have and now you could write components that run inside of the browser.
And they're 100% in the browser, right?
Because now the runtime, you've just shipped the runtime, kind of like you would like a JavaScript file, like jQuery or whatever the case is, or your web pack bundle the thing, right?
You build it and you send it to the browser.
Also now it kind of runs there.
So that means, and sometimes people don't believe this, but what that means is that you could turn off the internet, right?
And then your app is still functioning, right?
Because the functionality is living in the browser inside of Blazor, which I think is really cool.
I think this is really cool.
And I don't really care that much for this type of app, say as like in my website, although I see uses there, but Electron.
You know?
Right?
Like if you could get something really rich like this and then turn it into a proper way to ship rich applications that are either progressive web apps or Electron.js apps, then you get a whole new avenue of types of apps that you can write that you wouldn't otherwise be able to.
So one of the things that the .NET team promised that was going to come out this year, hopefully comes out by the time build happens in May, is .NET MAUI, right?
Like MAUI, M-A-U-I stands for multi, oh my gosh, Microsoft application UI.
Oh my gosh, I don't remember what it is.
But whatever it is.
User interface?
I don't know.
User interface thing.
But essentially, MAUI is a way that you could write applications that exist across a lot of different places.
So if you think about like macOS desktop, Windows desktop, Android, iOS, those types of things.
But I could have like the single code base.
Kind of like Xamarin Forms, but like Xamarin Forms, the new like VNX kind of thing.
I bring that up because one of the things that they promised that we could do in MAUI is have a Blazor view, which essentially is Blazor running in MAUI.
So that means that like if I write a thing in Blazor, like my Blazor components that run on the web and do the thing, that means that I should be able to have that code exported and like embedded inside of an app.
And now that app could run across all those other places as well.
Right?
Interesting.
Think about the right once run anywhere thing that we've been chasing for decades, right?
Like we can write the thing in Blazor if we wanted to.
And now it can run not only in the web, but it can run on mobile.
It can run on desktop.
Not just Windows desktop, but also macOS desktop.
Mobile even.
The dream of mobile.
Yeah.
iPhones, iPads, Samsung tablets, and like all those kinds of cool things.
Yeah.
Absolutely.
All right.
Well, I think we have to leave it there for our main topic, Cecil.
But I feel like we have so much more to talk about.
Like that was so, that won't buy so quickly.
Maybe we'll come back and do another follow up episode.
People have a bunch of questions or something.
Yeah.
If folks want to know part two, they should let us know.
Leave a comment on the show or whatever the case is.
Yeah.
Don't bug Michael on Twitter.
Mostly the best place to leave comments is on the YouTube live stream.
Okay.
I turned off the comments on the episode page because they were forcing a bunch of third
party tracking onto our users.
And I'm like, ah, I really don't want to have cookie pop-ups and all these things.
Yeah.
And I'll just, yes.
Anyway, no more comments on the episode page, but on the YouTube live stream.
Absolutely.
Before we get out of here though, if you're going to write some code, I guess at this
point, it almost doesn't matter the language of C# or Python.
What editor are you using?
I pull out VS Code by default only because, again, I like, I like to focus.
You know what I mean?
And then if there's one IDE that can support multiple languages, like that's what I'm going
to do.
So VS Code is where I'm going to go.
Cool.
And I don't know if you have anything off the top of your head, any Python libraries
you want to recommend?
Have you come across any?
You know, I'll be honest with you.
I'm sure folks know about this already, so I'm not going to say anything different, but
I really want to learn about Scikit-learn.
You know, it's a machine learning.
Library, like I'm sure most of your listeners already know about, but I personally haven't
played around with it.
I personally haven't spent too much time at all in that machine learning space.
But I figured this day I want to try it.
Yeah.
I haven't either.
It seems so magical.
Like if you could crack it, you'd be able to build just amazing things, right?
Yeah.
So I've been playing around with just like doing data visualizations and stuff like that
with things like Seaborn or Matplotlib.
That's just me having data, wanting to draw like charts and graphs.
What I actually want to do is like analyze some of that data using like some of those
machine learning libraries.
And, you know, I figured learning a little bit of machine learning is not a bad idea, right?
And I think that's one of those places that Python really shines.
The ecosystem that it has within Keras, I think is what one of them is called.
And you think about PyTorch, you think about all the other really cool data analytics and
machine learning libraries.
For me, like it's just automatic.
Like I'm going to go to Python and I'm going to do that.
Yeah, absolutely.
All right.
Now close us out, you know, especially speaking to the .NET people who I may have dragged into
this episode, they're thinking of Python.
Maybe they'll try it out.
Maybe they won't.
What would you tell them coming from their C-sharp background?
If you look at one of those old, older Stack Overflow surveys, they'll always say like
Python is like the second language for a lot of C-sharp developers.
Because when you think about it, Python does a great job at allowing you to like execute
things very quickly, right?
And so for us, a .NET developer, if I need to analyze something, if I need to like, I don't
spin up a really quick web server and, you know, just do like some really quick things.
Prototype something.
Yeah.
Just put some data on the internet.
Yeah.
It's a great additional tool to have.
Now, it's more than just a tool.
But again, like if you're a .NET developer, that's your focus.
And you need something else to allow you to like move quickly, allow you to experiment,
allow you to kind of just like explore your world and kind of extend your tool belt a little
bit.
I think Python is a great option to do that with.
Right on.
Well, thanks for being here.
It's always fun to talk to you.
And it's been cool to sort of compare and contrast.
Sure.
Thanks for having me, man.
So I really appreciate it.
You bet.
Bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
Teams using Cast AI see an average of 50% or more savings on their Kubernetes clusters.
Your friendly cloud giant is making tons of money.
Don't send them more than you need to.
So why not scan your cluster to discover how much you could save?
Visit talkpython.fm/cast AI to get a free optimization report.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.