Comments 30
Чего я искренне никогда не понимал (возможно, недостаточно вникал в тему) - зачем вообще встраивать свой скриптовый движок под конкретный язык вместо того, чтобы предоставить API и позволить пользователям писать скрипты/плагины на том языке, на котором им самим удобно.
Изоляция кода пользователя, ограничение ресурсов, упрощение API. Ну и просто чтобы для плагинов был простой язык,но это не значит что "упрощённый" (всё зависит какие api предоставить). Не каждый пользователь готов разбираться например с C\C++ для плагина, а вот на lua вполне могут осилить
Так если у меня есть API, что мешает пользователю написать свой скрипт/плагин, который его дёргает, хоть на Lua, хоть на Visual Basic или что там для него ещё проще? И чем такой скрипт/плагин, который запускается в своём процессе (да и вообще хоть на другой машине) и имеет доступ только к тем эндпоинтам, которые я сам открыл, будет менее изолирован и ограничен, чем встроенный?
Например в wireshark используется Lua для парсинга - просто и быстро. Да можно было хоть tcpdump прасить с помощью внешних скриптов, но встроенное апи обычно продумано разработчиками и предоставляет удобные средства. Веб апи и эндпоинты не беру в расчёт, это чуть из другой оперы (предоставление готового функционала, а плагины обычно встраиваются в процесс обработки, наподобии интерсепторов) С помощью эндпоинтов я могу построить внешнее приложение со своей логикой, но как повлиять на логику приложения которое предоставляет эндпоинты? (Я от веба далёк, может чего и не понимаю)
Если мы про веб (а часто есть смысл реализовать именно веб-технологии, даже если у нас общаются друг с другом исключительно процессы на разных портах localhost) - то есть вебхуки/вебсокеты, чтобы реализовать обратную связь (вызов пользовательского кода по событию в приложении).
Если не веб, то, помнится, когда я последний раз писал что-то для десктопа (давно), на Windows был COM, вполне удобно тоже.
В общем, технологий-то много, под конкретный случай можно подобрать оптимальную. А заставлять пользователя писать на одном единственном языке, каким бы он простым ни был, - ну негуманно же.
Это сложна. Это надо уметь полностью отделить слой API от слоя ядра приложения и слоя скриптов. По крайней мере это потребует рефакторинга всего приложения. А скрипт на lua можно закостылить в произвольное место в коде, как в этом примере из статьи
Скрытый текст
package main
import (
"fmt"
lua "github.com/yuin/gopher-lua"
)
func main() {
var l *lua.LState = lua.NewState()
defer l.Close()
if err := l.DoFile("fib5.lua"); err != nil {
panic(err)
}
// достаем результат выполнения с вершины стэка
result := l.Get(-1) // result типа lua.LValue
// и очищаем его
l.Pop(1)
fmt.Printf("result: %d\n", result) // result: 5
}
Не всегда возможно дать доступ по API, а даже если и можно, то это будет слишком медленно. Например, какой-либо процесс в игре, который был модифицирован пользователем. В теории мы можем высылать callback пользователю, он его обработает и даст ответ. Но сколько времени это займет? Звучит непозволительно долго. В таких сценариях мы вынуждены запускать код на том же сервере, где этот процесс происходит. А lua для этого подходит лучше всего, хотя я и не люблю этот язык.
Спасибо, вот это действительно понятный сценарий - запускать на стороне сервера скрипты, которые пользователь, не имеющий доступа к серверу, создаёт на стороне клиента. Не знаю, зачем это в играх (и зачем вообще в играх скрипты), страшно далёк от игрового мира :) - но такая возможность и для многих полезных задач явно пригодится. Хотя вопросы безопасности, на первый взгляд, весьма нетривиальные возникают.
Собственно, только что NeoVim именно так и поступил. После чего выяснилось, что писать на языке удобно, а паковать написанное - отнюдь. Так что либо не писать плагины на Python, либо предполагать что в системе Python установлен.
Писать на Go - либо нужен ещё один плагин который будет вызывать компилятор, что фактически и было сделано в Unity с C# на деньги Микрософт, либо это будет делать пользователь. А встроеный интерпретатор позволяет оставаясь в NeoVim написать и тут же выполнить.
В своё время в NeoVim была выбрана Lua потому, что интерпретатор очень маленький и специально создавался для встраивания а код на С, то есть ожидался быстрым. Потом выяснилось, что Lua развивается, а NeoVim это отслеживать неохота, и они просто зафиксировали версию. А тот же JavaScript использовался везде и ускорялся всем миром, так что теперь Lua и не на много меньше, и отнюдь не быстрее, и сказать что в Neovim Lua, опустив слово "старая", не совсем честно.
Зачем вообще плохой вопрос когда исторически сложилось.
Это прекрасно, когда есть альтернатива - или встроенный скриптовый язык из коробки, или пользователь ставит / компилирует весь необходимый тулинг под свой любимый ЯП сам и использует его.
Меня эта тема, собственно, задела, потому что часто не так. Я человек любознательный, софта использовал за свою жизнь много разнообразного. И вынужден был писать и на Lua, и на полудюжине диалектов Basiс, и на Go, и на Lisp (угу, Emacs), и на Python и JS (которые никогда по своей воле не выбрал бы), и даже на Clojure и Forth. Наверняка не все ещё вспомнил. Я уж молчу про своеобычные языки AutoHotkey и Mikrotik, которые спроектированы, кажется, с одной целью - чтобы абсолютно любой ЯП после них показался счастьем :)
Основная причина старой версии lua - это использование LuaJIT. Что также делает lua прекрасным выбором для плагинов.
Универсальных API не существует. Ну то есть можно, конечно, в конечном итоге привязаться к C-binding, но для какого-нибудь простого языка типа того же Lua это потребует таких усилий, что мало кто из пользователей будет на это готов.
А Lua правда нужен в современном мире при условии, что уже есть JS?
По мне так для скриптов нет ничего лучше JS. Он простой, он прощает почти любые ошибки, он достаточно быстрый. И главное, по нему куда больше информации чем по Lua.
Нет ничего лучше JS!? Это ещё надо постараться придумать что то хуже JS! Если бы не его монопольное положение в браузере, этот язык вообще никому не был бы интересен сейчас.
Если бы он был никому не нужен, не было бы никакой монополии. Луа в браузере вообще не работает :)
Отбросьте негатив. Скоро это все вытеснит вайб колинг.
Луа в браузере
Web-asm. Я так AngelScript запускал
Тогда уже просто дать возможность подключить webasm модули. Язык там роли не играет.
Нельзя позволить пользователям загружать webasm - это получится как XSS - "дыра в безопасности."
Я люблю JS. Но нет ни одной нативной альтернативы в браузерах. Хотя как уже заметили, через asm даже c# на страницах запускают - привет blazor.
Да, я б с радостью променял JS в браузерах на что-то типизированное. Хотя тот же TypeScript вполне себе ничего, разве что добавляет отдельные шаги сборки.
JS в браузере === работа с DOM почти всегда и, на сколько помню, webasm не позволяет это делать напрямую. Поэтому всякие blazor-ы от этого страдают. Ну и в целом JS - язык который развивался вокруг веба (и только его по сути), поэтому другой язык для веба впихнуть будет очень неудобно.
lua позволяет sandboxить выполнение скрипта, то есть абсолютно убрать возможность доступа к файловой системе, сетевому стеку и прочее. Как, например, это сделано в redis. Насколько мне известно, никакой из мейнстримных "скриптовых" языков (javascript, python) такого делать не умеет.
Потому что Lua ничего не сендбоксит. Это делает движок, который ее исполняет. И точно так же можно делать и с любыми скриптовыми языками. Все зависит от того как он запускается.
Почему-то умные дядьки и тетьки из postgres не умеют сандбоксить python (plpython3u https://www.postgresql.org/docs/current/plpython.html, где буква u означает untrusted, то есть умеет все, что умеет python), а вы говорите, что можно. Можно оно-то все можно, только вот насколько это сложно и рентабельно - вопрос другой. А вот в redis полностью sandboxed версия lua стоит из коробки, что позволяет атомарно выполнять скрипты любой сложности на уровне БД.
Если вы имеете в виду, что можно запускать скрипты внутри средств контейнеризации, то согласен с вами. Но опять же, контейнер - штука недешевая. И если вам нужно запускать сотни таких скриптов в секунду, то можно забыть о такой реализации.
Возможно умные дядьки из Postgres решили не писать свой интерпретатор Python, а использовать что есть. А там, видимо, так делать нельзя, я не в курсе, python - не мой стек, не люблю его.
Нет, я имел ввиду, что интерпретируемый язык в целом сам ничего не решает. Это просто язык. Никто вам не запретит на Lua написать чтение/запись файла, это просто работать не будет, потому что ограничено со стороны интерпретатора.
Тут чистый маркетинг: якобы пользователь сам сможет написать нужное расширение или "на коленке" что-то поправить, и приводятся простейшие примеры, очень привлекат потенциальных покупателей.
...в реальности, требуются сложные вещи, которые пользователь заказывает (часто - у разработчика базовой стстемы). Разработчик в итоге страдает от ограничений скриптового языка. К примеру, нас отчетная система расширяется скриптовыми модулями. За 20 лет существования системы не припомню, чтобы пользователь накодил что-то вменяемое. Позже была добавлена система плагинов, плагины могут быть реализованы на любом ЯП, поддерживающем интерфейсы. А прежнюю скриптовую систему по просьбе продавцов выпиливать не стали, ибо покупатели клюют на такую фичу, ну и легаси.
... наверное, можно (в качестве рекламного шага - "вот что у нас есть!") реализовать и скриптовую систему как вариант реализации интерфейсов плагинной системы, чисто для продавцов.
python<->rust вызвать проще через PyO3, причём можно в обе стороны
Я видел проекты, написанные почти полностью на Lua.
Луа неплох для отднострочников.
Но когда на нем хотят написать ВСЁ.Это ад - WriteOnly код без возможности рефакторинга и отладка только принтами(там использовалась VFS и MobDebug не мог найти файлы).
Что такое Lua: почему стоит его попробовать и как встроить в программу на Go