this post was submitted on 13 Feb 2024
17 points (100.0% liked)
.NET
1489 readers
1 users here now
Getting started
Useful resources
IDEs and code editors
- Visual Studio (Windows/Mac)
- Rider (Windows/Mac/Linux)
- Visual Studio Code (Windows/Mac/Linux)
Tools
Rules
- Rule 1: Follow Lemmy rules
- Rule 2: Be excellent to each other, no hostility towards users for any reason
- Rule 3: No spam of tools/companies/advertisements
Related communities
Wikipedia pages
- .NET (open source & cross platform)
- .NET Framework (proprietary & Windows-only)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
They keep saying "Cloud-Native Developers" in a bunch of titles and the text, but I'm pretty sure this is mostly going to be Azure-cloud focused.
Since AWS only supports LTS versions, a lot of things have been stuck on dotnet6 there. (Unless you install your own frameworks or docker or own ec2 images or something) - But no proper native cloud support for a lot of dotnet7 from AWS
For example, Lambdas don't natively support anything besides dotnet6, and dotnet8 is still scheduled to be released (Mentions February 2024, but used to mention January 2024, so who knows when it's actually going to be released)
Since dotnet6 and dotnet8 were LTS, I doubt dotnet9 is going to be as well, and is going to be STS again. So all the Cloud-Native stuff in dotnet9 is pretty much going to be Azure
We've switched to deploying everything as self-contained apps as we got tired of waiting for AWS to update their stuff.
If Lambda cold-start is important for you, publish the app with native AOT.
I saw an amazing demonstration of a GUI app's cold start time with .NET 9 AoT on Twitter: https://x.com/wieslawsoltes/status/1757488043143942528?s=20
I don't use AWS but I updated one of my apps (https://dnstools.ws/) to use AoT and really like it since it avoids having to deploy .NET to the servers. Saves quite a bit of disk space which is useful since this app is deployed to a bunch of small servers.
I suppose you are right. If AWS doesn't support STS versions, these will be only applicable to Azure (I know nothing about GCP). It probably makes sense for AWS to stick to LTS versions (I would do the same). But isn't that a choice made by AWS (rather than Microsoft).
Well it's both, though my comment wasn't to blame Microsoft on this. But LTS is a relative, non-defined term. AWS has a policy to only support LTS versions because they (understandably) don't want to deal with new versions every couple of months. Within Microsoft terminology STS (Standard TS) is 18 months of patching, LTS is 36 months of patching.
So it's just semantics. dotnet-STS is not some goofy hobby language that gets new versions every couple of months. 18 months from a massive team with a massive userbase is pretty long term compared to some other frameworks.
So either AWS could not be so nitpicky about it not being labeled LTS - or Microsoft could just label one version (dotnet7, dotnet9) as LTS, and the 36 months version as Extra-LTS or whatever lol. And all the dotnet versions would fall within the AWS native-support parameters
I don't use AWS but it seems like a big limitation if you can only use frameworks they officially support? What happens if you use a non supported framework?
Pretty sure they are referring to AOT and docker when they say that. That seems to be the direction they are pushing with their cloud stuff.
.net Aspire is their new toy and that is generally targeting kubernetes for deployment.
The article specifically talks about AOT and kubernetes so I think that's a safe bet at what they mean.