Кста, кто-то пробовал ноду запихать как встраиваемый яп, как луа

в какие-то плюсы или ещё куда-то?

Интересно а есть ли в этом смысл. Её интерпретатор медленно работает по сравнению с тем же луа, который еще и в байткод компилировать можно для ускорения интерпретации, а ещё есть luaJIT

Вот вот

хмм. надо будет потыкать. чёт я луа за всё время вообще обошёл стороной как-то

Это да, та же херня

Зачем все это, когда есть Java? 😁

Да зачем если есть машинный код в блокноте бумажном

Он очень быстрый, предварительно компилируемый и есть jit компилятор. Ориентированность на прототипы и доступ ко многим внутренним методам/объектам позволяет писать очень хороший код, реализовать наследование и многие плюшки из ООП

спасибо. обязательно добавлю себе в список. как раз есть необходимость переделать старые костыли на псевдоязыке на что-то удобоваримое

Главное - не начать как я, искать типизиацию для него.... Там много вариантов, 2-3 из них очень даже хороши и чуть похожи на TS для JS, но их развитие слишком медленное из-за маленького сообщения луакодеров

не, нужны как раз мелкие скрипты типа проверки на наличия числа в массиве и прочего. щас оно на подобие jsonschema с пачкой логики. поддерживать оное ад

Тогда идеально. Руби тоже хорош для такого, но это уже совсем другой разговор...

не, надо что-то простое как молоток. думал про луа раньше, но не хватило смелости его тащить. щас необходимость в нём, вижу, есть

Если не пользуешься LuaJIT, советую предварительно компилировать код. Тогда интерпретатор будет моментально исполнять выходной байткод компилятора

Посмотри TypeScriptToLua проект. Они написали компилятор ts в lua.

Представь количество бгов там, луа и сама по себе достаточно корявая, а тут еще и компилятор из ТСа

да, спс, понимаю, транспилеров много .тут в другом был вопрос

Ну ноду сложно, а вот deno можно (если быть точным, то deno-core). Он распространяется в виде crate. Но там не будет компилятора TS и какой-нибудь SWC придется присобачивать отдельно

А есть объективные бенчмарки, где видна разница?

О, товарищ админ, будешь как-то группу от спама защищать? А то минус 200 человек за одну ночь

Думаю есть, ведь не с проста всё сообщество твердит о его скорости, равной сишной. Ну и если подумать, то язык сам по себе не сложно устроен, ни во что другое не транспилириуется, компилятор выдаёт байткод и можно напрямую интерпретировать без компиляции. На глаз проверить если, то действительно заметно быстродействие. Уточню что луа имеет свою виртуальную машину, которая не сравнима с той же у джавы по скорости. Исходя из того что я давно читал и в целом проверял по мелочи, я считаю что луа очень быстрый язык. Думаю бенчмарки найти можно, но мне они не особо нужны. Если кто найдёт - поделитесь, интересно посмотреть

Нода не яп, а рантайм. Его можно встроить, если рассматривать ноду как application server, то это часто встречается

чем плохо то?

Нет, не буду. Потому что у меня прав нет Но выше была озвучена интесная идея с выставлением таймаута для сообщений. Давно понял, что чем больше ограничений, тем лучше (это проекция рабочих установок на реальность)

согласен, таймауты частично порешают проблему и повсят качество общения. Но от спамов в полной мере не спасут(

Какое сообщество? Сообщество луа? Тогда это необъективно Про несравнимость по скорости вм верю: жавовскую двадцать лет вылизывают, быстрее её вм, наверное, на данный момент невозможно сделать

В отличии от LLVM, JVM выгружает значения в стек, что явно проигрывает чистой работе регистров. Кроме того, JVM имеет обязательный сборщик мусора в то время, когда на LLVM к нему можно подключаться опционально. Луа в принципе язык-конструктор, в нем все минимально как в сишке и с каждым стандартом стараются урезать все больше излишней функциональности и библиотек, что делает его легковесным. По прочитанным мною сурсам, мне известно что JVM основана на общении со стеком и выполняется по принципу JIT. LLVM же работает по принципу SSA, что ближе к математическим абстракциям и заточено под анализ и оптимизацию. Это два совершенно разных подхода, один высокоуровневый, а другой машинный. За высокие абстракции всегда высокая плата и это нормально. JVM дает возможность интерпретации на всех поддерживаемых платформах, в то время как LLVM может выбросить нужный ассемблер под специфику платформы, что довольно круто (но все равно есть инструмент для интерпретации LLVM-байткода, хоть он и не особо нужный)

Почему ты привязываешь llvm к луа? У "стандартного" луа точно так же есть gc, и не самая быстрая vm А фронтэндов для llvm много, в том числе js

LLVM как вариант, дело в возможностях которые имеются, а не в том кто, что и к чему имеет причастие. Если брать так, то в целом луа планировался как учебный язык, созданный в рамках университета