Были ли у компанды мыcли по замене Lua на JavaScript?

Очень интересный вопрос! А на ваш взгляд, какую проблему можно решить такой заменой?

Если Tarantool - middleware for data, и есть возможность поднятия web сервера близкого к данным - Lua кажется не очень очевидным выбором..

получить compile time проверку типов (typescript) и более живую экосистему, чем Lua конечно, этого никогда не произойдет (просто потому что нужно выкинуть для этого половину кодовой базы и еще процентов 25% переписать), но желание вполне логичное

Я думаю, для понимания этого выбора можно оглянуться в прошлое, когда Tarantool еще не позиционировался даже как Application Server + DBMS (не говоря уж о middleware).

Для Lua, кстати, тоже есть схожие приседания, просто есть одна проблема: JS и его экосистема поддерживаются многими компаниями (не только Google), а Lua -- группой "исследователей" из университета в Бразилии. Ну и может еще парочкой человек вне университета.

Другая сторона медали, кстати, популярность самого тарантула. Не смотря на то какой пласт задач решает - 3,5к звезд на гитхабе. Был бы js - иную картину бы уведели

что собственно объясняет, но никак не облегчает историю с бедностью экосистемы Кстати, еще одна большая проблема - невозможность подцепить случайную библиотеку из LuaRocks из-за необходимости использовать везде COIO

Мне, к сожалению, не довелось особо поиграться с JS (ни написанием кода на нем, ни встраивания его в другие системы), но, учитывая архитектуру Tarantool, и как туда вонзили Lua, у меня все еще есть большие сомнения про "другую картину" в смысле переиспользования экосистемы.

Бедность экосистемы, опять же, скорее из-за фрагментации Lua сообщества, нежели от малого количества участников.

да, просто встраивание интерпретатора JS никак не решило бы проблему с несовместимыми рантаймами

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

Именно так. Было бы всё то же самое: js с файберами. А async/await нормально не едет. Мы смотрели сейчас на wasm для использования assemblyscript, но к сожалению туда пока не довезли переключения контекста, так что ждём…

Что имеется в виду под async / await не едет? В плане, не очень понятно как подружить с рантаймом?

Ну вот. Другими словами, при встраивании JS мы бы получили другой странненький ЯП, экосистема которого не ложилась бы нативно на runtime платформы, а людям казалось бы *еще* более странным использование каких-то подхаченных библиотек, вместо аналогов широко используемых в вебе/ноде.

(с последним, кстати, именно фрагментация и бедность Lua экосистемы даже на руку)

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

Безусловно. Конечно, помойки типо CPAN и PyPI убивают количеством альтернатив для решения какой-нибудь стандартной задачи, но несомненно, что лучше когда выбор есть, чем когда его нет. А теперь к конкретике: чего именно не хватает в экосистеме?

Лично мне сильно нехватает активности комьюнити и популярности т.к. даже клиенты для других яп забрасываются. Сам инструмент использую долгие годы и получаю удовольствие. Поэтому и задался вопросом, что мешает? Для себя понял, что если был бы js, то во многих случаях я не выносил бы логику наружу

это глубоко тарантульный подход когда среднему разработчику (например, на node.js) нужно что-то сделать - первое, что происходит - проверяется github и npm на наличие библиотеки, которая уже это реализовала

Что-то я не увидел конкретики, если честно... Коннекторы уж точно не про Lua, вынесение логики наружу -- личный выбор каждого: мне на выходных надо было накидать небольшой сервис, так я наоборот как можно больше логики запихнул в Lua. Про общую мотивацию, опять же, можно обратиться к истории: если бы в броузеры воткнули Lua, а не JS, то мы бы жили в другом мире, и какой он был бы -- уже никто не узнает.

Угу. И я убежден, что именно эту проблему стоит решать в первую очередь (хотя очень долгое время вектор был строго противоположным).

Я тут не про личный выбор каждого, а размышляю с бизнесовой стороны. Если у меня есть команда rust девов, или даже люди с фронта, добавим сюда еще экосистему js - и получаем быстрый способ создания/поддержки приложений близких к данным. На Lua поднимать приложение не стал, как минимум потому, что каждому новому программисту в команде туда нужно вникать и поддерживать еще. Опять же, я тут не говорю, что текущие решения плохие (иначе бы годами не пользовался). Высказал мнение со стороны.

У меня есть ощущение, что люди, пользующие JS на FE, немного отличаются по навыкам и экосистеме от людей, пользующих JS для BE. Но повторюсь, мои знания по JS настолько малы, что я не готов аргументировать свои ощущения :)

Re мнение со стороны: а я поэтому и подкинулся в диалог, потому что интересно узнать про проблемы/переживания/etc. С задачами найма для Lua, кстати, я вообще не спорю: видел разное (и не только в Tarantool).

Не согласен, у меня в команде фронтовики близко работающие с веб серверами и бэком. Я бы сказал, что сейчас JS стал реально универсальным, а со всякими Deno превращается в хороший embedded без V8

https://t.me/tarantoolru/127390 https://github.com/tarantool/tarantool/issues/7208

недоавно под фронт писал на ts для браузерного IndexedDB который ниразу не типизирован очевидно . так вот магия d.ts делает чудеса , формат данных и индексы будучи описаны в одном месте и в редакторе и в момнет сборки не дадут допустить глупых ошибок т.к. там очень серьезный type inference

Основная моя печаль, что результат работы transpiler-а никак не будет использован в компиляторе: это помогло бы более эффективно компилировать трассы. В эту тему, мне на прошлой неделе попалась интересная статья про профилирование кода, реализованное в TraceMonkey (JIT от мурзилки): они как раз собирают знания о типах в процессе профилирования — если дойдут руки посмотреть/покопать в эту тему, поделюсь результатами. Но я уже совсем ушел на "темную" сторону этой темы :)