Oh this is neat. We do IAC, and whenever I do a change management audit, going through all the changes and who initiated them over the past year is a pain. With this you could make a pretty comprehensive report on demand!
A single race condition is a tragedy. A million race conditions is eventual consistency.
Okay, I love these features individually. I loved it when moving from java to kotlin. However, I'm conscerned that these features create multiple ways to do things correctly in C#. Having one way to do things, has been for me one of the best features of C#. It makes it easy to read colleagues code accross generations and easy to onboard new guys.
I do hope we see these adopted quickly, but I hope the C# folks dot start shoehorning in new syntactic sugar for no good reason. The language is starting to get a bit arcane.
Yeah for us, mermaid has been great to through in a documentation git repo and keep some consistencies. But 90% of the utility of a diagraming system is easily being able to draw something on a whiteboard with an almost empty marker and be halfway understood
Dotnet had really been the ecosystem i keep coming back to. It's been so frictionless. It could be experience, but I really never feel like I'm fighting with it. Running plain C might be the only other ecosystem that I would hold as a less frictionless experience. I genuinely don't hold any frustrations with it. I don't have any ideological problems around Microsoft's involvement. The tool lets me solve problems effectively.
The only thing Im missing is a good llvm target for the clr something like what the kotlin native guys enjoy so i can take the ecosystems to new places.
Sure EFcore can be tiresome and LINQ is inefficiënt. But I'm going to be honest here. If you're trying to squeeze performance out of an ORM and you're running up against performance limits of LINQ, maybe not use a time-saving tool as a power tool?
Maybe I'm simping a bit over it, but I'm not seeing alot of positive content about a tool that has only been very productive in my experience. Maybe because all of the dotnet users are too busy solving actual problems for people haha 😂
Oh and newtonsoft... And maybe xUnit and nUnit could make up and figure out a way to be ergonomic AND work well multi-threaded.
I agree that credential management can be tricky. But genuinely after working from framework to core for over 15 years, publishing an consuming packages has been the best experience for me out of all other ecosystems. Maybe node is easier, but I've been burned too many times by supplychain issues to feel safe with it.
There was a period between 2016-2019 where due to error codes and no error messages it was a bit trickier to resolve the 'yellow triangle of doom'.
But honestly compared to pip and cargo and Gradle Nuget has been a damn godsend.
If OP play their cards right they have a wonderful legacy support gig for life
Counter point. Sounds like a c-level pet project on steroids. It doesn't sound like anyone is planning a migration. So they are relying on a big bang.
Now... A question for the panel: how would you say big bangs on corporate software projects with actual customers typically go?
I think you might be out of luck. Even C# projects use a different semantic with dotnet6.
I spent a good long while reimporting resource references and rewriting code.
It was totally worth it tho!
I get that. But then I have a VM that I have to run and support and put effort into CICD. The nice thing about native stuff, is that they can scale independently, don't need updates, integrate with the ecosystem, and for the standard tiers can run on the cheap :)
Man, micro-services really could mean anything...
Whenever possible, I've run projects to have zero downtime deployments. Multiple stateless instances behind a load balancer. Deploy one instance at a time, run a health check and move traffic to the fresh instances. Most cloud providers often have these out of the box. Database migrations are run well in advance. New functionality is hidden behind feature flags.
Zero downtime is nice, but the real benefit is that you force the teams to really think about deployments as migrations to accomplish this policy.
Your instrumentation and alerting need to be top-shelf you need to automate deployments fully, which means you can fully automate rollbacks.
The downside is that you have to build everything twice, deployments are slower and there is a significant descaffolding.
But that's a small price to pay not to be on call outside of business hours to deploy.