Информация об изменениях

Сообщение Re[5]: Rust или Golang - за кем будущее? от 05.02.2024 14:32

Изменено 05.02.2024 15:40 Serginio1

Re[5]: Rust или Golang - за кем будущее?
Здравствуйте, _NN_, Вы писали:

Согласен. Погорячился.
А как ты хочешь без CLR? Можно подумать ты в Go и Rust что то там в рантайме компилишь?
C++/CLI, а он в Core то есть?

Ну до Com доберутся. Интерфейсы то нативные поддерживаются. Подсчет ссылок нужно организовать. Но это не критично.
Проблемы конечно есть, но многое переписывается.
С усечением например проблемы для .Net 8 из .Net 7 поубирали.
А так по твоей же статье, многое переписывается под оптимальное использование Native AOT.
_NN>Вон в Microsoft Office
Автор: flаt
Дата: 30.01 22:55
посчитали, что проще переписать с .NET чем решать проблемы медленного запуска утилит.

А офис разве не на JavaScrip написан?

'No, we are not rewriting Office in JavaScript' and other Microsoft tales

Ну а что касается замены .Net на Rust лучше бы сосредоточились на Native AOT.
Наверное проще довести до ума Native AOT чем переписывать все на Rust.
Было бы интересно сравнить производительность Rust и AOT
Кстати в свое время Блазор работал как интерпретатор. То есть многие проблемы можно решать через интерпретацию кода.

Хотя выражения могут использоваться в собственных приложениях AOT, когда вы Lambda.Compile() создаете выражение, оно использует интерпретатор для вычисления выражения. Это не идеально и может привести к снижению производительности. Если возможно, рекомендуется удалить Expression.Compile() использование в собственных приложениях AOT.

Re[5]: Rust или Golang - за кем будущее?
Здравствуйте, _NN_, Вы писали:

Согласен. Погорячился.
А как ты хочешь без CLR? Можно подумать ты в Go и Rust что то там в рантайме компилишь?
C++/CLI, а он в Core то есть?

Ну до Com доберутся. Интерфейсы то нативные поддерживаются. Подсчет ссылок нужно организовать. Но это не критично.
Проблемы конечно есть, но многое переписывается.
С усечением например проблемы для .Net 8 из .Net 7 поубирали.
А так по твоей же статье, многое переписывается под оптимальное использование Native AOT.
_NN>Вон в Microsoft Office
Автор: flаt
Дата: 30.01 22:55
посчитали, что проще переписать с .NET чем решать проблемы медленного запуска утилит.

А офис разве не на JavaScrip написан?

'No, we are not rewriting Office in JavaScript' and other Microsoft tales

Ну а что касается замены .Net на Rust лучше бы сосредоточились на Native AOT.
Наверное проще довести до ума Native AOT чем переписывать все на Rust.
Было бы интересно сравнить производительность Rust и AOT
Кстати в свое время Блазор работал как интерпретатор. То есть многие проблемы можно решать через интерпретацию кода.

Хотя выражения могут использоваться в собственных приложениях AOT, когда вы Lambda.Compile() создаете выражение, оно использует интерпретатор для вычисления выражения. Это не идеально и может привести к снижению производительности. Если возможно, рекомендуется удалить Expression.Compile() использование в собственных приложениях AOT.


Но уже сейчас многое поддерживает
.NET 8 Support for Native AOT

Поддерживаются:

Middleware
Minimal APIs
gRPC
Kestrel HTTP Server
Authorization
JWT Authentication
CORS
HealthChecks
OutputCaching
RequestDecompression
ResponseCaching
ResponseCompression
StaticFiles
WebSockets
ADO.NET
PostgreSQL
Dapper AOT
SQLite



Они еще не поддерживаются:

ASP.NET Core MVC
WebAPI
SignalR
Blazor Server,
Razor Pages,
Session, Spa
Entity Framework Core