this post was submitted on 13 Feb 2024
1 points (100.0% liked)

.NET

1474 readers
1 users here now

Getting started

Useful resources

IDEs and code editors

Tools

Rules

Related communities

Wikipedia pages

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
1
Our Vision for .NET 9 - .NET Blog (devblogs.microsoft.com)
submitted 9 months ago by [email protected] to c/[email protected]
6 comments fedilink hide all child comments
top 6 comments
sorted by: hot top controversial new old
[–] [email protected] 0 points 9 months ago (3 children)

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

[–] [email protected] 0 points 9 months ago

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?

[–] [email protected] 0 points 9 months ago (1 children)

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.

[–] [email protected] 0 points 9 months ago

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 the birdsite: 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 a bunch of space which is useful since this app is deployed to a bunch of small servers.

[–] [email protected] 0 points 9 months ago (1 children)

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).

[–] [email protected] 0 points 9 months ago

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