Почему в tarantool\redis хранимые процедуры если не на SQL, то на Lua?
Во всяком случае, к первому этот Lua просто "прибит гвоздями", и никто никогда даже не рассматривал возможность применить там что-то другое. (Или рассматривал?)
Ну, почему не рассматривали сразу несколько языков для хранимых процедур, это еще как-то можно понять. Типа усложнение чудовищное. Ок, пусть 1 язык.
Но почему именно на Lua остановились. Чем он лучше JavaScript, ну или хотя бы Python? Его мало кто знает, а отличий в нем много, даже на ровном месте можно нарваться на что-то, чего вообще нигде больше нет. Например, ~= - это, оказывается, просто !=. Мдааа... Даже паскальское <> - и то понятнее.
плохо искали, в том-же постгресе хранимки можно на куче языков писать (в том числе и на питоне - https://www.postgresql.org/docs/9.6/plpython.html). Ну и да - луа это вполне себе стандарт для использования в качестве скриптового языка (он для этого первоначально и создавался)
луа это вполне себе стандарт для использования в качестве скриптового языка (он для этого первоначально и создавался)
С учетом того, что я его сравниваю с JS и Python, этот аргумент звучит примерно как "что лучше, бмв или мерседес? - мерседес, потому что он автомобиль и изначально как автомобиль создавался". Как бы некая доля смысла есть, но маленькая.
Еще сталкиваюсь со странной тенденцией: почему-то все компилируемые языки максимально похожи друг друга, да и большинство из них в той или иной мере Си-подобные, а вот интерпретируемые - обязательно каждому разработчику языка надо выпендриться и сделать что-то не как у всех без всякого на то смысла. Почему это так?
beem7, ну в оглавлении вы написали про "все БД", если честно я упустил уточнение что вопрос в контексте только двух конкретных хранилищ.
1) размер. интерпретатор луа - 3-5Мб. интерпретатор питона - 30-50мб. для приложение в 10мб это вполне себе критично.
2) песочница. попробуйте гарантировать что пользовательский скрипт в питоне не начнет удалять файлы в системе. с тем-же луа это решается с коробки.
3) популярность. отвечая на вопрос "что использовать в качестве встроенного языка" в голову в первую очередь приходит луа/схема. во вторую - свой написание своего дсля. использование тут джаваскрипта я вообще никогда не видел (питон - видел).
4) исторически так сложилось. был успешный опыт использования луа, его и продолжили использовать.
а что с этого реально повлияло на выбор луа - могут только разработчики и ответить.
использование тут джаваскрипта я вообще никогда не видел
Я, конечно, извиняюсь... а то, что в браузере, чем не встраиваемый скриптовый язык-то?
И да, с песочницей там все хорошо. Относительно. Ни разу не видел рабочего и современного эксплойта на JS (социальная инженерия типа "Ваш браузер устарел, скачайте вот этот троян" сюда не относится).
beem7, вот напишите разработчикам тарантула и поспорьте с ними...
Заведите issue на гитхабе, вдруг заезд соберёте много и разрабы увидят в этом потребность и запилят
beem7, а возможность выковырять с браузера интерпретатор джаваскрипта и подключить к приложению на <название языка> есть? кроме установки ноджс и танцев с интеграцией и созданием песочницы? (чтоб запретить скрипту от васи пупкина параллельно с полезной работой еще и слить какие-то данные с диска). Пока не будет инструментария чтоб с пол-пинка подключить <название языка> в качестве скриптового - многие будут и дальше использовать луа. Просто потому что там по всем граблям походили, и будет быстрее потратить пару часов чтоб разобраться с синтаксисом и гарантировано получить рабочее решение
зы: я и сам не в восторге от луа, но свои задачи он решает
Еще сталкиваюсь со странной тенденцией: почему-то все компилируемые языки максимально похожи друг друга, да и большинство из них в той или иной мере Си-подобные
Fortran, Haskell, Scala, Delphi, Rust и Ocaml передают привет. Вот уж максимально похожие на Си языки
Василий Банников, ну так ты специально всякую гадость собрал. Причем с Rust я тоже сталкивался как с гадостью. Что как бы говорит о том, что в целом языков не так много странных. Ну и Delphi понятное дело не Си-подобный, да и устарел он.. А остальное - экзотика, некоторые еще и устарели тоже.
beem7, вы не находите противоречий? вы спрашиваете почему все компилируемые языки похожи, но при этом отказываетесь принимать как пример не похожих языков (т.к. "экзотика"). Да и в целом "похожесть" на си притянута за уши т.к. на примере больше хелоуворлда общего у си и шарпа/джавы - только скобочки.
ayazer, ты из тех, кто не способен понять, что у кошек 4 лапы, если есть хотя бы 1 чернобыльская кошка с 5 лапами?
Василий Банников собрал все, что мог, и устаревший Delphi, и кучу функциональных языков, и Rust, чтобы наскрести этот список компилируемых языков, не похожих на Си.
А в интерпретируемых языках различия на каждом шагу, без всяких причин, и искать язык другой парадигмы (как-то функциональная парадигма) для этого вовсе не нужно.
Да и в целом "похожесть" на си притянута за уши т.к. на примере больше хелоуворлда общего у си и шарпа/джавы - только скобочки.
Вовсе нет.
Например, конкатенация "Hello " и "World" будет через оператор +. И в C++, и в Java, и в C#, и в Rust, и в Delphi, и в VB.NET, и в Swift, и в Go.
А теперь интерпретируемые: JavaScript - +, Python - +, Perl - ., PHP - ., Lua - вообще ...
Ну что это? Я не говорю про всякие ссылки-указатели в компилируемых, где-то они есть, где-то они есть для особых случаев, где-то их нет. В этом есть смысл, это парадигма языка. Но в примере с конкатенацией различия на ровном месте, они ничего не дают каждому из языков, а головной боли добавляют.
Или вот - создание объектов на месте, чтобы сделать JSON.
В компилируемых языках подобной фишки, естественно, попросту нет :)
В интерпретируемых она есть, и это очень удобно... Пока ты пишешь на чем-то одном.
JavaScript: {x: 1, y: 2}
Python: {'x': 1, 'y': 2}
(ну тут как бы можно делать так же в JS, но тебя никто не поймет и все будут объяснять, что "можно без кавычек")
Lua: {x = 1, y = 2}
(ну а это уж вообще...)
beem7, я из тех кто понимает что множество "компилируемые языки" сильно больше множества "императивные компилируемые языки". Если вас интересовало только второе - надо было сразу и уточнять.
А на вопрос "почему в <название языка> для какой-то задачи используется синтаксис не как в <название языка>?" ответ может дать только автор/ы. Учитывая что многие интерпретируемых языков в вашем списке начинали свое развития как проект на коленке (без прицела стать известным на весь мир) нельзя исключать варианты "показалось что это хорошая идея"/"вдохновлялись другим языком с таким синтаксисом", а потом менять стало поздно.
Потому что интерпретатор Lua очень маленький и нетребовательный к ресурсам, но при этом обладает JIT-компилятором и высокой производительностью, а также встраивается намного проще, чем интерпретатор любого другого языка.
А почему интерпретатор Python такой огромный и медленный? А JS?
А "встраивается проще" - вообще странный аргумент... Проще вообще не создавать свою СУБД, а взять готовую. Не поверишь, но я бы так и поступил.
А почему интерпретатор Python такой огромный и медленный? А JS?
Во-первых, а почему ВАЗ-2170 такой медленный? Во-вторых, может перед разработчиками CPython и V8 стоял иной класс задач и встраивание не было главной целью?
Проще вообще не создавать свою СУБД, а взять готовую.
Что можно взять вместо Tarantool? И опять же, может у разработчиков Tarantool приоритеты иные, чем обеспечивать поддержку других языков в хранимках?
Во-вторых, может перед разработчиками CPython и V8 стоял иной класс задач и встраивание не было главной целью?
У Python и JS есть и другие интерпретаторы.
Что можно взять вместо Tarantool?
Многое, Redis можно, Mongo можно. Посмотри мой другой вопрос за сегодня. Там наглядно видно, что на простейшей задаче, требующей быстродействия, оказалось, что Tarantool не так уж и крут, а задача толкового решения на нем не имеет. Хотя в остальном в нем гораздо больше наворотов, чем в том же Redis... но не в Mongo, кстати.
И опять же, может у разработчиков Tarantool приоритеты иные, чем обеспечивать поддержку других языков в хранимках?
Не других, а какого-то одного языка, более популярного, чем Lua.
Не воспринимайте аналогию так буквально. Я о том, что в мире нет ничего идеального.
У Python и JS есть и другие интерпретаторы.
И у всех встраиваемость - не главный приоритет.
Многое, Redis можно, Mongo можно.
Нельзя. MongoDB - это документоориентированное персистентное хранилище, ориентированное на распределённость. Redis - это in-memory key-value хранилище, ориентированное на легковесность. Монга не сравнится с тарантулом по производительности и гарантиям ACID, а редис не сравнится с тарантулом по функциональности. Это разные системы с разным назначением.
Не других, а какого-то одного языка, более популярного, чем Lua.
Любой другой потребует больше ресурсов команды разработки, которые они могли бы кинуть на другие задачи, более приоритетные для проекта и более полезные для пользователей.
Нельзя. MongoDB - это документоориентированное хранилище, ориентированное на распределённость. Redis - это key-value хранилище, ориентированное на легковесность. Монга не сравнится с тарантулом по производительности и гарантиям ACID, а редис не сравнится с тарантулом по функциональности. Это разные системы с разным назначением.
Ну вот, как видишь по соседнему вопросу, функциональность у тарантула тоже че-то как-то оставляет желать лучшего.
Думаю, что я бы и в функциональность Redis ужался со своим брокером очереди сообщений, который собственно и пишу. Коль скоро самого главного (что и описано в том вопросе) в Tarantool все равно нету.
А вот про Mongo и ее плохое быстродействие... может быть. Ок, не буду рассматривать ее для своего брокера. Но тогда вообще непонятно - а в каких случаях Mongo хороша, кроме тех, когда нужна распределенность? Тот же Tarantool вполне документоориентированный со своими space'ами. А вот с посредственным быстродействием Mongo - да, сталкивался.
Любой другой потребует больше ресурсов команды разработки, которые они могли бы кинуть на другие задачи, более приоритетные для проекта и более полезные для пользователей.
А насколько реально стороннему разработчику это реализовать? На текущем этапе развития Tarantool. И будет ли кто-то пользоваться такой версией Tarantool?
beem7, вполне реально, если разработчик владеет C на должном уровне и разобрался во внутреннем устройстве СУБД. Форкаешь репу https://github.com/tarantool/tarantool, делаешь ветку, в которой реализуешь новый функционал, отправляешь PR. Если всё сделано правильно и хорошо, PR принимают и Tarantool обзаводится нужным вам функционалом.
Сергей Горностаев, это хорошая такая инструкция на тему того, как добавить в тарантул какую-нибудь мелочь :) А тут, если на то пошло, то я боюсь, что идею проще будет отвергнуть, чем смотреть все нюансы десятков тысяч строк ее реализации.
beem7, вам правильно советовали начать писать свою реализацию, может выстрелит, а изливать душу на форумах не может, все так же останется на своём месте
