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

Знаете, мы тоже :)

Вы работаете на этом проекте, вам платят, это ваше детище.

Наверняка, у Команды тарантула тоже бизнес видение проекта. 🤔

Я бы сказал свое видение!?

Пакет появился, но не ставится. Сисстема чистая центось 8 на виртуалке. Че ему не нравится?

Смотрите:
Со стороны приходит кто-то и говорит: сделайте в продукте фичи X и Y, это прямо обязательно, без них продукт нежизнеспособен.
При этом мы знаем, что продукт жизнеспособен, ему 12 лет, из которых 10 он работает на внутреннем проде и уже около 4х он вполне успешно работает на внешнем Enterprise рынке.
У нас есть собственный роадмап, известные нам проблемы и подходы к их решению, продуктовая стратегия и векторы развития.
Есть только один вариант, при котором мы можем реализовать какую-то фичу вне плана по запросу: если за это отдельно заплатят и если эта фича не противоречит стратегии и ничему не помешает.

Поэтому могу подытожить: мы вас услышали.
- Документацию по коннекторам думаю можно улучшить. Просто ранее ни у кого из программистов на Go не возникало проблем с использованием Golang коннекторов. Мы это запланируем и со временем это будет сделано.
- Ваши запросы на SQL понятны, но они противоречат стратегии развития. Tarantool — мультипарадигменная база. В нешардированном варианте можно будет пользоваться всей полнотой SQL, аналогично MySQL или PostgreSQL. Недоработки в этой части сейчас устраняются. В кластерном режиме SQL противоречит архитектуре и может быть использован только как язык запросов для storage узлов, но не как верхнеуровневый язык.

Успешность понятие относительное. Можно померить его рейтингом. В db-rank я вас не нашёл сходу, а clickhouse там видел.
За 12 лет многие технологии завоевали мир. При запросе на hh большинство вакансий с tarantool были от мейла. А могло быть намного больше.
Если sql не будет поддерживать кластеры и шарды, зачем тогда его вообще делать?

М - мультипарадигменность!

Что вы так к SQL то прикипели, ей богу...

> Если sql не будет поддерживать кластеры и шарды, зачем тогда его вообще делать?

На момент, когда SQL прикручивали, SQL рассматривали исключительно в контексте single node, т.к. многие инсталляции на тот момент (да и сейчас) вполне довольствуются нешардированным вариантом (всё таки перфа одного инстанса с головой хватает для большинства даже highload проектов).
SQL рассматривался как альтернативный/дополнительный язык запросов для простых кейсов и для "админов", а не как основной способ взаимодействия.
Если вам не нравится то, какой в Tarantool'е SQL — не пользуйтесь. Не так давно была мысль вообще убрать его совсем. Но решили сохранить для части сценариев, раз уж туда закопали значительное количество ресурсов. Да и он прекрасно закрывает некоторые бизнес-сценарии.

Есть психология клиента. Мало кому есть дело до красоты архитектуры, большинство просто хочет, чтобы было удобно.

Таков путь)
А если серьезно, то каждый добивается успеха своим путем. Нравится это окружающим или нет. И только время покажет, был ли этот путь верным

Один язык для всех баз это удобно

Я вам по секрету скажу: в бытность мою в Облаке мы использовали подход: один язык для всего проекта — это удобно. И этим языком был Lua. В связке OpenResty + Tarantool.

И да: в MRG, насколько мне известно, ни один проект не использует SQL в Tarantool.

Это сверхобобщение. Есть системы, которые работают без SQL. И ими пользуются. А ещё очень популярны ORM, которые как раз пытаются от разработчика скрыть SQL. Таким образом, утверждение что один SQL для всех БД удобно и типа must have - уже не укладывается в картину мира, где orm очень популярны

А драйвер - это витрина, с которой многое начинается и там же и заканчивается. Не будь я на обучающих курсах по тарантулу, увидев впервые такой драйвер сразу бы завернул базу.

может вам и не нужен тарантул? возьмите монгу какую нибудь?

В го орм считаются богомерзким занятием) Но проблема не в sql, а в том зачем что то делать наполовину.