Comments 22
Привет! С дебютом. А почему всё-таки LUA? Ну т.е. чем вы руководствовались когда его выбирали?
1. В те времена, когда начиналась разработка Tarantool (а это даже раньше 2009 года), альтернатив не было видно даже на горизонте.
2. Lua очень простой и компактный язык, не требующий изучения двадцати томов большой советской энциклопедии для начала работы. По большему секрету скажу, что ни в Mail.Ru, ни у других пользователей Tarantool нет специально обученных Lua-программистов для работы с Tarantool. С написанием хранимок на Lua одинаково легко справляются как JS, так и PHP/Perl/Ruby/Go/whatever разработчики.
3. Мы пробовали встраивать V8 где-то с годик назад. По началу в синтетических тестах все казалось очень быстрым. Когда же реализовали простейший биндинг к space:select() — v8 стал сливать Lua по производительности примерно в раза 3-4. Каждое создание объекта в v8 делалось настолько долго, что ни о какой высокопроизводительной базе данных с хранимками уже особо не могли идти и речи. Мораль сей басни такова, что если в виртуальной машине быстрая числодробилка, это никак гарантирует быстрой производительности в целом на реальных задачах.
В Tarantool 1.6.7 мы также открыли C API, дав возможность написания хранимок на C/C++ и других языках. Сейчас в качестве разминки пальцев можно взять данное API и заново попробовать уже на нём запустить какой-нибудь еще язык. Вопрос только какой?
2. Lua очень простой и компактный язык, не требующий изучения двадцати томов большой советской энциклопедии для начала работы. По большему секрету скажу, что ни в Mail.Ru, ни у других пользователей Tarantool нет специально обученных Lua-программистов для работы с Tarantool. С написанием хранимок на Lua одинаково легко справляются как JS, так и PHP/Perl/Ruby/Go/whatever разработчики.
3. Мы пробовали встраивать V8 где-то с годик назад. По началу в синтетических тестах все казалось очень быстрым. Когда же реализовали простейший биндинг к space:select() — v8 стал сливать Lua по производительности примерно в раза 3-4. Каждое создание объекта в v8 делалось настолько долго, что ни о какой высокопроизводительной базе данных с хранимками уже особо не могли идти и речи. Мораль сей басни такова, что если в виртуальной машине быстрая числодробилка, это никак гарантирует быстрой производительности в целом на реальных задачах.
В Tarantool 1.6.7 мы также открыли C API, дав возможность написания хранимок на C/C++ и других языках. Сейчас в качестве разминки пальцев можно взять данное API и заново попробовать уже на нём запустить какой-нибудь еще язык. Вопрос только какой?
Haskell конечно же!
Если его не разнесёт от переключения Сишных стеков в корутинах, то можно попробовать уже сейчас.
Shared libraries (.so) мы уже умеем загружать, даже по протоколу через CALL можем вызывать по имени функции.
Достаточно лишь биндинги наваять.
Shared libraries (.so) мы уже умеем загружать, даже по протоколу через CALL можем вызывать по имени функции.
Достаточно лишь биндинги наваять.
Судя по githut.info
Активность языка Lua заметно выше чем у Haskell
Активность языка Lua заметно выше чем у Haskell
Так то там и vimL есть с активностью больше Go и Perl, но от этого конфиги вима автоматом не стали удобным языком программирования.
Активных репозиториев у Haskell больше, нет? по той диаграмме.
Пушей меньше, и сильно меньше тикетов — но живых проектов-то чуть больше. Меньше багов, коммиты посодержательнее :)
Пушей меньше, и сильно меньше тикетов — но живых проектов-то чуть больше. Меньше багов, коммиты посодержательнее :)
Nginx модуль в интерфейсе для клиента получается привязанным к модели JSON RPC сервера.
Это означает, что даже для простого получения данных необходимо формировать вызов метода.
В данный момент популярно/молодёжно/втренде REST API.
Было бы неплохо реализовать такую модель работы: имя метода в пути URI или зашит в конфиге nginx, а параметры берутся из URI.
Еще неплохо было бы где-то встроить поддержку oauth2.
Это означает, что даже для простого получения данных необходимо формировать вызов метода.
В данный момент популярно/молодёжно/втренде REST API.
Было бы неплохо реализовать такую модель работы: имя метода в пути URI или зашит в конфиге nginx, а параметры берутся из URI.
Еще неплохо было бы где-то встроить поддержку oauth2.
Ценное замечание. REST хотят многие, сделаем в след. версии.
Кстати, про Tarantool, почему LUA, новый вид апп-серверов на базе nginx и tarantool'а и прочее мы общались с Костей Осиповым у меня в SDCast'е #20: sdcast.ksdaemon.ru/2015/03/sdcast-20
зачем LUA, когда ввели js
это было бы куда интереснее
это было бы куда интереснее
rtsisyk ответил ранее.
Добавлю от себя, сейчас есть возможность сделать биндинги в другие языки, достаточно просто, главное требование: язык, в который биндим, не должно разносить от С-шных корутин.
Кое кто даже _планирует_ попробовать js, а там как пойдет.
И не надо боятся lua он простой но, конечно, со своими приколами.
Добавлю от себя, сейчас есть возможность сделать биндинги в другие языки, достаточно просто, главное требование: язык, в который биндим, не должно разносить от С-шных корутин.
Кое кто даже _планирует_ попробовать js, а там как пойдет.
И не надо боятся lua он простой но, конечно, со своими приколами.
Чем же интересней? Может тогда сразу perl/python/php?
Что все к LUA прицепились? Нормальный встраиваемый язык. Только с библиотеками всё плохо, конечно. Не понятно как писать на нём что-то большое (то есть понятно как — писать всё самим, но не понятно зачем).
Вначале статьи есть подводка почему использование связки nginx + tarantool вместо традиционных способов лучше.
А плюсы в конце статьи как то вообще про другое. Близость кода и данных какое-то сомнительное достоинство.
А LUA, как я понимаю, в один поток выполняется на сервере?
Вначале статьи есть подводка почему использование связки nginx + tarantool вместо традиционных способов лучше.
А плюсы в конце статьи как то вообще про другое. Близость кода и данных какое-то сомнительное достоинство.
А LUA, как я понимаю, в один поток выполняется на сервере?
Sign up to leave a comment.
Строим сервисы на базе Nginx и Tarantool