В JSON даже комментарии нельзя вставлять, не говоря уже о схемах и прочем.
Для передачи данных да, он компактнее и, может, более читаем. Но для разметки, конфигов я предпочту XML.
"Неторопливая" — очень относительное понятие. Да, PInvoke медленный по сравнению с прямым вызовом функции, он добавляет от 10 до 30 инструкций (см MSDN). Но надо понимать, что эта разница — порядка наносекунд, и в случае вызова функций сложнее a+b просто теряется. Например, Ignite.NET работает с JVM через PInvoke, и тормозов от этого не испытывает.
Electron:
тащит за собой целый браузер, жрёт немеряно памяти и создаёт новый процесс на каждый чих
C# быстрее JavaScript и лучше во всех отношениях
XAML лучше HTML
Другое дело, что layout & rendering в Electron действительно может быть быстрее для некоторых сценариев, браузерный движок очень круто заоптимизирован под это дело.
.NET Standard не содержит кода, это просто перечень API. Код находится в фреймворках (.NET 4.6 или .NET Core 2.0, например). Фреймворки реализуют ту или иную версию стандарта.
Стоит упомянуть, что из проектов на .NET Core 2.0+ можно референсить сборки и нугеты ЛЮБОЙ версии .NET, и оно будет работать под линух, если либа не использует windows-specific API.
То есть если вы — автор библиотеки, то не обязательно переезжать на кору, достаточно проверить, что нет windows-specific вызовов, или обернуть их в if-else.
Мы так поступили в Apache Ignite.NET. Всё работает под линух и макось, но сохранена поддержка VS 2010.
XAML — это просто представление объектной иерархии. Всё, что можно выразить в XAML, можно выразить и в C# (но не наоборот).
XAML/BAML нужно в рантайме превратить в дерево объектов, это дороже, чем выполнить скомпилированный C# код (про CAML не в курсе, может, он решает проблему).
XAML декларативный, и он удобнее для описания UI, с этим спору нет. Но в профайлере явно видно, на что уходит время при загрузке развесистых контролов.
И это работает в десятки раз быстрее.
Когда работал с WPF, стандартный подход к оптимизации, например, тяжелого DataTemplate в больших списках — перейти от XAML к аналогичному коду на C#.
Развитие идёт как раз в сторону полноценной SQL базы данных. Пробелов по сравнению с большими дядями (Oracle/Postgres/...) пока много, но работа идёт именно в этом направлении.
Существующая опция останется, это важный сценарий использования, отказываться от него никаких причин нет.
Работа над тонким клиентом уже идёт, он будет доступен в версии 2.4 (конец года).
Обе опции будут поддерживаться под .NET Core 2.0. "Серверный режим" заводится пока только под windows (любая версия уже работает), тонкий клиент работает и под Linux (если взять ночной билд, можно уже сейчас это попробовать: https://myget.org/gallery/apache-ignite-net-nightly).
Да, дополнительный оверхед будет. Но есть ситуации, когда тонкий клиент необходим — короткий жизненный цикл приложения, ограничения по ресурсам, и так далее.
Не совсем так; in-process JVM — это детали реализации.
Межпроцессное взаимодействие осуществляется через различные API Ignite — Cache, Messaging, Compute, и так далее. Эти API есть в Java, .NET, C++. Таким образом, приложения в разных процессах, написанные на разных языках, могут взаимодействовать друг с другом.
Интересно, а где можно на это посмотреть?
В JSON даже комментарии нельзя вставлять, не говоря уже о схемах и прочем.
Для передачи данных да, он компактнее и, может, более читаем. Но для разметки, конфигов я предпочту XML.
"Неторопливая" — очень относительное понятие. Да, PInvoke медленный по сравнению с прямым вызовом функции, он добавляет от 10 до 30 инструкций (см MSDN). Но надо понимать, что эта разница — порядка наносекунд, и в случае вызова функций сложнее
a+bпросто теряется. Например, Ignite.NET работает с JVM через PInvoke, и тормозов от этого не испытывает.Electron:
Другое дело, что layout & rendering в Electron действительно может быть быстрее для некоторых сценариев, браузерный движок очень круто заоптимизирован под это дело.
Вот кое-что есть на хабре: https://habrahabr.ru/post/328684/
.NET Standard не содержит кода, это просто перечень API. Код находится в фреймворках (.NET 4.6 или .NET Core 2.0, например). Фреймворки реализуют ту или иную версию стандарта.
Стоит упомянуть, что из проектов на .NET Core 2.0+ можно референсить сборки и нугеты ЛЮБОЙ версии .NET, и оно будет работать под линух, если либа не использует windows-specific API.
То есть если вы — автор библиотеки, то не обязательно переезжать на кору, достаточно проверить, что нет windows-specific вызовов, или обернуть их в if-else.
Мы так поступили в Apache Ignite.NET. Всё работает под линух и макось, но сохранена поддержка VS 2010.
Это мёртвый механизм, зачем его упоминать? От него отказались в пользу
csproj:https://stackoverflow.com/questions/38536978/is-project-json-deprecated
https://docs.microsoft.com/en-us/dotnet/core/tools/project-json-to-csproj
Не очень понял этот комментарий.
XAML декларативный, и он удобнее для описания UI, с этим спору нет. Но в профайлере явно видно, на что уходит время при загрузке развесистых контролов.
Кросс-платформенный аналог WPF: https://github.com/AvaloniaUI/Avalonia
Недавно пробовал, оно вполне себе работает на вин/линух/макос из-под .NET Core.
И это работает в десятки раз быстрее.
Когда работал с WPF, стандартный подход к оптимизации, например, тяжелого
DataTemplateв больших списках — перейти от XAML к аналогичному коду на C#.Тот же вопрос задавали в прошлый раз: https://habrahabr.ru/company/gridgain/blog/327732/
Хотя я согласен, что картинкой не очень хорошо, не индексируется поисковиками, не скопировать.
Или огорчаешься, потому что мало серьёзных проектов с открытым кодом на C#.
Почитать можно на оф. сайте.
GridGain выпускает платный плагин для Ignite, там это есть
Data Center Replication
Да
Security
Management
Развитие идёт как раз в сторону полноценной SQL базы данных. Пробелов по сравнению с большими дядями (Oracle/Postgres/...) пока много, но работа идёт именно в этом направлении.
Существующая опция останется, это важный сценарий использования, отказываться от него никаких причин нет.
Работа над тонким клиентом уже идёт, он будет доступен в версии 2.4 (конец года).
Обе опции будут поддерживаться под .NET Core 2.0. "Серверный режим" заводится пока только под windows (любая версия уже работает), тонкий клиент работает и под Linux (если взять ночной билд, можно уже сейчас это попробовать: https://myget.org/gallery/apache-ignite-net-nightly).
Да, дополнительный оверхед будет. Но есть ситуации, когда тонкий клиент необходим — короткий жизненный цикл приложения, ограничения по ресурсам, и так далее.
Для этого есть Ignite Services API (упомянут в этой статье, кстати):
https://habrahabr.ru/company/gridgain/blog/327380/
https://apacheignite.readme.io/docs/service-grid
Да, это всё те же services, а так же Compute, который помимо map-reduce функционала позволяет выборочно выполнить код на конкретном узле.
https://apacheignite-net.readme.io/docs/compute-grid
Да, без сомнения, но сроков пока нет. Думаю, в следующем году.
Не совсем так; in-process JVM — это детали реализации.
Межпроцессное взаимодействие осуществляется через различные API Ignite — Cache, Messaging, Compute, и так далее. Эти API есть в Java, .NET, C++. Таким образом, приложения в разных процессах, написанные на разных языках, могут взаимодействовать друг с другом.
Да, сейчас идёт разработка открытого клиентского протокола, который позволит писать клиентов на любых языках.
Насколько я знаю, Python в планах, особенно в связи с активностью по ML.
Это не хитрый режим. Выполняя код
Ignition.Start()в .NET/Java/C++ мы запускаем ноду Ignite внутри текущего процесса.В предыдущем посте подробнее: https://habrahabr.ru/company/gridgain/blog/325830/