Net Core ha sido de código abierto durante varios años. ¿Por qué muchas personas no estudian y ajustan su algoritmo GC como JVM?

Hemos lanzado varios proyectos .net core, básicamente docker+.net core 2/3. Para ser honesto,

el GC de .net core es muy bueno y básicamente no requiere mucha optimización como cuando se hace Java. Por eso es normal que no haya mucha gente investigando. En otras palabras, si un GC necesita mucha optimización, definitivamente no es un buen GC. Por supuesto, al programar, aún necesita dominar el procesamiento de objetos no administrados de uso común, etc.

Esto tiene mucho que ver con el entorno de desarrollo interno.

Por un lado, existe un problema de dependencia de la trayectoria, que es particularmente prominente en China. En los últimos años ha habido más desarrolladores de otros idiomas en China y la ecología ha sido mejor, pero la conversión supone un coste.

Por otro lado, la impetuosidad se ha vuelto demasiado fuerte y el utilismo prevalece. A continuación se muestran dos ejemplos para ilustrar. Uno es el problema central del sistema operativo doméstico. ¿Por qué utilizar el kernel de Linux en lugar de reescribirlo? La razón dada es simplemente que el ecosistema Linux es bueno y estable, y no hay necesidad de duplicarlo. ¿Es realmente innecesario? Entonces, ¿por qué es popular en el extranjero reescribir varios programas en Rust y hacerlos de código abierto? "No es necesario" es falso, "no quiero" es cierto. Después de todo, el ciclo de construcción de infraestructura es largo y el costo es alto, por lo que es mejor no utilizarlo como doctrina. Otro ejemplo es la reciente suspensión de la autorización de MATLAB en China. En este asunto, mucha gente piensa que no es un gran problema. La razón por la que no es un gran problema es que también existe un scilab de código abierto que se puede utilizar.

Puede que no sea apropiado citar estos dos ejemplos, pero un vistazo al leopardo en la tubería es suficiente para ilustrar el impetuoso ambiente actual.

Dado que aquí estamos hablando de los problemas subyacentes de net core, puede que valga la pena leer la nueva "Introducción subyacente a .NET Core" de este año. Esto está escrito por un investigador nacional y es posible que sea posible ver avances nacionales a este respecto. Con todo, aunque net core ha sido de código abierto durante varios años, el crecimiento de los desarrolladores y la construcción del ecosistema en China llevará más tiempo.

Porque no es necesario, Java es como un producto semiacabado, ya sea gramática, compilador, etc. Si no existieran las series de primavera, se estima que esos 996 se habrían convertido en 007 hace mucho tiempo. .

Las capacidades de producción de Microsoft son obvias para todos. .net es más completo que el sistema JAVA, incluido el producto en sí y el mantenimiento posterior, por lo que es mejor utilizar la plataforma .net.

Esto parece bastante normal, al igual que después de comprar GitHub, muchos proyectos de código abierto migraron a GH. La comunidad de código abierto generalmente desconfía de Microsoft y su intención no está en el código abierto en sí. Se estima que el código abierto .Net tiene una cuota de mercado cada vez menor y nadie realmente quiere utilizarlo.

.net core, ¿dónde está la necesidad de optimización de GC? Ese es un problema causado por los defectos inherentes de jvm. .net 5 va un paso más allá en términos de rendimiento. Siempre que su programa no esté mal escrito, no tiene que preocuparse por el rendimiento del tiempo de ejecución subyacente.

No se puede mirar .net desde la perspectiva de JVM. El mundo Java ha entrado en un estado de complacencia. Las versiones se actualizan muy rápidamente y no hay avances en cosas importantes. Muchas empresas insisten en Java 1.6 y no lo sueltan, lo cual es realmente testarudo.

La optimización es definitivamente necesaria. No importa qué tan bueno sea el programa, hay espacio para la optimización. Es solo que actualmente faltan aplicaciones a gran escala en la plataforma dotnet. En escenarios comerciales normales, es difícil alcanzar el cuello de botella de rendimiento del marco.

Aunque dotnet es de código abierto, ya es demasiado tarde. Si hubiera sido hace unos años, antes del auge de Android y antes del auge del big data, ¿seguiría esta situación siendo así ahora? Al ver que las grandes empresas nacionales están recurriendo a Java y otros lenguajes una tras otra, como programador de dotnet, no me siento muy dispuesto.

dotnet tiene muchas ventajas sobre Java a nivel de lenguaje. Algunas de las nuevas características del lenguaje agregadas en la nueva versión de Java también se copian de dotnet. Pero aun así, fue bien recibido pero no popular.

Ya era demasiado tarde para abrir el código fuente y se perdieron varias oleadas de dividendos en el desarrollo de la industria.

Hasta ahora, Hadoop falta en el campo de big data y Elasticsearch falta en el campo de búsqueda. Aunque Xamarin está disponible en el terminal móvil, todavía es inútil. Si existen estas aplicaciones asesinas, el ecosistema dotnet definitivamente prosperará y se optimizará en una dirección más sólida.

¿Qué más se puede decir? Solo puedo esperar que el próximo dotnet 5 pueda unificar la caótica situación actual, aprovechar al máximo sus propias fortalezas y hacer prosperar el entorno ecológico de dotnet.

En primer lugar, el GC original de .net siempre ha sido bueno. Lo suficientemente fluido como para soportar el desarrollo de juegos 3D. Por lo tanto, hay poca necesidad de realizar ajustes. Debes saber que tener demasiados artículos que no se utilizan no es necesariamente algo bueno. El 95% de los artículos técnicos en realidad son solo para resolver un ERROR. En segundo lugar, la sintaxis y el diseño del tiempo de ejecución de C# son buenos y ejercen mucha menos presión sobre el GC. Por ejemplo, los genéricos admiten tipos básicos, de modo que estructuras como Lista se asignan y publican como un todo. Y cierta rana necesita desempaquetar y empaquetar cada elemento. Muerte lenta, también requiere más cadenas de referencia para el GC. Además, C# también admite tipos de datos SIMD como matrx4x4. También es bueno mejorar la velocidad de ejecución y reducir el GC.

Estas cosas se han optimizado muy bien y los programadores no necesitan prestarles atención, lo que permite a los programadores centrarse más en la implementación empresarial.

En comparación con Java, el lenguaje de .netcore es más elegante, avanzado y completo, por lo que no es necesario prestar atención a cosas de nivel relativamente bajo.

Es simple: ningún negocio crítico se ejecuta en net core.

En el pasado, jd business usaba .net, pero después de unos años, todo fue reemplazado por Java. Esto es suficiente para explicar el problema.

Las pequeñas fábricas como Zhihu comenzaron a usar Python y, cuando el volumen de negocios aumentó, cambiaron a Golang en lugar de Net Core. Esto es suficiente para ilustrar el problema.

Algunas personas dicen que por muy bueno que sea el netcore, no es necesario optimizarlo uno mismo... De hecho, no se ha alcanzado el límite en absoluto y no es el momento de optimizar.