Интересная и хорошая статья. У самого витают мысли по созданию блокчейн-фреймворка для .NET Standard. В таких статьях можно заметить некоторые нюансы и трудности, решения к ним.
Rxjs отличается от Promise идеологически и предназначен для другого — для реактивного программирования и работы с потоками данных.
Есть понятие pull-объектов, которые получают данные сами, и push-объектов, которые реагируют когда данные сами к ним приходят.
Вот Pull / Single: Function Push / Single: Promise Pull / Multiple: Iterator Push / Multiple: Observable
RxJs как раз решает вопрос о push-коллекциях. И его сила раскрывается в куда более сложных кейсах.
А объединяются они в цепочки через flatMap:
// first, second возвращают observable
first().flatMap(firstResult=>second())
.flatMap(secondResult=>...)
Все таки хотелось бы иметь расширяемый blockchain-тулкит, с помощью которого можно собирать кастомный блокчейн для любых задач. Ставим nuget-пакет и нет необходимости лезть в исходный код и выкорчевывать криптографию, например. Хотим PoW — пожалуйста. Нужен вместо него PoS — без проблем. Нужен свой алгоритм(тм) — легко, вот интерфейс, реализуйте его) Аналогично с криптографией, валидацией блоков и другими вещами, которые меняются. Добавить интеграцию с КриптоПро тогда не составит труда. Добавим сладости .NET Core 2.0 и будет хорошо.
Возможно, займусь таким проектом в свободное время.
Даже в случае решения этих вопросов для таких серьезных вещей, как выборы в России, необходимо будет использовать ГОСТовскую криптографию. В multichain возможна замена SHA-256, Merkle Tree и эллиптических кривых на другие соответствующие алгоритмы?
Как мне кажется, введение методов по умолчанию в интерфейсах — это бред. Есть же абстрактные классы?
Можно было бы ввести концепты, трейты, методы расширения для всего, как предлагали на github, но вводить реализацию по умолчанию в интерфейсы(которые как бы контракт) — какой-то бред.
Не устраивает только Java и C# программистов, потому что их рынок пытаются занять выскочки из JavaScript области.
И штук 10 еще таких цитат в основном вашего авторства. Вы сами себе противоречите, говоря только о C#.
На хабре от С++, PHP, JAVA разработчиков не слышно говнf в сторону JS.
Вот и весь секрет.
Пруфы? На хабре принято использовать аргументы. А про языки — нет идеального языка. PHP стал источников мемов, JS странный и далек от идеала, С++ монстр во плоти, а а Шарп это лазерная пушка, которая не работает без ослика.
Не нужно быть психологом, что бы понимать почему они это делают.
JS не лезет в драйвера, контроллеры и банковский сектор, но JS лезет в средний бизнес, там где обосновался C# разработчик.
C# можно много где использовать — банки, энтерпрайз, хайлоад, десктоп и т.д. Тут JS-у до него ой как далеко. Упадок C# на десктопе связан не с JS, а с общим умиранием десктопа.
Ах да, есть еще Unity и игры. И что-то как-то там C++ и C# правят балом, а не JS.
Смотрю никакие контр-аргументы не стали писать, надеюсь я вас убедил что никакие WASM не свергнут JS :)
WASM — посмотрим, что за зверь, пока что выглядит незрело.
А JS свергать не надо, отличный язык для задачи придания интерактивности на HTML-страницах) Пусть и остается им))
Я уже выше писал про новые стандарты приложений. Они — лучший путь, чем WASM или HTML+JS
Кстати, в дополнение к новому языку разметки, вполне допустимо оставить например CSS или аналог. Это позволит использовать различные темы в приложениях, системные и кастомные.
Также возможна реализация единой виртуальной машины, встроенной в систему. В байткод этой ВМ будут компилироваться все языки, что также увеличит многообразие. Ну а ОС будут реализовывать стандарт этой ВМ и пытаться сделать более быструю и крутую реализацию)
Эх, розовые мечты…
Имелось в виду байт-код, не привязанный ни к платформе, ни к языку программирования. Что-то похожее на WebAssembly или LLVM IL.
Уже есть. HTML называется. На мой взгляд, ужасен.
HTML — предназначен для текстовых документов. Я же предлагал XAML. Можно взять любой другой, tex и т.д. Сделать поддержку компонентов в первую очередь.
Чем эти «документы» тогда будут отличаться от приложений? А уж интерфейс для запуска приложений в ОС и так хорош.
А чем сейчас документы отличаются от приложений? Я имел в виду единый интерфейс, чтобы юзер захотел — открыл сайт, документ, захотел — запустил приложение и было удобно. Это будет скорее tabbed shell, чем браузер, где каждая вкладка может быть окном, а каждое окно — набором вкладок.
Копию на вкладку сделали не просто так, а ради стабильности и безопасности.
Я критикую подход электрона, который запускает Chromium на каждое окно. При этом можно было бы вынести все таки эту общую часть и не грузить ее каждый раз по новой.
А если соединить все лучшее из мира десктопа и Web?
Например, реализовать единый стандарт байт-кода. Основать его на байткоде CLR, JVM, V8. WebAssembly же смогли сделать, смогли договориться, так и тут)
И реализовать его поддержку на уровне ОС. В этот байткод будет компилироваться JS, .NET, Java-приложения и т.д.
Для поддержки приложений реализовать единый стандартный язык разметки, можно например на основе XAML. Обеспечить поддержку модных нынче компонентов. Можно встраивать в систему готовые компоненты.
На уровне ОС обеспечиваем удобный интерфейс, похожий на браузер, для просмотра HTML-документов(которые останутся документами, максимум интерактивными страничками).
Также в этом интерфейсе можно будет зайти на сайт, а он предложит установить приложение, либо автоустановка в безопасном месте, только с пользовательскими правами. Можно сделать на основе идей мобильных приложений)
В разных вкладках этого браузера 2.0 можно будет запускать как просмотр документов, так и приложения.
При этом исполняющая среда не будет по одной копии на вкладку, а общая на систему.
Таким образом, получаем настоящие кроссплатформенные приложения, удобство для разработки, красивые интерфейсы, при этом решаем проблему Electron(где отдельный Chromium на каждое приложение), и можно делать на любом языке программирования.
А ОС будут уже соревноваться между собой кто как лучше реализует эти стандарты и быстрее исполняет этот байткод.
И можно будет вводить стандарты на API к различным элементам системы, при этом делать их безопасными. Все равно все корпорации так или иначе стараются выполнять веб-стандарты)
Это будет ОС 2.0 и Браузер 2.0.
Эх, мечты…
Есть понятие pull-объектов, которые получают данные сами, и push-объектов, которые реагируют когда данные сами к ним приходят.
Вот
Pull / Single: Function
Push / Single: Promise
Pull / Multiple: Iterator
Push / Multiple: Observable
RxJs как раз решает вопрос о push-коллекциях. И его сила раскрывается в куда более сложных кейсах.
А объединяются они в цепочки через flatMap:
Возможно, займусь таким проектом в свободное время.
Можно было бы ввести концепты, трейты, методы расширения для всего, как предлагали на github, но вводить реализацию по умолчанию в интерфейсы(которые как бы контракт) — какой-то бред.
И штук 10 еще таких цитат в основном вашего авторства. Вы сами себе противоречите, говоря только о C#.
Пруфы? На хабре принято использовать аргументы. А про языки — нет идеального языка. PHP стал источников мемов, JS странный и далек от идеала, С++ монстр во плоти, а а Шарп это лазерная пушка, которая не работает без ослика.
C# можно много где использовать — банки, энтерпрайз, хайлоад, десктоп и т.д. Тут JS-у до него ой как далеко. Упадок C# на десктопе связан не с JS, а с общим умиранием десктопа.
Ах да, есть еще Unity и игры. И что-то как-то там C++ и C# правят балом, а не JS.
WASM — посмотрим, что за зверь, пока что выглядит незрело.
А JS свергать не надо, отличный язык для задачи придания интерактивности на HTML-страницах) Пусть и остается им))
Я уже выше писал про новые стандарты приложений. Они — лучший путь, чем WASM или HTML+JS
Также возможна реализация единой виртуальной машины, встроенной в систему. В байткод этой ВМ будут компилироваться все языки, что также увеличит многообразие. Ну а ОС будут реализовывать стандарт этой ВМ и пытаться сделать более быструю и крутую реализацию)
Эх, розовые мечты…
Имелось в виду байт-код, не привязанный ни к платформе, ни к языку программирования. Что-то похожее на WebAssembly или LLVM IL.
HTML — предназначен для текстовых документов. Я же предлагал XAML. Можно взять любой другой, tex и т.д. Сделать поддержку компонентов в первую очередь.
А чем сейчас документы отличаются от приложений? Я имел в виду единый интерфейс, чтобы юзер захотел — открыл сайт, документ, захотел — запустил приложение и было удобно. Это будет скорее tabbed shell, чем браузер, где каждая вкладка может быть окном, а каждое окно — набором вкладок.
Я критикую подход электрона, который запускает Chromium на каждое окно. При этом можно было бы вынести все таки эту общую часть и не грузить ее каждый раз по новой.
Например, реализовать единый стандарт байт-кода. Основать его на байткоде CLR, JVM, V8. WebAssembly же смогли сделать, смогли договориться, так и тут)
И реализовать его поддержку на уровне ОС. В этот байткод будет компилироваться JS, .NET, Java-приложения и т.д.
Для поддержки приложений реализовать единый стандартный язык разметки, можно например на основе XAML. Обеспечить поддержку модных нынче компонентов. Можно встраивать в систему готовые компоненты.
На уровне ОС обеспечиваем удобный интерфейс, похожий на браузер, для просмотра HTML-документов(которые останутся документами, максимум интерактивными страничками).
Также в этом интерфейсе можно будет зайти на сайт, а он предложит установить приложение, либо автоустановка в безопасном месте, только с пользовательскими правами. Можно сделать на основе идей мобильных приложений)
В разных вкладках этого браузера 2.0 можно будет запускать как просмотр документов, так и приложения.
При этом исполняющая среда не будет по одной копии на вкладку, а общая на систему.
Таким образом, получаем настоящие кроссплатформенные приложения, удобство для разработки, красивые интерфейсы, при этом решаем проблему Electron(где отдельный Chromium на каждое приложение), и можно делать на любом языке программирования.
А ОС будут уже соревноваться между собой кто как лучше реализует эти стандарты и быстрее исполняет этот байткод.
И можно будет вводить стандарты на API к различным элементам системы, при этом делать их безопасными. Все равно все корпорации так или иначе стараются выполнять веб-стандарты)
Это будет ОС 2.0 и Браузер 2.0.
Эх, мечты…