История изменений

Что значит «развитых»?

Имелось в виду покрытие пространства проблем пространством решений (или хотя бы заявка на), т.е. фундаментальность подхода. Активность в github при этом – вопрос второстепенный.

В этом плане твой PSO – развитый, но он несколько из иной области и, извини, но…, безнадежный. Потому, что это CPython и его runtime.

Чего я ожидал от NoSQL? Предположим, на дворе у нас 2010-12 годы (к вопросу о том, что у нас есть в наличии). Вот, есть у нас, скажем, Cassandra. Всё хорошо, но мы хотим хранить в ней видеоролики. Ну, вот, хотим. Так надо. При этом надо, чтобы читать такой объект можно было с любого места (перемотка). Нужна т.н. «нереляционная схема» для файл-подобного объекта над K/V хранилищем. Cassandra не умеет в сканирование, поэтому просто считать линейно возрастающий набор ключей нельзя. Нужно городить дополнительно индексную структуру, которая сгенерирует требуемый набор точечных запросов. Такая индексная структура должна уже обновляться транзакционно если мы хотим, например, дописывать в конец такого файла.

Вот появления подобных библиотек «нереляционных схем» для различных прикладных случаев я и ожидал по аналогии с тем, как мы можем использовать Hibernate для RDBMS. Но индустрия пошла по пути polyglot persistence, создавая для каждого прикладного случая своё оптимизированное хранилище. Мотив понятен и рационален. Вот только подход такой не масштабируем в инженерном плане (каково это, тащить в проекте с дюжину разных хранилищ от разных вендоров, которые не дружат друг с другом от слова «совсем»?). Я извиняюсь, но saga pattern (привет, микросервисы с состоянием, как дела?) – это убожество.

Касательно PSO и CPython. Я долго искал возможность встроить Меморию в <ваш_любимый_язык_программирования> и зарекся это делать впредь. Причина в том, что сами рантаймы этих языков не предназначены ни для ФСД, ни для STM. И если с интеграцией с типами языка еще всё более-менее, то, вот, с поддержкой файберов уже всё плохо.

Я в конце-концов пришел к идее, что под Меморию нужно делать свой язык программирования(x), изначально построенный над асинхронным рантаймом Мемории, который обеспечит простую безопасную работу с контейнерами из прикладного кода и DSL. Рантайм в Мемории Erlang-подобный. Worker threads, между ними мессаджинг и разделяемые ФСД. Конкурентность – через файберы.

(x) Речь здесь идет не о полноценном ЯП (типа, вот, С++ плохой, поэтому мы делаем Rust), а о безопасном (xx) семантическом (xxx) подмножестве С++, сделанном поверх интерпретируемого байт-кода, AOT-транслируемого в С++ и в машинный код. Секретный соус в том, что кодовую модель (байт-код, AST, метаданные, сборки и прочее) можно делать средствами самой Мемории. Она спокойно это всё потянет.

(xx) ARC для всего, немного локальной стековой аллокации, без разделяемых данных между тредами (кроме ФСД), без pointer arithmetic, без UB (контроль переполнения чисел) и т.д.

(xxx) синтаксически оно всё может сильно отличаться от С++, иметь кучу сахара, поддержку разных DSL, метапрограммирования уровня AST и т.д.

Короче, вот этот вот язык вполне может стать языком для «микросервисов с состоянием».

Что значит «развитых»?

Имелось в виду покрытие пространства проблем пространством решений (или хотя бы заявка на), т.е. фундаментальность подхода. Активность в github при этом – вопрос второстепенный.

В этом плане твой PSO – развитый, но он несколько из иной области и, извини, но…, безнадежный. Потому, что это CPython и его runtime.

Чего я ожидал от NoSQL? Предположим, на дворе у нас 2010-12 годы (к вопросу о том, что у нас есть в наличии). Вот, есть у нас, скажем, Cassandra. Всё хорошо, но мы хотим хранить в ней видеоролики. Ну, вот, хотим. Так надо. При этом надо, чтобы читать такой объект можно было с любого места (перемотка). Нужна т.н. «нереляционная схема» для файл-подобного объекта над K/V хранилищем. Cassandra не умеет в сканирование, поэтому просто считать линейно возрастающий набор ключей нельзя. Нужно городить дополнительно индексную структуру, которая сгенерирует требуемый набор точечных запросов. Такая индексная структура должна уже обновляться транзакционно если мы хотим, например, дописывать в конец такого файла.

Вот появления подобных библиотек «нереляционных схем» для различных прикладных случаев я и ожидал по аналогии с тем, как мы можем использовать Hibernate для RDBMS. Но индустрия пошла по пути polyglot persistence, создавая для каждого прикладного случая своё оптимизированное хранилище. Мотив понятен и рационален. Вот только подход такой не масштабируем в инженерном плане (каково это, тащить в проекте с дюжину разных хранилищ от разных вендоров, которые не дружат друг с другом от слова «совсем»?). Я извиняюсь, но saga pattern (привет, микросервисы с состоянием, как дела?) – это убожество.

Касательно PSO и CPython. Я долго искал возможность встроить Меморию в <ваш_любимый_язык_программирования> и зарекся это делать впредь. Причина в том, что сами рантаймы этих языков не предназначены ни для ФСД, ни для STM. И если с интеграцией с типами языка еще всё более-менее, то, вот, с поддержкой файберов уже всё плохо.

Я в конце-концов пришел к идее, что под Меморию нужно делать свой язык программирования(*), изначально построенный над асинхронным рантаймом Мемории, который обеспечит простую безопасную работу с контейнерами из прикладного кода и DSL. Рантайм в Мемории Erlang-подобный. Worker threads, между ними мессаджинг и разделяемые ФСД. Конкурентность – через файберы.

() Речь здесь идет не о полноценном ЯП (типа, вот, С++ плохой, поэтому мы делаем Rust), а о безопасном () семантическом () подмножестве С++, сделанном поверх интерпретируемого байт-кода, AOT-транслируемого в С++ и в машинный код. Секретный соус в том, что кодовую модель (байт-код, AST, метаданные, сборки и прочее) можно делать средствами самой Мемории. Она спокойно это всё потянет.

(**) ARC для всего, немного локальной стековой аллокации, без разделяемых данных между тредами (кроме ФСД), без pointer arithmetic, без UB (контроль переполнения чисел) и т.д.

(***) синтаксически оно всё может сильно отличаться от С++, иметь кучу сахара, поддержку разных DSL, метапрограммирования уровня AST и т.д.

Короче, вот этот вот язык вполне может стать языком для «микросервисов с состоянием».