We used to have some C# but we moved away from it to have fewer languages and because it was a worse fit for us than Go and Python. I'm not sure .NET would really give us any advantages though. Microsoft treats most major languages as first class citizens in Azure, and since we build everything to be sort of platform agnostic, we wouldn't have the tie-ins that you could have with .NET. I'm not saying it would be fun to switch cloud, but all our services are build so that there is a decoupled "adapter" between our core logic and Azure. We use a lot of Azure functions as an example, but they run in container apps on a managed k8s, so the Azure function part is really just an ingress that could be swapped for anything else.
It's been a while since I worked with an "actual" function app in Azure. We did have a few .NET ones that weren't using containers. At the time they were pretty good, but today I'm not sure what the benefit over a managed container envrionment with container apps would be. Similarily with sqlserver. We use it because of governance and how it ties into data factory and I guess fabric, but we don't use ORM's so something like Entity Framework wouldn't really be something we'd benefit from with .NET.
I think the only thing we couldn't realistically replace and get something similar is the governance, but that's more to do with how Management Groups, Policies, Subscriptions and EntraID works than anything else.
Eventuallyt everything will probably be Python and then C/Zig for compute heavy parts. Not because Python is great, it's terrible, but it's what everyone uses. We're an energy company and with the internal AI tools we've made widely available we now have non-SWE employees writing code. It's Business Intelligence, it's Risk analysys, it's powerplant engineers, it's accountants. They're all working with AI code in their sandboxed environments and it's all Python. Since some of it actually turns out to generate great value, it's better for us (and the business) if our SWE teams can easily take over when "amateur hour" needs to meet operational compliance for the more "serious" production envrionments. I put things in "'s because I'm still not entirely sure how to express this. A lot of what gets build is great, and would have never been build without AI because we don't have the man power, but it's usually some pretty bad software. Which is fine, until it isn't.
We used to have some C# but we moved away from it to have fewer languages and because it was a worse fit for us than Go and Python. I'm not sure .NET would really give us any advantages though. Microsoft treats most major languages as first class citizens in Azure, and since we build everything to be sort of platform agnostic, we wouldn't have the tie-ins that you could have with .NET. I'm not saying it would be fun to switch cloud, but all our services are build so that there is a decoupled "adapter" between our core logic and Azure. We use a lot of Azure functions as an example, but they run in container apps on a managed k8s, so the Azure function part is really just an ingress that could be swapped for anything else.
It's been a while since I worked with an "actual" function app in Azure. We did have a few .NET ones that weren't using containers. At the time they were pretty good, but today I'm not sure what the benefit over a managed container envrionment with container apps would be. Similarily with sqlserver. We use it because of governance and how it ties into data factory and I guess fabric, but we don't use ORM's so something like Entity Framework wouldn't really be something we'd benefit from with .NET.
I think the only thing we couldn't realistically replace and get something similar is the governance, but that's more to do with how Management Groups, Policies, Subscriptions and EntraID works than anything else.
Eventuallyt everything will probably be Python and then C/Zig for compute heavy parts. Not because Python is great, it's terrible, but it's what everyone uses. We're an energy company and with the internal AI tools we've made widely available we now have non-SWE employees writing code. It's Business Intelligence, it's Risk analysys, it's powerplant engineers, it's accountants. They're all working with AI code in their sandboxed environments and it's all Python. Since some of it actually turns out to generate great value, it's better for us (and the business) if our SWE teams can easily take over when "amateur hour" needs to meet operational compliance for the more "serious" production envrionments. I put things in "'s because I'm still not entirely sure how to express this. A lot of what gets build is great, and would have never been build without AI because we don't have the man power, but it's usually some pretty bad software. Which is fine, until it isn't.