врятли. «Быстрых, легких» скриптовых языков примерно дохрена. А вся статья состоит из перечисления минусов этого языка. Причем минусы такие, хорошие и жирные.
А после 4х часов утра на хабре сидят очень злые и невыспавшиеся люди. Сейчас народ к 11 на работу подтянется, будут вам плюсы )
А по поводу «быстрых и лёгких» дохрена — это спорное заявление. К тому же, фишка Луа в том, что в языке достигнут хороший баланс по всем перечисленным показателям, не только по быстроте и скорости.
Но мне холиваров по поводу языка разводить здесь совсем не хочется. Я никого Луа использовать не заставляю. Те, кто использует — те обычно знают «в чём фишка». ;-)
Ну, в Аегисабе (для которого я и пишу на Lua) для UTF-8 есть свой костыль. Про отдельные библиотеки тоже давно знаю, но хочется же, чтобы всё это было родное.
Там дальше в треде народ пошёл ещё раз перечислять проблемы с Юникодом у тех, кто использует Луа под Windows… Можно излить свои печали, иногда это работает.
Хочу уточнить на всякий случай, что проблемы с Юникодом под Windows возникают в основном при работе с юникодной файловой системой через io.* (что всё равно обычно отдаётся на откуп движку — так что не страшно). Сами юникодные строки можно использовать — так же как и на других платформах.
А есть ли ссылка на какой-нить вменяемый туториал (желательно под с++), как связать и в чем сила использования Луа? Просьба не минусовать, а отнестись с пониманием. Луа на слуху уже года 3 как (или даже больше), периодически то тут, то там всплывает информация. Но найти простой, и главное содержательный и показательный урок по её использованию пока не удалось. Буду благодарен за толковый линк на статейку, где показаны все прелести и радости от использования Луа.
статья с gamdev.net есть переведенная на русский на gamedev.ru. видел эту статью, изучал, но понимания чем lua в данных примерах лучше банального ini файла не появилось. остальные ссылки спасибо посмотрю, но кажется там тоже не совсем реальная жизнь отражена.
Вот ещё есть паттерн Alternate Hard and Soft Layers, там есть несколько полезных мыслей по поводу использования скриптовых языков вообще. Там, правда довольно сумбурно написано.
в каком виде? share nothing с изолированными состояними и обменом сообщениями есть в виде минимум нескольких библиотек (lua lanes, например). share everything — авторы против такого подхода.
Распараллеливание кода в Луа отлично получается и без поддержки системных потоков самим языком. (Понятное дело, что для этого нужны изолированные стейты, но это и хорошо, лучше масштабируется.)
Все игрушки, в которых внедрена луа — напрочь отказываются использовать больше одного ядра. Даже если сам движок игры поддерживает многоядерные архитектуры? Чем можно объяснить? Ленью разрабов?
Сразу приведу пример: NWN II (только 1 ядро), GarrysMod (на движе Half-Life 2 Ep2, который поддерживает до 4 ядер).
В отличие от «некоторых других» динамических языков, в Луа можно параллельно работать одновременно с несколькими стейтами в одном процессе.
Если нужно организовать параллельную работу логики на Луа, обычно создаётся по стейту на поток и организуется механизм обмена данными между стейтами. Например, налаживается система посылки сообщений между потоками или данные просто расшариваются тем или иным способом между стейтами с обеспечением синхронизации доступа кодом движка.
Почему разработчики отдельных игр пренебрегают такой возможностью мне сказать сложно. Может быть считают, что овчинка не стоит выделки, и игровая логика отлично будет работать и на одном ядре…
Скорее время пересылки данных между стейтами больше времени обработки микроскриптов, которые предварительно скомпилированы. 100% знаю, что в том же гаррис моде скорость работы Lua очень критична, так как от неё зависит два внутренних языка программирования + все-все добавленные обьекты и физические игрушки.
Хм, хотя в том же крайсисе луа отвечает за все скрипты, и при этом многопоточна. С другой стороны, от поддержки системных потоков самим языком хуже явно не станет, другое дело что внедрить подобное, не нарушив идеологию языка (и желаний разработчиков) — весьма и всемьса сложно.
Куда уж быстрей-то? Есть подозрение, что без JIT-а сильно быстрее уже не получится. А с JIT-ом — см. LuaJIT 2, в среднем всего в 2.37 раза медленнее C++. 5.2, конечно, пока LuaJIT не поддерживает, но ближе к релизу, скорее всего, будет.
Если говорить про стандартную реализацию 5.2, то, говорят, стало где-то чуть медленнее, где-то чуть быстрее. Существенной разницы с 5.1 нет.
ну понятно что быстрей c jit :)
я на луа использовал для lua_newthread, вот у меня там еще проблема была что надо переменные в скриптах как local обновлять. а то они между thread'ами шарились…
но как понял это типа не баг а фича
Ненадёжный код нужно помещать в песочницу. (По-хорошему ещё нужно ограничивать память через lua_setallocf и время выполнения через debug.sethook, этого по ссылке нет.)
Если нужно только перехватывать «нелегальные» глобальные переменные (а это полезно делать всегда, не только в песочнице), то нужно повесить на глобальное окружение (это же табличка на самом деле) хитрую метатаблицу, которая будет в __index и __newindex перехватывать обращения и проверять их.
См. etc/script.lua в луашном дистрибутиве. (Здесь — версия, которой я пользуюсь)
Что можно ожидать от Луа 5.2?