Комментарии 70
Про этот ЯП можно было бы рассказать гораздо больше всего интересного, с примерами и пояснениями.
Согласен. Что бы вам прежде всего хотелось видеть в развёрнутом разборе?
Спасибо за предложения! Вот краткие ответы на некоторые вопросы, пока не написал подробный разбор или не нашёл достойный для перевода:
Есть ли варианты интерпретаторов с JIT-компиляцией?
Есть! LuaJIT
Что с легковесностью, какие самые лёгкие интерпретаторы?
Стандартный интерпретатор весит 282 Kb, а вся стандартная библиотека — 470 Kb.
Можно ли запустить скрипт на восьмибитном контроллере с парой килобайт памяти?
Можно, причём даже делают миниатюрные виртуальные компьютеры с интересными ограничениями — TIC-80
Что с управлением памятью? Сборка мусора, refcounting, или все ручками?
Сборка мусора.
Корутины - было бы интересно посмотреть, какие они и как сделаны внутри
Стандартный интерпретатор весит 282 Kb, а вся стандартная библиотека — 470 Kb
Не знаю, что у вас за стандарт такой. У меня такой:
root@рhost:~# /usr/bin/lua -v
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio (double int32)
root@host:~# ls -lh /usr/bin/lua
-rwxr-xr-x 1 root root 9.2K Dec 31 1969 /usr/bin/lua
root@host:~# ls -lh /usr/lib/liblua.so.5.1.4
-rw-r--r-- 1 root root 171.4K Dec 31 1969 /usr/lib/liblua.so.5.1.4
И это ещё с поддержкой целочисленной арифметики
Клёво!
А я имел в виду самую последнюю версию интерпретатора и прямую цитату с официального сайта, в параграфе "Lua is small"
Есть ли варианты интерпретаторов с JIT-компиляцией?
Они не просто есть. LuaJIT является одним из быстрейших интрепретаторов языков с JIT-компиляцией, и долгое время обгонял супер-оптимизированный V8 для JavaScript от гугла (сегодня это уже не так). А если нужно еще быстрее, то можно определять сишные типы через встроенный модуль FFI, и работать уже с ними.
Не оспаривая достоинств Lua... Примерно всé, кто в принципе умеет / готов что-то по мелочи запрограммировать, в наше время ужé знают или Python, или JS. Мне лично несимпатичен ни тот, ни другой, но это факт. И пусть Lua проще / легковеснее их обоих - это всё равно новый язык, который надо освоить, а потом на него ещё и переключать мозги для Lua-специфичных задач, если в основном пишешь на другом языке. Так что если бы сейчас стояла задача внедрить в продукт какой-то скриптинг для продвинутых пользователей - выбирал бы именно между Python и JS (лучше, конечно, универсальное решение с binding'ами к разным языкам, но тут уж от ресурсов зависит).
суть луа в том, что его удобно встроить куда-то, в то время как питон (особенно современный 3й) встроить внутрь nginx кажется задачей непомерно громоздкой и неудобной.
Луа это как PCRE библиотека - удобное для интеграции легковесное и популярное решение.
Ну систему, где нет python, надо ещё поискать. Хотя для приложений типа nginx или haproxy, которые могут запускаться на минималистичном урезанном дистрибутиве и такой сценарий нормален и важен, - соглашусь. Но в списке софта со встроенным Lua много приложений, для которых таких ограничений нет, и встроить в них можно хоть JRE с .NET на пару, никто особо и не заметит :) А вот за знакомый язык скажет спасибо.
Смотрю с точки зрения того самого пользователя, которому уже изрядно надоело вникать в очередной язык ради нескольких десятков строчек скрипта, которые надо очередной софтине скормить (а в списке таких языков в моей практике уже побывали и Lua, и Clojure, и Groovy, и вообще своеобычный язык Autohotkey, а про тысячу и одну разновидность query language вообще молчу).
Ну примеров использования языка достаточно, что бы задуматься: Roblox, WoW, Lightroom.
поискать - embedded системы бывают чувствительны к размеру образа.
Мне, кстати, лет 10 назад довелось поработать со встроенной системой, в которой единственным ЯП был Python. То были интегрированные GSM/GPS модули Telit. И вот чтобы железяка могла делать что-то полезное, в неё через последовательный порт по протоколу z-modem заливался файл .py, потом она перезагружалась, несколько минут внутри себя "транслировала" скрипт в двоичный Python object, после чего была готова к работе.
На всю жизнь запомнилось.
А там какой-то стандартный питон или что-то альтернативное было?
Насколько я тогда мог судить, вполне стандартный. Естественно, никаких дополнительных библиотек ему поставить было нельзя. Были видны несколько объектов для чтения координат из GPS, общения с GSM-модемом с помощью AT-команд и управления внешними линиями GPIO на разъёме. Тогда Python в небольшой плоской коробочке размером 50мм*50мм выглядел, как маленькое чудо.
Ну систему, где нет python, надо ещё поискать.
Это вы про большие машины. На моём кэноне нет питона, но зато есть луа. ЕСП8266 всякие тоже отлично работают под управлением луа скриптов. Впрочем, на них есть и микропитон.
ЕСП8266 всякие тоже отлично работают под управлением луа скриптов.
Ну, так себе. Интерпретирующий язык, который свалится не при компиляции, а во время работы. Очень многословный (по сравнению с C/C++). Программа то заработала, но удовольствия от процесса нет ;)
Ну систему, где нет python, надо ещё поискать.
Вы не поняли контекст?
Система - имеется ввиду встроенный скриптовый язык в вашем приложении, а не отдельно установленное в операционке.
Вот насколько было бы лучше, если бы в Autohotkey скриптовым языком был бы луа, а не то, что там сейчас?
Ну систему, где нет python, надо ещё поискать
10 лет назад люди впихнули интерпретатор Луа в ядро ОС NetBSD. Питона в такое место засунуть не получится
Ну систему, где нет python, надо ещё поискать
Windows7 например
https://github.com/arut/nginx-python-module
Вот же. Python в nginx
Вообще и python и perl прекрасно встраивается. Много где встроены
Этот модуль разве не потребует установленного питона на машине? В таком случает это не тот уровень встраивания как lua.
Модуль луа тоже liblua требует. Просто оно меньше. А как вы попробуете хоть что-то кроме примеров запрограммить, тут же окажется что вам нужны другие lua библиотеки и биндинги к odbc, к примеру
Не требует, так как Lua тривиально собирается в статическую библиотеку, или вообще компилируется из исходников при сборке вашего проекта (как встраиваемый sqlite).
Вот про встроенные батарейки это конечно в точку, на с другой стороны это и преимущество — можно встроить именно сам язык, а не язык со стандартной и не очень библиотекой. Если хотите, то даже math можно не встраивать.
Python "встраивается" в том смысле, что можно внутри программы организовать интерфейс, чтобы внешний интерпретатор Python мог в него ходить? По аналогии с COM из мира Windows? Мне кажется, Python слишком тяжёл, чтобы его целиком засунуть внутрь прикладного софта. В отличие от Lua или того же TCL.
Версия Python там — 2.7, а кроме того нужно учитывать временной лаг на старт его интерпретатора. Пока Python только будет запускаться, скрипт на Lua уже отработает, особенно если он запущен с использованием JIT компиляции :)
По-моему, не надо путать язык (синтаксис и стандартная библиотека) и среду исполнения. Лёгкие рантаймы есть для разных языков, вон даже есть ВМ Java для AVR, вероятно, самого дохлого микроконтроллера из ныне используемых.
Луа, вроде, зародился в академических кругах, а потом как-то проник в реальную жизнь. И он ничем не лучше других. Даже хуже! Например, JavaScript лучше хотя бы тем что его "всё знают" (кроме питонистов, возможно :) ). Т.е. привычный синтаксис и куча разных рантаймов, например, можно использовать JavaScript внутри программы на Java.
Что касается статьи.... Ну в Википедии написано больше. Мини то, ни другое не отвечают на вопрос зачем мне учить ещё один язык (а чтобы что-то внятное писать, учить его придётся и то что для этого хватит вечера субботы - маркетинговая коровья лепёшка).
У Micropython есть Embed - версия. Компилируется вместе с проектом на С.
https://github.com/micropython/micropython/tree/master/ports/embed
Скажем из Си в питон прибиндиться можно без особой боли, но вот чтобы наоборот - придётся пострадать. Для JS только недавно полноценные легковесные рантаймы появились, для луа они есть уже раза в три дольше. И таки нет такого огромного количества странных поведений, сколько их есть в JS, чем в классическом луа (PUC Rio), поэтому JS - сомнительный выбор для скриптинга. Проще тогда вообще с ним не связываться, а писать сразу на wasm.
Знаешь притчу о двух волках? Побеждает тот которого ты кормишь. Один волк это JS, а другой это Lua. Пока что IT сообщество кормит JS, а Lua сидит в яме и ждёт, когда неосторожная жертва упадёт вниз.
Embed-Микропитон:
https://github.com/micropython/micropython/tree/master/ports/embed
Пожалуй соглашусь с автором выше. Я ожидал более развернутой статьи, но все равно неплохо.
Если по найму, то выбирать вредно, как господин начальник сказали, так и будет. Если не по найму, то где больше библиотек, это или Python или JavaScript. А встраивать, тогда Lua хорошо, это высоковат уровень и специфичны задачи.
Кто понимает что хоть один язык надо знать действительно хорошо и библиотеки ему, в силу оригинальности, без особой надобности - Lua отлично. Но обойтись только ей - без шансов, а тем же Python какие-то шансы есть.
ИМХО запев про Lua однозначен - она скриптует Neovim.
Для разработки и отладки скриптов на Lua использую редактор SciTe, который написан на Lua. Есть API C for Lua, с помощью которого можно решить любые проблемы с быстродействием или с расширением функциональности. Lua это язык с динамической типизацией. Но есть очень интересные диалекты с включением статической типизации и параллельным вычислением на уровне jit компилятора. VM Lua примерно в 5 раз быстрее интерпретатора Python. Lua прекрасно работает на любом микропроцессоре и встраивается в любой SoC.
Ну все же написан SciTE на плюсах, а Lua туда встроен.
Спорить не буду, но рекомендую посмотреть исходники. Само приложение естественно написано на Си ( заголовочные файлы *.h), VMLua и все библиотеки - это тоже Си. Но это и так понятно, так как нет аппаратного процессора для данного языка. Он же скриптовый.
Все настройки для различных языков, а также функции обработки текста реализованы на луа.
Кроме того, в этом редакторе легко подключить и LuaJIT.
В результате легко тестировать скрипты в окне редактора.
API C позволяет писать dll, встаривать их в Lua и отлаживать в этом редакторе.
с лайвкодингом и удалённой отладкой,
в том числе для redbean (https://notebook.kulchenko.com/redbean/redbean-debugging-with-zerobrane-studio) который тоже можно упомянуть раз уж про вебфреймворки в статье вспомнили.
Нет нужды беспокоиться о float, int, usize
Ага. Нет нужды беспокоиться... Но есть нюанс: number - это сразу два типа: float и int. В зависимости от контекста и операций они разные. И это ведет к неочевидным(хоть и не частым) проблемам.
Честно говоря, лучше бы сделали для разных типа. Потому что сейчас выглядит так, что хотели сделать "как проще", а потом оказалось что так не работает и навешали костылей.
Да, действительно, только эти "костыли" всё же идут намного дальше, чем чинят такую мелкую проблему. Например, Nelua добавляет статическую типизацию, опциональную (!) сборку мусора и транспиляцию в C или напрямую компиляцию в машинный код.
ну да, небольшие костыли, потому что приделывали опосля, изначально решив что 640кБ 53бит мантиссы double хватит для любого целого числа. как и битовых операций тоже когда-то там не было.
ну хоть так.
Я в своё время выбрал Squirrel, потому что он ближе по синтаксису к C/C++.
Для разработки на Lua есть ZeroBrane Studio https://studio.zerobrane.com/.
Авторы Lua не гарантируют обратной совместимости.
На Lua можно писать макросы и скрипты для FAR Manager 3.0.
Порой приятно сидеть и читать что то такое простое и понятное, про лёгкий язык, который при этом может сделать многое. Спасибо за статью! Даже не смотря на краткость получилось крайне интересно
Учил в своё время Lua, очень добрый и приятный язык, сделано в Бразилии. Но когда попробовал на нём рисовать, там есть только OpenGL2, а OpenGL3 уже нет. Потому что в OpenGL3 есть команды с двойными указателями ** и даже LuaJIT не может их понять (с одной звёздочкой может, в Lua вообще нет указателей, но LuaJIT позволяет вставлять в Lua кусочки кода на C). А так, гораздо приятнее, чем Питон и Яваскрипт. Lua, кстати, придумана (она женского рода, Lua значит "Луна") на год раньше Яваскрипта. В былые времена несколько раз слышал от разработчиков на Яваскрипт "как хорошо было бы, если бы сразу выбрали Lua вместо Яваскрипт!" Яваскрипт был сделан на коленке за два дня (как рассказывал его разработчик), что поначалу очень чувствовалось (сейчас его, кажется, доработали)
Потому что в OpenGL3 есть команды с двойными указателями ** и даже LuaJIT не может их понять
Вполне понимает. Пример из моих биндингов для sqlite:
-- модуль биндинга
...
ffi.cdef [[
int sqlite3_open(const char*, sqlite3**);
...
]]
...
function funcs.open(filename)
local db_p = ffi.new('sqlite3*[1]')
local code = clib.sqlite3_open(filename, db_p)
return code, db_p[0]
end
...
-- использование
local sqlite = require 'sqlite3' ('sqlite3')
local SQLITE = sqlite.const
local code, db = sqlite.open(':memory:')
...Очень показательный пример в свете удобства C FFI в Lua, спасибо, что делитесь!
Да не за что. Если интересует более полная версия, то можно посмотреть код на github для luajit-sqlite, luajit-tcc, luajit-glfw. У последних двух есть минимальный readme, и они в принципе рабочие и актуальные, не смотря на долгое отсутствие обновлений.
Эти биндинги создавались частично в автоматизированном режиме с помощью скрипта на том же luajit. Нужные определения из C копировались в cdef, потом используя немного магии интроспекции прямо из под капота luajit'а извлекался список определений, и на его основе генерировался текст функций для всех не слишком сложных случаев. А уже потом я вручную допиливал где требуется более сложная логика.
А еще для Lua есть простенький аналог nodejs - luvit. Позволяет быстро писать простенькие серверные приложения:
local http = require('http')
http.createServer(function (req, res)
local body = "Hello world\n"
res:setHeader("Content-Type", "text/plain")
res:setHeader("Content-Length", #body)
res:finish(body)
end):listen(1337, '127.0.0.1')
print('Server running at http://127.0.0.1:1337/')Вместе с ним идет менеджер зависимостей, который дополнительно умеет упаковать среду выполения, скрипты, и ассеты (в т.ч. библиотеки) в один единственный исполняемый файл.
Для разработки использую ZeroBrane (luacheck встроен), Sublime Text 4 с плагинами LSP + LSP-Lua (оба есть в packagecontrol).
Нет нужды беспокоиться о float, int, usize
Вот тут враньё. Очень даже стоит беспокоится. Т.к. в lua используется для представления числа или int64 или double. И когда используется int64 переполнения ведут себя как модульная арифметика по модулю 2^64, а когда double нет.
x=1<<63 print(x) x=x*2 print(x)-9223372036854775808
0ps: В отличии от питона lua можно собрать C компилятором под любую платформу например под dos
У нас примерно миллион строк на Lua + миллион строк C++(либы + биндинги либ в Луа)
И это боль - отсутствуют нормальные инструменты для поддержки подобного количества кода на Lua(частично скрашивает плагин EmmyLua для IDE от JetBrains, но там есть свои проблемы)
Многие ошибки всплывают только у клиентов(в основном очепятки, nil-ы и подобное).
Исправление одной ошибки занимает от суток до бесконечности.
Не используйте Lua как основной язык - максимум длины для Lua-скрипта - строк 50(ИМХО)
Я устал от Lua.
миллион строк на Lua + миллион строк C++
А как так получилось? Прикрутили Lua для небольшого скриптинга, но это вышло из-под контроля и на нём стали целые фичи хреначить?
ну для visual studio есть отличный плагин для отладки lua(LuaDkmDebugger), который позволяет и точки останова делать и смотреть локальные параметры почти так же как если это был бы код на C++, но согласен что тонны кода на скриптовых языках это боль
С моей точки зрения это очень удобный язык для управления железом, я выпускаю станки с ЧПУ со своей стойкой, и на LUA организован один из самых больших плюсов нашей стойки - интерпретатор G-кодов. Дело в том, что каждый производитель стоек дает свой набор G-кодов, и пользователь станков сразу привязан к производителю стоек, так как у него накапливается большой архив программ обработки именно для этой стойки, и когда он будет приобретать новый станок ему будет нужна именно такая стойка. А мы на LUA написали транслятор который программу для любой стойки переводит в программу для любой другой стойки
По моим впечатлениям язык действительно очень легкий для освоения, при наличии опыта с другими ЯП втягиваешься в разработку «с колёс». Из недостатков — дебаг приложения и набор сторонних библиотек и фреймворков. Например, с взаимодействием с Kafka было немало трудностей.
Не так давно переписали наше платежное emv-kernel в новую архитектуру, как раз с использованием LUA
https://mst-company.ru/blog/u-nas-novoe-emv-yadro
А ещё луашку использовали для скриптов в пятых героях, и фрилэнсере ;) так что можно и для них на этом языке что-то пилить)
Для VS Code есть очень хорошее расширение - lua-language-server by Sumneko. По своим возможностям он превосходит плагин EmmyLua для IDE от JetBrains. Кстати, этот же сервер можно использовать и в Neovim.
А для отладки в VS Code есть расширение LuaDebug от actboy168.
Выбирая между ZeroBraneStudio и VS Code с этими расширениями, я выбрал VS Code.
Lua: маленький язык, который смог