#363: Python for .NET and C# developers Transcript

00:00 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 Philip, who does both Python and .Net and 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.

00:23 This is Talk Python to Me, episode 363, recorded April 13, 2022.

00:41 Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy. Follow me on Twitter where I'm at @mkennedy and keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter via at talkpython. 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.

01:08 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. You're located in the American Southwest, so you 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.

01:58 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/losalamos' 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 links right in your podcast player or on the Episode page.

02:19 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/assemblyai'.

02:32 Hey, Cecil.

02:33 Hey, what's going on?

02:33 It's going to be fun to just chat about past, future, present. I see you're wearing the C# shirt.

02:39 Yeah, I decided to wear this today. Also, this is a vintage shirt, like you can't get these anymore.

02:44 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 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 today was a special occasion. I wear it today.

03:05 Yeah.

03:05 For for sure.

03:05 Sure. I got my Vivaldi shirt off today, which should have brought my Python one. 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 some of my live streams set up is actually thanks to you, because that's awesome. You blazed the trail, which is awesome. You and it was Brian Clark, right. Who had been doing your Python livestream.

03:30 Right. Yeah.

03:31 Back when Brian and I were both at Microsoft, we're doing a Py Weekly live is what it was called. We were just kind of looking at Python from a perspective of people that don't do Python for a living or I don't push Python production or I don't maintain Python open source libraries, but it's still cool language. And we wanted to learn it right. And we wanted to learn in public. And I think as advocates are pretty much just as anyone, I think now learning in public is a great way to not only help yourself, but also help the community, too. It is.

04:02 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 then. We also talked about developer relations and what the heck is that with you, 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 it'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 almost all the axes. It looks really weird from a .net perspective. Right. 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, 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 looking 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.

05:27 Yeah, I think so, too. First of all, I want to tell folks this is not like my language is better than your language kind of conversation here. We all like each other. But I always find that if you kind of look through, like the history of programming languages, we all kind of evolved together. We all borrow features from each other, whether it's libraries or actual language core features or whatever the cases. And 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, okay, well, I know how that works for me. So now maybe I can pick up your language a little bit easier because I already know that particular concept.

06:08 Yeah, I totally agree. And it's not a one way street either. For example, we in Python have async and await 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, which I think is quite interesting.

06:27 Another thing that C# has, and if, you know, I think it was in C#9, it might be mistake. I think it was C#9

06:34 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.

06:41 C#9, this is like a lot of releases.

06:43 Yes. I think C#9 was two years ago. So last year's version was C# 10. And then C# 11 is going to be released in November of 2022. 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 when I actually really appreciate is records. When I think about records, I almost think about data classes in Python.

07:07 Yeah, they're very similar.

07:08 I think about these mutable classes, these mutable types that I have, and essentially their job is really just to pass information back and forth. But I want to say I feel like Python had that first.

07:19 Again, I got that like two years ago. I'm not sure how old data records are or data.

07:24 Yeah. Data classes, I believe are older than two years, but I'm pretty sure. But yeah, I don't totally remember the exact release number it was. 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 do I actually have a ton of experience in that before I got into Python. But let's imagine that you don't know a lot about Python and you're thinking about 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 more like I was 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, if I had to leave this feature or this language thing behind, it would nearly kill me to do so.

08:37 Yeah, I think for me and it's almost not so much so for me about the language because like you mentioned before, we've had the opportunity to play around with 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 library.

08:54 It's the tooling and the library.

08:55 The tooling, the library and the integration 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 for .Net developers may already know this, but 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 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 roots 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 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 the right subset of them run.

10:05 Right. Maybe have a web front end and some API back end and they both need to be running that type of thing, right.

10:11 So for me, 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 select multiple projects to start, like when I started debugging sessions so that whenever I hit F5, famous F5, start and run and do all that types of stuff. Now I'll have 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, all those types of stuff. Whereas again, if I walk away from the 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.

10:59 Well, let me riff on that for a minute. So often what you'll see in the tutorials and stuff that getting started stories in the Python space is creating a blank Python file called app.py, main.py, whatever.

11:15 And write this bit of code. 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 where do the static files go? Where is the JavaScript? How do I align that? What do I do with my view templates versus 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, 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 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, I don't really need two layers of Redis one layer of Redis was enough. Like, why is all this stuff here?

12:25 Right.

12:25 People get carried away with it, but you can generate those types of 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.

12:42 Right.

12:43 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?

12:49 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 and that getting started experience and that evolvedability of the language I think is important. And I think that's one of the reasons why people latch onto it so much. Because my barrier to entry is like extremely low. It is literally like a file and whatever Python runs that you have on your machine, you know what I mean? Yeah.

13:19 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.

13:33 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.

13:41 Exactly. And when I think about that. Right, if I think about the structured nature of Visual Studio style projects and .Net projects and C# projects, and unlike you mentioned, like the Python projects and even the cookie cutter stuff or whatever, the cases, I have to kind of look at the history and see what space did these ecosystems kind of evolve in.

14:03 When I think about that .Net ecospace, for folks that are listening, that's mostly where I spent a lot of my time in terms of my career coming forward. I think about schools and enterprises and big companies that need like structure. Give me the structure, and then 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, OK, 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 execute experiments, not experiments. From the perspective that the code is not important, the code is important, but the task is more important than the code is. If that makes sense.

14:48 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, 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.

15:06 I need to copy these files over here and then rename them and then put them on S3. Right. That's not a super structured experience, but Python's really good at it.

15:15 Often it's used for it. Yeah.

15:17 And I agree with you when we look at where both of these languages come today. So if you kind of look at okay, now is what Net is like 16 17 years old, something like that 20.

15:29 I think it's 20.

15:31 I think there was a whole Richard Campbell and crew have been going on about the anniversary and stuff.

15:36 Right. So if you look at languages 20 years later, your initial intent was this. As the world evolves, as the world's software development evolves, and then now we're as developers, we're looking at attaching on to new work types, and you're hearing about Kubernetes and mobile apps and all these types of things. Now our languages kind of have to evolve with us. Right. They have to evolve with the industry. And so now some of those initial use cases have expanded and multiplied, and now we've got to take care of all of these other things, though, as well.

16:07 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 ten years. Is the open source, the open sourcifacation 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 was no GitHub and PR's and all of this sort of formal open source structure, it was just released on usenet and other places, whereas .net has been a product for quite a long time. Right. It was a way to build things in the early days for Windows servers and for Windows and the Microsoft Tooling. And 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?

17:10 Yeah.

17:13 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 cost, 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 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.

18:17 Again, when we look at the history of things. Right. For me, the initial intense 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 at that time? You go back to like 2001, 2002. Right. That's what we're talking about.

18:37 And at that time, mostly we're talking about desktop applications. Right. Like, we're thinking about Windows Forms.

18:42 This is the successor to Visual Basic Six and all of its glory.

18:46 Right. Like the drag and drop UI's and all that types of stuff. Right. And then eventually that evolved into Win Forms and those types of things. But still from a very Windows specific perspective. And then now we forward on to, 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. How do we plug into Redis? How do we plug into Rabbit MQ? How do I plug into Docker and Kubernetes? Right. A lot of these things have their best experiences on non Windows machines. Right. So how do we not plug into that ecosystem and evolve to kind of follow along with the rest of the industry is going. And so that's why you'll see now .net it's open source. Now it runs on armed devices that it runs on what's that? The M1 Mac.

19:59 Yes, it runs on our Mac. Right.

20:01 It runs everywhere that you could potentially want it to run. It I'm pretty sure it runs on like Apple watches and on your fridge if you have a Samsung fridge, like all these different places, which is really crazy to think about again, like looking back at the history of what this thing was initially intended, for sure.

20:19 To me, the biggest 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 1000 flowers blooming and some of them growing maybe in adult 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 could 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.

21:12 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.

21:23 Right.

21:24 It says you will use this web framework ASP Net, some variety. You'll use this data access framework in any framework, probably of some variety. Now go, 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. Ok. First you begin the web framework selection story, Flask, Django, Pyramid, FastAPI, Tornado, 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, every step 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?

22:34 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?

22:42 Right?

22:42 Yeah.

22:43 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 our projects are successful. Right. And hopefully it will grow with me if you kind of go back against that Microsoft thing that you're talking about. Like you said, Net was not originally open source. And Net is a product that was essentially created to make it easy to build things on Windows. And now again, over time, it's become open source. Now it's in the cloud, it 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.

23:27 It's intent from the beginning was already like, hey, I have a community of people that are going to come and latch onto 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 type and research and all these other things to tell you this is the right way for me to do things. 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. 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 it looks different because it came from different people. Just like, again, like telling a story, drawing a picture, or 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 of your foundation 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 found new project that you can get ASP. Net and editing framework and right click Publish to the cloud. And then you could just be like, okay.

24:57 And by the way, when you publish the cloud, how many cloud vendors do you get? Usually it's Azure, right?

25:03 I mean, if you're talking about Visual Studio out of the box, right.

25:09 Just being like that's another thing that's sort of like strongly encouraged as one more choice.

25:13 Yes. That's another thing you have to think about. Right. 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 how this thing is structured and where my dependencies go, how they define 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 augment some of those additional things that are in there and do some of that type of stuff, then maybe again, you want to make some different choices.

25:52 One thing that just occurred to me, I think is pretty interesting as a difference here is you talked about the benefit of all the tooling, like on the 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 in framework, 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, whereas in our space we don't have those 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 better on this one, even though it doesn't fit traditionally like, exactly, yeah.

26:55 I think there's definitely something to be said if you walk into a world where the entire stack is unified. When I say that I can go into a place and the programming language runs on the operating system that they built, that runs, and the IDE that they built, that runs on the cloud that they built, that runs on the DevOps, pipeline, security, whatever that they built, and it all plugged in together. And so with that integration, like you said, you can get a different level of visualization, a different level of reporting and metrics and all of that types of stuff with a lot less work now that you can't get it from other places, but it's just a little bit more work to get it to kind of put those puzzle pieces together to make the world look like how you want it to look.

27:41 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.

27:50 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 the micro service matrix.

27:56 Yeah. Before you get into it, 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, not at Stripe. Right.

28:07 We didn't point that out.

28:08 Right.

28:08 I want to point out that you're not actually at Microsoft anymore.

28:11 I'm not a Microsoft anymore. So there's no background baseball happening here. I'm not sharing anything that I know more about than anyone else at this point, kind of going back to, if you think about the world of, like, micro services, 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. Like I mentioned before, 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? I have to choose a thing. Right. And so now you're sitting down, having to make some of these decisions about what's the right way for me to compose, and then also what are the right combinations of tools that I've got to compose it with? So if we come back now to the level of just talking about Python. Net, again, it's a very similar thing where you can just say, hey, just give me the menu. Right. The GUI like file, new block. And there's a thing. Or I could sit down and I could fine tune and optimize my application to perfection or what we consider to be perfection, to run and work and have the right integrations of things that I wanted to have. And like I was saying, there's no wrong way. It's just a matter of for your business and what you're trying to do. What do you think makes the most sense?

29:41 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 many people do. Let me just use Django. If 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 in something that could be SQL Server, but more likely it's Postgres. Here you go. But I personally very much appreciate the ability to look at all those options and go, no, for this one, I want to use FastAPI and Beanie rather than Django and Django ORM.

30:26 And that's what I'm saying, like, depending on what your goals are. So I know for you, you have your Talk Python websites and your courses, I believe you all have a mobile app, too, right?

30:35 Yeah, we do. That's actually. Xamrin, shout out to the shirt.

30:38 I didn't know that. That's cool.

30:39 The APIs are all Python, but the front end, like mobile app itself is Xamarin.

30:43 It's all Xamarin. Okay.

30:44 Yeah.

30:44 So for your web experiences, 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 one, sometimes someone's opinion just doesn't line up with what you're trying to do. But then on the other side, sometimes there's just too many opinions. You're like, oh, man, can I choose this or this or that or the other? What's the right puzzle piece for me?

31:14 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.

31:40 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 born for another situation. I believe you're having a relational database and around 100,000 or fewer users a day. But if it's significantly different in some other direction, then maybe you should make different choices. Right. And having that flexibility is awesome.

32:05 Yeah, for sure.

32:07 And then kind of going back to what we're talking about a little bit earlier with the tooling. Once you've made those choices, now you have to make the 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.

32:23 So 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. We might want to grab a bunch of different tools and kind of put them together again, all depending on what we're trying to do with our use cases. And I think with that, too. What you notice is that the culture of either side 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 it is 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, the culture is probably different. Right. It's probably a little bit of Mongo or Postgres, it's probably a little bit of Glasgow Django and probably now FastAPI, because I know that's another popular thing. And 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 info on the show, so it could be that too.

33:30 Right.

33:30 But that culture is different. You know what I mean? And so the expectations about how software is built is going to just be totally different.

33:38 Yeah. When I opened the 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, it might not like they just don't want to consider it, which I think is an interesting angle. It's very much at odds with that. You have a thousand choices.

34:15 Yeah. For me, as a net developer, before and during and after Microsoft, that's one of those things that's such a hard habit to break.

34:24 Do you agree with my assessment?

34:26 I agree with your assessment 100% for sure.

34:27 Okay.

34:28 And I think it's something that particularly when you're living in an open source development world, like majority of us languages and tooling and stuff are open source, we have to be able to like, developers still have to develop, and you can't really expect things to always be given to you all the time. So when I say that 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 evolving over time.

35:06 Growing up through their career.

35:07 Growing up through their time, 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 I'll use, but those things are usually recommended. If you think about like, Json. Net as an example, those things are usually recommended from the box and then not going to use that. Right, right.

35:29 They might actually be third party, but they end up getting installed anyway.

35:32 Exactly right.

35:33 Like a pip dependency effect.

35:35 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, it shipped with Jquery. And so anytime you did find new project NVC automatically, you had Jquery, you had Jquery validation. And I think there's a couple of other libraries that were in there. I think Jquery UI maybe might have been in there or something else like that. Right.

35:56 Yeah.

35:56 But again, these are the things that just come out of the box with 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, 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 see why people are so invested in this ecosystem that they're constantly trying to make it better. And they're constantly trying to 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 if it's not in the box, people are like, I'm not messing with it versus on the back, on site.

36:38 It's like we'll just make it sure the realm of possibility is wider. Yes.

36:42 We'll just make it we'll make it together, 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 pydantic and static and some of those other things that have come up pretty slow.

36:54 Absolutely.

36:55 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, Pythonic and some of the new language features of Python 3567, somewhat enforced typing information, data classes, those kinds of things, the Async and await.

37:22 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 and has some very good positives. Like, there are people who are constantly focused on 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 means the language is always changing.

38:02 Maybe if it doesn't even need to.

38:05 That's my favorite. You 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, and if there's no new keywords, then what's their job about? Yeah.

38:16 So for folks that don't know, .Net as an entire product and family of things, has gone through changes over time. When Michael and I first started doing it, it was Net Framework. And then over time.

38:28 It became back in early 2000.

38:31 Right. And then it evolved into what today is known as, like, .net core. And I think that net core went from 1.1 to three point something 3.1 or something like that. Right. And then after that, we skipped a number. We skipped four. Right. I don't know why we skipped four, but we skipped four. And then we went to .Net5, not net core five, 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. Net5. What's happened over time now with .net five and six, seven. And until they decide to call it something else, what's happening right now is that it switched to like this yearly release cycle.

39:11 And I'll be honest with you, I don't know how I feel about it yet. We're looking at net7 coming up in November. So it's really only been five and six. We've had two versions that have been on this yearly release cycle. I don't think that's enough time for me to see how I feel about it and see what the actual effects of that are for sure. My initial thoughts are I don't think we really need to release that quickly because like you said, 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.

40:00 They're going to end up in a code base that's going to be ten years old with three flavors of Lambda expression.

40:06 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 to do application. And so now, like the minds like the mental effort. So now you kind of have to exist in multiple worlds. Here's the new cool stuff. And if you're lucky, maybe you started a company that's doing the new cool stuff, or here's the framework stuff, or the older tooling, or here's this older version that's still kind of new but still doesn't have the things from six or seven. And it's like, well, if I'm considering myself a Language X developer, how many of these new language features do I need to know?

40:46 It's a really good question.

40:47 Let me just give a little bit of background for people who obviously most people this probably don't work in C#, but C#, like Python, has a way to express properties. Honestly, C# way is way better than Pythons. There is a way to do Lambda expressions that's very similar across both languages. But if you look on the C# way, 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? 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 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.

41:43 Yeah. And I agree with you. I think that's another thing that I feel like I've really appreciated about the Python ecosystem, because Python also has a scheduled cadence of release.

41:54 Yeah. And it's yearly as well now.

41:56 And it's not like Python hasn't updated the language in like six years or whatever the case is. Like you said, there's async await and there's new operators and things of that nature. But I always find that the additions to the language, I think with the exception of maybe typing, 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 time it happens in the core library and not so much so on the language surface. And then the few that happen in the language service.

42:25 Yeah. Or some package, but you don't have to know about it to consume it, something like that.

42:30 Right. And then the things that happen on the language servers are usually very subtle. We'll have a whole version and they might add like one operator. Right.

42:37 Yeah.

42:37 Or you might add again, like async 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 I've added this one big feature. But then 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 if you're on modern Python, I'm going to use the term you use. Right. If you're on modern Python and you're 3.4 or five 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. Might be some extra things. We could probably ignore it if you don't need it. But then you should be able to be functional and not have to think too much about like, okay, how do I plug this thing into this thing? And then, oh, my thing is not compiling anymore because I don't have the new version, even though I'm not using the new version features and all of that. Yeah.

43:30 It's interesting, I think that we use the language as an example, but I think that influence happens across different, many things across the Web frameworks, across the database, across the Twilight and so on.

43:41 All right.

43:41 A couple of thoughts from the audience here.

43:43 Mr. Hypermatic says hello, looking sharp. See what I did there? Loving the shirt.

43:49 And Christopher Tyler has more actual question here are the contributors to Net, primarily people who work at Microsoft. That's the same for C#. What's the open source story on that? We know in Python, there's the cordevs, and then there's the sort of everyone else layering, but that's not nearly as extreme as employee, not employee.

44:09 Yeah. I can't talk to the percentages in terms of what percentage 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 all these types of things.

44:30 Let me see if I can open it up. I think if you go to GitHub. Net, and I think if you go to .net/C#, I'm not mistaken. No, it's not C#. There's a language proposal thing. I don't remember what it's called, but there's runtime. Maybe it might be in the runtime. There's a repo in here that you can essentially submit proposals whenever there's a new version of C# that's coming out. Or if you want to know. Okay, well, I want to maybe we should change our interfaces work or how do we add records or whatever pieces. There's a repoint here that you can do that. I don't remember what it is at the time. I probably should.

45:08 But what I'm saying is that as a person that does not work in the company, you can have 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 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 do that. They don't do that.

45:38 It's not like they own GitHub. Wait a minute.

45:42 You see what I'm saying? All right. You can have that open discussion about like, okay, these are some of the things I think make a lot of sense.

45:49 That's really good. And it's certainly a big change that's happened over the last five years there.

45:54 I found it C# Lang. So it's not just C Sharp, it's C Sharp. L-A-N-G. Yeah. So if you go there, you should be able to, again, the language design repo.

46:05 Yeah. The active C# language feature proposals and meetings and. Yeah, interesting.

46:10 Yeah. Some of those meetings are they're public on their online. I know Emo is one of the folks that work on C# and the runs like they do API reviews and all these types of things livestream it I don't know if you've ever sat down in an API review. It's not the most page turning thing to sit down on my computer, but you could have used. But if you wanted to, 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.

46:50 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 podcast, 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 that's absent in the Python world. Right.

47:30 There's none of this 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 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. In that sense, that's a pretty big difference of the ecosystem.

48:03 Yes. I think it kind of goes back to what we're talking about before. Right. In terms of culture, the culture of Python has always been like an open project that we all kind of work on together versus. Okay, here's a products from Apple or Microsoft, and I'll date myself a little bit. I remember when you used to have to wait until magazines came out to learn about beta features that have like little CD in the back bars and Noble or whatever.

48:31 Macworld or MSDN or any of these things.

48:34 Right. There'll be CDs in the background, magazines. And that's how a lot of developers back whenever used to be like, oh, okay, this is what's coming out. And you'll read about it, right.

48:46 Youtube wasn't a thing for developer videos and livestreaming. All these things that we do now where we can get more immediate feedback, the magazine is going to go out. But then think about it. 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? Is that active?

49:05 And how far, far back is the editorial schedule versus the writing? That's months, right.

49:11 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. You could have changed all kinds of stuff. But what I love again about the culture of where Python has started, like the feedback mechanism is so much faster and it's been like that by default. Yeah, 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, let's shorten the feedback mechanism let's get more immediate responses on things. Let's allow folks to 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 work with us and talk about like, okay, well, I learned this in class. Now I'm seeing it over here. I understand how this works. Let's kind of collaborate a little bit closely together.

50:02 Yeah, certainly it's a different way of working on it. You don't have to wait until the one thing has been released. 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 can 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.

50:51 Yeah. Again, think about projects and products. Right. 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.

51:00 I bet your PM has A-P-M.

51:02 Your P. M. Probably has A-P-M. Right. To manage all the other PMS. Right. But what I'm saying is when you're a product, you have resources financially, be able to do user studies and talk to customers directly and set up meetings and gather analytics and all these really cool things, which is great that you could do that. But when you're a free open source project, like your resources, your community. Right.

51:26 Sometimes you just have to kind of build up that culture of, hey, well, hey, we're going to release a new version to do switch statements in Python or pattern matching or whatever the case is.

51:37 Yes, exactly.

51:38 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 that could become a feature. But the downside of that being, again, 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.

51:58 Or it might never happen if no one cares enough.

52:03 Right. Someone who's actually a contributor to the project, 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. 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 called 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, 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 a little bit closer to these things. There's somebody who's kind of job it is to bring these features in.

53:11 Yeah. When you think about, again, a project evolving into something really substantial, and I look at Python as an extremely substantial project, at some point 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 whose time is that?

53:32 Who's going to do that? But now when the project is at the point where my business needs this thing to run, so you better figure it out kind of thing at that point. That's why it's so important for not only just major corporations, but all of us that use it to find a way to contribute in whatever way that we can.

53:51 Obviously, for bigger companies, again, 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, let's just say I want stuff. Well, let's have a practical conversation about, like, how is it going to make everyone better? Right.

54:16 Right. There's a whole spectrum of that. Right. 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, or even just documentation with examples.

54:38 Yeah. And you bring them a great example of documentation. Right. 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 it's easy, but it's such a great way to get started with 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.

54:58 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.

55:03 Right. When we think about projects, 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, dude, I don't have a PhD. I don't understand anything you just told me. Right. Versus like, okay, someone that can kind of sit in the middle and translate. Not that we're translating languages, but like, 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 talk about students or folks in startups or big enterprise companies, what are the things that are important to them? And then how can I communicate that to those people?

55:56 Yeah, but again, absolutely.

55:58 When you're a big company, you could pay for that.

56:00 Like, you could pay people to do that when you're not saying it's now your job to do this thing and you better do it because you have a manager.

56:07 Yeah, exactly.

56:09 Yeah.

56:10 All right.

56:10 We're getting short on time here, Stefan, but I do want to talk about one thing that I really admire about the. Net space. And I think the reason I admire, among other reasons, is I think it really has a lot of relevance for Python people, and that is the whole Blazer thing.

56:31 It's blazer. Net. So one of the things that they did over at the dotnet side is they came up with this idea of like a standard core. And I sort of take an inner essence of Net that 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, you really need a UI GUI framework when you're on a fridge. Maybe you're running just as a back end service on Linux. You really need a UI framework for that.

57:06 Right.

57:07 And so out of that, to some degree, came Blazer, which is basically the runtime plus the language in the browser. And we have that really close in things like pyiodied. And the core developers have been building CPython really recently for WebAssembly, which is amazing.

57:26 The 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.

57:39 Do you want to just riff on that a little bit? I think if we had something like this in Python, 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?

57:51 Yes. 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 his 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 runtime the actual thing .Net runs in a virtual machine, kind of like how Java does the net runtime to actually execute a WebAssembly. And most modern browsers have WebAssembly enabled today. So again, assuming that you update your browsers, put on auto update, 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 shift the runtime into the browser, that means I can run the language in the browser. Right. Which is really cool. And so what Blazor Can is if you're familiar with Net and you know what syntax is like from MVC days.

58:56 It's like a Jinja for us.

58:58 Right. It's like a templating language. Right. If you understand how that templating language functions, which is essentially C# and code, just like you said, Jinjar is Python and code. Right. It's Python and 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 cases or your webpack bundled the thing. Right. You build it and you send it to the browser once I know 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.

59:45 I think this is really cool. And I don't really care that much for this type of app, say in my website, although I see uses there. But Electron, 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.

01:00:12 So one of the things that the Net team promised that was going to come out this year openly comes up by the time build happens in May. Is .Net Maui, right. Like Maui, Maui stands for multi oh, my gosh. Microsoft Application UI. Oh, my gosh. I don't remember what it is.

01:00:28 User interface. I don't know.

01:00:29 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 Xamarin Forms, the new Venix kind of thing. I bring that up because one of the things that they promised that we could do in Maui is have a Blazer view, which essentially is Blazer running in Maui. So that means that if I write a thing in Blazer, like my Blazer components that run on the Web and do the thing, that means that I should be able to have that code exported and embedded inside of an app. I know that app could run across all those other places as well. Right. So interesting thinking about the right once run anywhere thing that we've been chasing for decades. Right. We can write the thing in Blazor if we wanted to. And now it can run not only on the web, but it can run on mobile. It can run a desktop, not just Windows desktop, but also macOS.

01:01:29 Desktop, mobile, even the dream of mobile.

01:01:31 Yeah. iPhones, iPads, Samsung tablets, and all those kinds of cool things.

01:01:36 Yeah, absolutely.

01:01:38 All right.

01:01:38 Well, I think we have to leave it there for our main topic.

01:01:42 But I feel like we have so much more to talk about that went by so quickly.

01:01:46 Maybe we'll come back and do another follow up episode if people have a bunch of questions or something.

01:01:50 Yeah. If folks want to do part two, they should let us know. Leave a comment on the show or whatever the case is. Yeah.

01:01:56 Mostly the best place to leave comments is on the YouTube live stream.

01:01:59 Okay.

01:02:00 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, I really don't want to have cookie pop ups and all these things.

01:02:14 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, C# or Python, what editor are you using?

01:02:26 I pull out Vs code by default only because again, I like to focus.

01:02:33 And then if there's one idea that can support multiple languages, that's what I'm going to do. So VS go. Cool.

01:02:40 And I don't know if you have anything off the top of your head, any Python libraries you want to recommend if you come across any you know.

01:02:45 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.

01:02:54 There'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.

01:03:04 I figured the way I want to try it.

01:03:06 Yes. I haven't either. It seems so magical. Like, if you could crack it, you'd be able to build just amazing things, right?

01:03:11 Yeah.

01:03:12 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 wanted to draw, like, charts and graphs. What I actually want to do is analyze some of that data using some of those machine learning libraries.

01:03:27 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, it's just automatic. Like, I'm going to go to Python and I'm going to do that.

01:03:48 Yeah, absolutely. All right. Now close us out. Especially speaking of the Net people who I may have dragged into this 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# background?

01:04:02 If you look at one of those older stack overflow surveys, they'll always say, like, Python is like the second language for a lot of C# developers. Because when you think about it, Python does a great job at allow you to execute things very quickly. Right. For us, .net developer. If I need to analyze something, if I need to spin up a really quick web server and just do.

01:04:24 Like, some really quick things, prototype something. Yeah, just put some data on the Internet.

01:04:29 It's a great additional tool to have. No, it's more than just a tool. But again, if you're a lead developer, that's your focus. And you need something else to allow you to move quickly, allow you to experiment, allow you to kind of just explore your world and kind of extend your tool belt a little bit. I think Python is a great option to do that.

01:04:47 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.

01:04:53 Sure. Thanks for having me, bud. So I really appreciate it.

01:04:55 You bet.

01:04:55 Bye bye.

01:04:57 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/castai to get a free optimization report on the 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 site. Check it out for yourself at Training. Python.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 GooglePlay Feed at /play and the Direct rss feed at rss on talkpython.FM.

01:05:58 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/

01:06:07 Youtube. This is your host, Michael Kennedy. Thanks so much for listening, I really appreciate it. Now get out there and some Python code.