Beyond that, the fact that you have to do any of this is silly. The .Net tooling used to be easy, now you’ll be able of building your entire application in python before you’re even done configuring your .Net environment.
I know I’m grossly exaggerating, but the fast movement and the lack of ease of use has been one of the primary reasons to see us slowly move toward python and powershell after nearly two decades of C#. Being a windows happy enterprise org, we still make plenty of use of the .Net family and friends of course, but not really for development.
Who said you have to? In fact you don't at all. He's only pulling in 5 dependencies. One is a command line option parser which you'd have to pull into a python project as well. The second is a bridge for that parser to integrate with the dependency injection - which you arguably may or may not need. Third & Fourth are for logging. The last one is completely unnecessary and can be ignored. Again it's just his way of doing things.
But lets not create this false narrative that somehow .NET has become super complex. Anyone can create a console application with -
Net tooling used to be horror. Now its good. Speaking as someone who does CI/CD work on it for a long time. You seem to speak as someone who doesn't have .net muscle memory.
Programming is complex, unless you finish with hello world (even hello world is complex in enterprise environments).
Except it isn't. We obviously had setups that mirrored production long before docker and CI/CD became a thing, but spending time configuring those things, for every project is just insane.
Even pythons virtual environments take less time to use than .NET.
Sure I actually liked the "double click" thing in Visual Studio, but that had nothing to do with "if it works on my computer", it simply saved bundles of time because we'd publish every project to the same damn IIS instance and not have them all run their independant web-servers with their independant setups.
Hell we still put things behind the same damn IIS instance and it's load balancer and all that, because why wouldn't we? We're not Netflix, we don't need to scale to two billion people. Our max load is 50.000 concurrent users, yet our build load and our deployment pipeline is now so best-practice, SOLIDVOLID, Buzzworded, CONSOLELIEK and complicated might actually work for Netflix with enough iron.
What's worse is that, it's now your job. Not the operations dude who actually specialize in this, no yours, along with keeping up with you know, actual programming.
Being the public sector, we benchmark everything, and the things we don't benchmark we hire E&Y to benchmark, and you know what our most expensive resource has seen the biggest increase of their time going into over the past 30 years? Configuring and maintaining their tooling. Not developing new things that are useful for our actual business, no sir, but working with the tools that allow them to develop things. It's up by 130% compared to 1998.
I'm not sure what you'd call that inside big-tech, but in non-tech, we tend to call that, a waste of resources.
At least we can lower the cost by vendor-lock-in with azure, right?
> The .Net tooling used to be easy, now you’ll be able of building your entire application in python before you’re even done configuring your .Net environment.
> I know I’m grossly exaggerating...
I do not even think it is an exaggeration. Even the non-performant Python still feels like a hacker's, get-shit-done language compared to .Net. Anything .Net still feels like slow, enterprise bloat. Even "dotnet build/run" is slow, no matter size of your project.
I know I’m grossly exaggerating, but the fast movement and the lack of ease of use has been one of the primary reasons to see us slowly move toward python and powershell after nearly two decades of C#. Being a windows happy enterprise org, we still make plenty of use of the .Net family and friends of course, but not really for development.