.NET 11 deja de funcionar en hardware antiguo y reescribe el async desde el runtime
What's new in the .NET 11 runtime
La nueva versión del runtime de .NET eleva los requisitos mínimos de hardware: en x86 pasa a x86-64-v2 y en Windows Arm64 exige el conjunto de instrucciones LSE. Además, Runtime Async V2 sustituye las máquinas de estado generadas por el compilador por suspensión y reanudación gestionadas por el runtime, lo que reduce las trazas de pila de 13 a 5 marcos y mejora la depuración. Incluye optimizaciones del JIT como la eliminación de comprobaciones de límites y el plegado de switch.
Con Runtime Async, los métodos reales aparecen directamente en la pila de llamadas.
- CharlieDigital
En mi experiencia, C# y .NET están ambos "poco valorados" en gran parte por el legado.
Hay gente por ahí que todavía piensa que .NET es solo para Windows. Hay gente por ahí que no ha mirado C# desde los tiempos de .NET Framework. Hay gente por ahí que sigue resentida por algunas de las decisiones de Microsoft en torno al OSS (el fiasco del debugger, del hot reload, etc.)
Pero, ¿en el día a día trabajando con C# y .NET para backends? Es realmente fantástico. A la IA parece gustarle mucho y hay un montón de herramientas para que los agentes den rienda suelta. Analizadores de Roslyn, generadores de código fuente, un hot reload que funciona (para un lenguaje compilado), toneladas de documentación realmente buena de Microsoft, en general poca varianza y mucha consistencia de un código base a otro (p. ej., encontrarte con Drizzle vs Prisma vs TypeORM vs Kysely vs... en el mundo de Node).
Mi equipo anterior pasó de TS a C# y F#[0][1] y fue una bendición; mucha de la operación de plataforma se simplificó. Es simplemente una cadena de herramientas muy sólida y los paquetes suelen ser estables (mucho menos esfuerzo en mantener la configuración y las herramientas de la plataforma y más foco en simplemente construir). Los paquetes de primera parte reciben actualizaciones de seguridad consistentes y C# no tiene ni de lejos el mismo nivel de exposición a paquetes transitivos que uno encuentra en el ecosistema JS/TS.
C# se siente como una elección realmente sólida en la era de la programación con IA por su estabilidad general, su fuerte analizador estático, su insistencia en los tipos y sus herramientas realmente buenas. No es lo adecuado para todos los casos de uso (p. ej., CLI, funciones serverless), pero es fantástico para APIs de backend.
Si estás busca[…]
- giancarlostoro
C# fue mi segundo lenguaje de programación después de VB6. Recuerdo que a principios de los 2000, cuando tenía 12 años, usaba el ordenador de mi mejor amigo para intentar descargar VB .NET (él tenía internet más rápido) solo porque era gratis, y luego me decepcioné muchísimo cuando no podía simplemente ejecutar mis proyectos de VB6 que quería correr en él... Unos años después, entre 2007 y 2009, probé C# y eso me cambió la vida.
Terminé yendo a la universidad después de trabajar en retail en Disney, y luego, tras la universidad, mi primer trabajo se suponía que era de C#, pero no tenían el proyecto aprobado, así que tuve mi primer contacto con Python, que me encantó, luego JavaScript, que odié pero con el que tengo una relación de amor-odio hasta hoy, y finalmente C#, pero no era .NET 3.5, no, empezaron a usar .NET Core, que era... otra cosa, mucha extracción de muelas durante los primeros días de .NET Core.
Tantos proyectos maravillosos hechos con .NET; mi única queja es que ojalá Microsoft hiciera un stack de GUI multiplataforma al que de verdad se mantuviera fiel, y que funcionara también en Linux. ;)
Sé que hay alternativas, pero nada supera decirles a tus compañeros de trabajo "usemos simplemente lo que viene incluido" a la hora de elegir un stack de GUI.
- wofo
¡Cosas geniales, como siempre en las versiones de .NET! El soporte de async en el runtime me sorprende... Entiendo que los stack traces son más amigables sin máquinas de estado en el código, pero no esperaba que pudieran cambiar a una versión en el runtime y tener un rendimiento equivalente. ¡Genial!
- 1a527dd5
https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
Ojo con esto
(decimal)0.1
// .NET 10: 0.1
// .NET 11: 0.1000000000000000055511151231
- mgdev
Siento que han hecho mucho para resolver un montón de los confusos problemas de versionado y compatibilidad del runtime que alejaron a los desarrolladores que no son de Windows de usar .NET.
Sin embargo, siguen sufriendo un problema de marca increíble.
Es una verdadera lástima porque como runtime es bastante increíble, y F# en particular es divertido de usar. También tienen buen soporte multiplataforma y buenas herramientas, que no tenían hace unos años.
Combina eso con el hecho de que de todos modos ya casi nadie escribe código gracias a la IA, y esto podría ser un runtime imbatible para un entorno de desarrollo nativo de IA.
Pero nunca pasará.
- GaProgMan
> .NET 11 es una versión de Standard Term Support (STS) con dos años de soporte bajo la política de soporte de .NET. Las versiones STS y Long Term Support (LTS) tienen las mismas políticas de calidad y mantenimiento; la diferencia es la duración del soporte. .NET 10 sigue siendo una opción LTS con soporte. Mantente al día con las actualizaciones de mantenimiento, elijas la versión que elijas.
Enterraron la noticia importante en esta.
- El fin de vida de .NET 10 es el 14 de noviembre de 2028
- El fin de vida de .NET 11 es el 9 de noviembre de 2028
Lo que significa que cualquiera que actualice a 11 tiene menos días de soporte. Pero la idea es que actualizarás a 12 en cuanto tenga su RTM.
El problema con eso es que tengo clientes que se niegan a moverse de 2.1 (o incluso a actualizar al relanzamiento de 2.1: 2.3).
- jotato
¿Qué IDE usa la gente para C# hoy en día? En su momento (allá por 2008) Visual Studio era tu única opción real.
Pero ahora estoy en Linux. Si quisiera retomarlo, ¿qué debería usar?
- SurajMishra
Para las características que se solapan entre golang y .Net, ¿alguien podría decirme por qué la gente elige .Net en lugar de golang para sistemas que no son legacy? Hasta donde llega mi conocimiento limitado, go es mucho más eficiente en sintaxis y memoria.