Здравствуйте, _NN_, Вы писали:

S>> Все под .Net 8! Там же JIT работает. А в Native AOT так еще и тримятся.

_NN>Ну как сказать всё:

_NN>

No dynamic loading, for example, Assembly.LoadFile.
_NN>

No run-time code generation, for example, System.Reflection.Emit.
_NN>

No C++/CLI.
_NN>

Windows: No built-in COM.
_NN>

Requires trimming, which has limitations.
_NN>

Implies compilation into a single file, which has known incompatibilities.
_NN>

Apps include required runtime libraries (just like self-contained apps, increasing their size as compared to framework-dependent apps).
_NN>

System.Linq.Expressions always use their interpreted form, which is slower than run-time generated compiled code.
_NN>

Not all the runtime libraries are fully annotated to be Native AOT compatible. That is, some warnings in the runtime libraries aren't actionable by end developers.

_NN>Чем больше когда, тем больше шансов, что не будет что-нибудь работать.

_NN>Конечно, со временем будет больше совместимости если тренд нативности разработчики будут активно поддерживать, а не сбегут на Rust

Согласен. Погорячился.
А как ты хочешь без 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.

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

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

Здравствуйте, _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.

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

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