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

S> Что же так популярность дарта то не растет?
S>https://habr.com/ru/company/skillfactory/blog/504194/

Опять опрос stack overflow? ))
Т.е. опрос тех, у кого возникают вопросы?

И тебя не смущает, что на первом месте Rust, который в рейтинге TIOBE на 30-м месте?
А дарт в этом же рейтинге на 22-м?
А топ выглядит так:
Питон
Си
Джава


S>И смотрим как растет популярность TS.

Смотрю как много Rust и TS вызывает вопросов на SO. ))


S> Ну Xamarin может использовать и блазор в натив, и сейчас MAUI кроссплатформенный развивается, ну и родные андроидные axml

Это да, XAML позиции не сдаёт, а даже набирает.
Но XAML-подобные GUI идеальнее всего подходят для статического GUI, а Flutter изначально проектировался с упором на динамику.

В этом смысле CSS/HTML/JS занимает промежуточное положение — в основе статическое описание плюс наработки на JS по манипуляции GUI.
Но описание на Dart всё-равно прикольней:
https://github.com/flutter/gallery/blob/21d025db17cab0cc325f77f89ff52057128f39e3/lib/pages/demo.dart#L331

Простое ветвление прямо в коде намного органичней смотрится, чем ветвление в JS, где или согласно условиям рендерят текст HTML, или ручками напихивают DOM, или переключают стили/классы видимые/невидимый.

Все три способа — убожество.
При кажущейся лаконочности последнего, у него расползаются зависимости м/у HTML-страницей, логикой в JS-коде и CSS-стилями, что приводит к той самой забористой каше современного фронтенда, где в одном месте чуть дунул — и всё поломалось.


V>>Это у тебя много голословного.
V>>Имеешь привычку рассуждать о том, чем лично не занимался и даже не пробовал.
S> Я то как раз говорю о том, в чем разбирался

С Unity ты не разбирался, посему твоё упорство выглядело странным.
Особенно когда ты не мог поверить, что в нейтивном релизе есть GC, но нет "среды".


V>>И среда там есть аж бегом, без ней .Net Native не живёт.
S> Ну вот нет там среды!

Есть.
https://docs.microsoft.com/en-us/windows/uwp/dotnet-native/

Mrt.dll — Minimal CLR Runtime.
Точный GC без метаинформации не работает.
Вся эта связка и называется CLR.


S>Кроме сборщика мусора. Если бы среда была, то не было бы проблем с докомпиляцией и рефлексией.

Для этого надо было бы оставить символьные строки, соотв. названиям неймспейсов, классов и их мемберов.

А тебя послушаешь, так даже в случае обычного дотнета, после того как JIT перевёл в нейтив весь наличествующий байткод, сразу "среда" перестаёт быть "средой".
Ведь происходящее далее не сильно будет отличаться от происходящего в .Net Native.


S>Подтверди свои утверждения ссылками. Опять голословный треп.

А в сад тебе не прогуляться, к остальным двоечникам? ))

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

S> Что же так популярность дарта то не растет?
S>https://habr.com/ru/company/skillfactory/blog/504194/

Опять опрос stack overflow? ))
Т.е. опрос тех, у кого возникают вопросы?

И тебя не смущает, что на первом месте Rust, который в рейтинге TIOBE на 30-м месте?
А дарт в этом же рейтинге на 22-м?
А топ выглядит так:
Питон
Си
Джава


S>И смотрим как растет популярность TS.

Смотрю как много Rust и TS вызывает вопросов на SO. ))


S> Ну Xamarin может использовать и блазор в натив, и сейчас MAUI кроссплатформенный развивается, ну и родные андроидные axml

Это да, XAML позиции не сдаёт, а даже набирает.
Но XAML-подобные GUI идеальнее всего подходят для статического GUI, а Flutter изначально проектировался с упором на динамику.

В этом смысле CSS/HTML/JS занимает промежуточное положение — в основе статическое описание плюс наработки на JS по манипуляции GUI.
Но описание на Dart всё-равно прикольней:
https://github.com/flutter/gallery/blob/21d025db17cab0cc325f77f89ff52057128f39e3/lib/pages/demo.dart#L331

Простое ветвление прямо в коде намного органичней смотрится, чем ветвление в JS, где или согласно условиям рендерят текст HTML, или ручками напихивают DOM, или переключают стили/классы видимые/невидимый.

Все три способа — убожество.
При кажущейся лаконочности последнего, у него расползаются зависимости м/у HTML-страницей, логикой в JS-коде и CSS-стилями, что приводит к той самой забористой каше современного фронтенда, где в одном месте чуть дунул — и всё поломалось.


V>>Это у тебя много голословного.
V>>Имеешь привычку рассуждать о том, чем лично не занимался и даже не пробовал.
S> Я то как раз говорю о том, в чем разбирался

С Unity ты не разбирался, посему твоё упорство выглядело странным.
Особенно когда ты не мог поверить, что в нейтивном релизе есть GC, но нет "среды".


V>>И среда там есть аж бегом, без ней .Net Native не живёт.
S> Ну вот нет там среды!

Ошибаешься:
https://github.com/dotnet/corert/blob/master/Documentation/intro-to-corert.md

Native (AOT) compilation is a great scenario addition to .NET Core apps on Windows, OS X and Linux. We've seen significant startup and throughput benefits of native compilation for Windows UWP apps, using .NET Native.
...
CoreRT is a refactored and layered .Net Core runtime. The base is a small native execution engine that provides services such as garbage collection(GC). This is the same GC used in CoreCLR.
...
CoreRT offers great benefits that are critical for many apps.
...
The native compiler generates a SINGLE FILE, including the app, managed dependencies and CoreRT.

https://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AOT/

Firstly, what exactly is CoreRT? From its GitHub repo:
— a .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying .NET native compiler toolchain
...
So whilst CoreRT is a run-time, it also needs a compiler to put everything together, from Intro to .NET Native and CoreRT:

.NET Native is a native toolchain that compiles CIL byte code to machine code (e.g. X64 instructions). By default, .NET Native (for .NET Core, as opposed to UWP) uses RyuJIT as an ahead-of-time (AOT) compiler, the same one that CoreCLR uses as a just-in-time (JIT) compiler.
...
The Runtime
All the user/helper code then sits on-top of the CoreRT runtime, from Intro to .NET Native and CoreRT:
CoreRT is the .NET Core runtime that is optimized for AOT scenarios, which .NET Native targets.

Точный GC не может работать без метаинформации, поэтому, там и метаинформации овердофига.
Можно сравнивать у разных объектов результат вызова GetType(), работает is и as, работает проверка на отношение base/derived и т.д. и т.п.


S>Кроме сборщика мусора. Если бы среда была, то не было бы проблем с докомпиляцией и рефлексией.

Для этого надо было бы оставить символьные строки, соотв. названиям неймспейсов, классов и их мемберов.
А насчёт докомпиляции — по ссылке для особо понятливых несколько раз повторяется, что это AOT-технология, но при этом используется тот же самый RuiJIT.

Native compiled apps startup faster since they execute already compiled code. They don't need to generate machine code at runtime nor load a JIT compiler.

А тебя послушаешь, так даже в случае обычного дотнета, после того как JIT перевёл в нейтив весь наличествующий байткод, сразу "среда" перестаёт быть "средой".
Ведь происходящее далее не сильно будет отличаться от происходящего в .Net Native UWP.


S>Подтверди свои утверждения ссылками. Опять голословный треп.

А в сад тебе не прогуляться, к остальным двоечникам? ))