Вообще, очень жаль, что Эсперанто не стал популярен как-раз для вот такого международного общения. А ведь новые языки программирования мы не ленимся и учим, учим… правда, за ними стоят Гуглы-Майкрософты…
Не удивлюсь, если кто-нибудь тут приложит картинку про 'надцать' стандартов и необходимость в новом )))
Лучше NgX+mod_lua (кстати, в последней версии NgX научился в shared-модули) :)
Да так и попроще, на мой взгляд. Голосую за то, чтобы nginx вобрал в себя этот модуль и он был сразу "из коробки"
Ну и корутины работают (хотя я их не осилил :())
Если говорить о сопрограммах, доступных изнутри Lua, то я до сих пор не знаю, есть ли профит для обычного приложения в них. Например, в представленном фреймворке можно было бы каждый презентер сунуть в отдельную сопрограмму, но смысл…? Пока выполняется сопрограмма, основная программа-то стоит. Конечно, если скачивать файлы, или ещё что-то делать, "общаясь" с другими серверами, то выигрыш будет, а вот в обычном случае?
mod_lua я вообще не смотрел(только догадывался о его существовании). Apache для меня это такой вымирающий динозавр, который все никак не может отойти в мир иной.
Моя идея была в том, что этот динозавр стоит на большинстве обычных хостингов, и если они с популярной нынче версии 2.2 перейдут на 2.4, то подключение mod_lua вообще не должно вызывать никаких затруднений. Мало того, такие хостеры должны были бы популяризовать Lua, т.к. сайт под его управлением не будет давать большую нагрузку, а значит, можно разместить больше сайтов на одном сервере и больше заработать. Но это ИМХО конечно, поскольку я сам не администратор, и нюансы хостеров не знаю.
PS я наткнулся на заметку «Хабр уже не торт» и решил написать комментарий, первый за много лет. :)
Лиха беда начало. А вообще, старые времена всегда "добрые", и трава тогда была зеленее. ))
В случае mod_lua есть разные варианты многопоточности, но по сути они все не такие красивые, как описаный выше вариант: нет возможности использовать одну lua-машину per-CPU для обработки параллельных запросов.
Какие варианты многопоточности считаете возможными и реальными?
Tarantool от ребят из мейл.ру очень любопытный: они скрестили ежа с ужом. Они сделали помесь между апп сервером и in-ram storage engine, который чертовски хорошо параллелится с помощью тех же самых корутин.
Сам не пробовал Тарантул, но мысль запилить что-то внутри него на Lua была.
Предкомпиляция в lua — это профанация. Это скорее обфускация. Выигрыш, как было замечено, только на больших файлах, благодаря уменьшенному размеру файла.
Позволю себе процитировать автора языка:
"Код в предкомпилированной форме не всегда меньше исходного кода, но он загружается быстрее"
Предкомпиляция маленьких файликов действительно часто давала файлы чуть большего размера, правда, существенной эту разницу назвать трудно.
Один из множества плюсов: использование легковесных lua корутин для многопоточности вместо создания нового lua state(по сути запуска отдельной lua машины) в apache/mod_lua.
Если не сложно, поделитесь опытом работы с Lua-корутинами.
Кстати да, когда мне приходилось писать на ассемблере, то его код по ширине был не велик, а вот высоты экрана реально не хватало (приходилось изменять текстовый режим). Какое отношение сторон у вашего монитора на видео? Вообще, этот момент по созданию удобной рабочей интересен, если будет время, напишите чуть подробней.
Полагаю, вы подразумеваете одностраничный сайт с внутренними ссылками. Можно сделать и так. Даже правильно сказать — именно так обычно и делается. Вполне распространённое решение, без сложностей, без заморочек. Если сравнивать с вариантом SSI-HTML, то тут главная разница в наличии страниц. Если не нужна многостраничность, то SSI-HTML вариант опускаем и забываем. Сравнивая же с SSI-XML, мы можем увидеть, что в конечном итоге и одностраничник и xml сразу отдают весь контент поисковому роботу. Т.е. если не считать отсутствия индексации в mail.ru, всё в принципе похоже.
При таком раскладе, если сайт должен быть совсем простой, обычный, то предпочтение и надо отдавать классическому html одностраничнику с внутренними ссылками — это и просто, и надёжно. Но если вы хотите реализовать разделы-подразделы, теги, может быть авторов, или ещё что-то в этом духе, то xml с xslt преобразованием могут пригодиться. Ну и момент с добавлением-удалением контента при xslt-трансформации тоже помнить будет не лишним (с точки зрения SEO).
Важно отметить, что то же самое при желании можно сделать с помощью JS. При этом конечно, количество фреймворков и величина сообщества JavaScript очень велики. Этот подход сейчас активно развивается. Так что я точно не против JS, мне просто интересно сравнить разные подходы. Например, одного и того же изменения страницы мы можем добиться и с применением JS, и с применением XSLT. Тогда вопрос — если результат одинаковый, то в чём собственно говоря, разница?
Разница в распространённости языка, в развитии его поддержки. Но если отодвинуть все холиварные сравнения, то остаётся только одно весомое противоречие подходов: декларативный у XSLT и императивный у JS (хотя можно на нём и функционально программировать). Императивный распространён, его понимают все, а декларативный редок. Но забывать его всё-же не стоит.
Согласен, вариант впихивания сайта в SSI инструкцию обычным никак не назовёшь. Но я удивлён, что такой вариант никто не использовал. Для эпохи активного использования инклюдов это было бы вполне актуальное решение — как минимум, для сателлитов, ну и для всяких сайтов-визиток и проч.
Название мне стало напоминать не безызвестный фильм Джуманджи.
Странно, но мне нравятся все вариации чтения названия, уже предложенные )
Осталось спросить, а что думают по этому поводу носители языка
он в конце говорит «джей», ну а с корпорацией добра спорить…
Пожалуй, спрячу от неокрепших умов )) Спс
А тестируете?
Не удивлюсь, если кто-нибудь тут приложит картинку про 'надцать' стандартов и необходимость в новом )))
Раз уж упомянули, то расскажите подробней об этом фреймворке.
Мне кажется, там есть что почерпнуть полезного.
Да так и попроще, на мой взгляд. Голосую за то, чтобы nginx вобрал в себя этот модуль и он был сразу "из коробки"
Если говорить о сопрограммах, доступных изнутри Lua, то я до сих пор не знаю, есть ли профит для обычного приложения в них. Например, в представленном фреймворке можно было бы каждый презентер сунуть в отдельную сопрограмму, но смысл…? Пока выполняется сопрограмма, основная программа-то стоит. Конечно, если скачивать файлы, или ещё что-то делать, "общаясь" с другими серверами, то выигрыш будет, а вот в обычном случае?
Моя идея была в том, что этот динозавр стоит на большинстве обычных хостингов, и если они с популярной нынче версии 2.2 перейдут на 2.4, то подключение mod_lua вообще не должно вызывать никаких затруднений. Мало того, такие хостеры должны были бы популяризовать Lua, т.к. сайт под его управлением не будет давать большую нагрузку, а значит, можно разместить больше сайтов на одном сервере и больше заработать. Но это ИМХО конечно, поскольку я сам не администратор, и нюансы хостеров не знаю.
Лиха беда начало. А вообще, старые времена всегда "добрые", и трава тогда была зеленее. ))
По поводу:
Какие варианты многопоточности считаете возможными и реальными?
Сам не пробовал Тарантул, но мысль запилить что-то внутри него на Lua была.
Позволю себе процитировать автора языка:
"Код в предкомпилированной форме не всегда меньше исходного кода, но он загружается быстрее"
Предкомпиляция маленьких файликов действительно часто давала файлы чуть большего размера, правда, существенной эту разницу назвать трудно.
Если не сложно, поделитесь опытом работы с Lua-корутинами.
При таком раскладе, если сайт должен быть совсем простой, обычный, то предпочтение и надо отдавать классическому html одностраничнику с внутренними ссылками — это и просто, и надёжно. Но если вы хотите реализовать разделы-подразделы, теги, может быть авторов, или ещё что-то в этом духе, то xml с xslt преобразованием могут пригодиться. Ну и момент с добавлением-удалением контента при xslt-трансформации тоже помнить будет не лишним (с точки зрения SEO).
Важно отметить, что то же самое при желании можно сделать с помощью JS. При этом конечно, количество фреймворков и величина сообщества JavaScript очень велики. Этот подход сейчас активно развивается. Так что я точно не против JS, мне просто интересно сравнить разные подходы. Например, одного и того же изменения страницы мы можем добиться и с применением JS, и с применением XSLT. Тогда вопрос — если результат одинаковый, то в чём собственно говоря, разница?
Разница в распространённости языка, в развитии его поддержки. Но если отодвинуть все холиварные сравнения, то остаётся только одно весомое противоречие подходов: декларативный у XSLT и императивный у JS (хотя можно на нём и функционально программировать). Императивный распространён, его понимают все, а декларативный редок. Но забывать его всё-же не стоит.
P.S. Не хотелось бы разжечь тут холивара