в этом вся прелесть!

Это кошмар.

она волшебство делает

Это чудовищный кошмар. Я покупал многоядерный сервер чтобы запустить на нём одно единственное приложение, которое должно быть ОЧЕНЬ быстрым. И жрать десятки гигабайт памяти. И если где-то упал поток - мне проще его перезагрузить, но чтобы остальные потоки остались живы, даже если они обрабатываются последние пол часа. Какой мне смысл от такого сервера, если только одно ядро задействованно?

это от задачи зависит: 1) нода мне нужна для сборщика файлов - потому что npm такой богат 2) импорт с чужих сайтов на наш стартапчик - как бы луа грузила 100 страниц параллельно? 3) все, больше она не пригождалась особо

Нет, можно запустить несколько нод одновременно: главная управляющая нода, которая пайпами или сокетами общается с другими нодами, загружает их задачами и собирает решения, отправляя назад собранное. Но блин.

никто и не говорит, что сервер на ноде - это умно

Сервер на ноде - единственное для чего я бы ставил ноду (((

> Нет, можно запустить несколько нод одновременно: согласись, код вырос бы раз в 10 и отлаживать импорт - был бы ад

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

> Нет, можно запустить несколько нод одновременно: согласись, код вырос бы раз в 10 и отлаживать импорт - был бы ад

Кстати нет. Код вырос бы ровно на две функции: send/receive через пайпы/сокеты.

Там не механизмы защиты от гонки данных, там таких понятий не существует, ибо волшебство

Хех, пример эвент-лупа применительно к node от хабры. Почти то же что я написал.

А, нода умеет в дочерние процессы. Уже чуть лучше. И память разделённая, и процессоров много.

В общем, на твоём месте, я бы почитал а) много хвалебной фигни б) много нейтральной фигни в) много хейтерствующей фигни Выделил бы всё ценное, и проверил бы всю магию на предмет магичности. Вот тебе пример хейтерства на ноду, и я даже понимаю почему: https://habrahabr.ru/post/129640/

у меня тут война с реактом, но потом почитаю. Срать на чье-то мнение)) — верный подход, главное что нода решает задачи, которые другие языки не могут, точнее могут, но разобраться долго и трудно

хлелебная фигня, нейтральная, — фигня же

http://stackoverflow.com/questions/5795419/lua-socket-asynchronous-calls

я это имею в виду

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

то что на ноде пара-тройка строчек - на луа выливается в малопонятную длинную простыню

Asm это ассамблер?)

блин. Ну не надо тут игры unless it's not written on Lua.

Го запилим альтернативный клиент ингресса на луа. И пофигу на тос)

Потому что ты больше пишешь на js чем на луа. И знаешь как решать проблемы методами js, а не луа. Или просто любитель использовать библиотеки: один вызов сторонне-библиотечной функции может быть внутри пятью гигабайтами малопонятной простыни, которую ты не писал, потому что её написали за тебя. Да, асм это ассамблер )))

а как же твой пример jquery/react? вот это я понимаю ущербность, хоть на 5ГБ, но 50-100кб непонятно чего, которое жрет неизвестно сколько

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

Это если уметь писать на асме.

вне браузера не важно сколько, главное что время твоей жизни экономит

Не факт, что на асме получится быстрее, чем на Си с -O3

скрин кидал - я атомом не пользовался, а на скрине Снусмумрика вроде как атом?

Конечно )) А на ноде можно писать если уметь писать на js. А на луа можно писать если уметь писать на луа. Асм прост. Его можно освоить за вечер, и остаток жизни потратить на изобретение всего того чем мы пользуемся в ноде и луа. На асме будет работать быстрее, если мы умнее тех кто писал сишный компилятор.

> Асм прост. Его можно освоить за вечер, и остаток жизни потратить на изобретение всего того чем мы пользуемся в ноде и луа. Изобрести ноду и луа?

Зато в десятки и сотни тысяч раз быстрее ))) Правда, количество фич будет урезано, и мы будем компилить js в полноценный машинный код.

Го запилим альтернативный клиент ингресса на луа. И пофигу на тос)

Го запилим альтернативный клиент ингресса на тасме. Там макросы есть!

Performance Comparison C vs. Lua vs. LuaJIT vs. Java | Elmar Klausmeier's Weblog https://eklausmeier.wordpress.com/2016/04/05/performance-comparison-c-vs-lua-vs-luajit-vs-java/

К слову

Го запилим альтернативный клиент ингресса на тасме. Там макросы есть!

В crystal макросы круче

c vs asm дайте лучше

не могу найти

К слову

Устаревшая информация. jit 2.1.0 получил резкий буст. Правда, сейчас в бете.

Ну да, и я все равно не вижу десятков и сотен тысяч раз

Ну, я утрирую, конечно. Но не очень сильно. Плюс я про изобретение luaJit на асме! Шоб прям супер-пупер, ни одной лишней процессорной команды!

давайте лучше создавать для луа то, чего не хватает, скорости хватает, никто не жалуется

И все равно скорее всего получится менее оптимальный код, чем сгенерированный шлангом каким-нибудь)

Мне в ванильной не хватает скорости. Надоело двое суток ждать пока банк не зальётся данными. И микросервисы мои хавают не 1.5млн запросов в секунду, а всего лишь 30-40к. Слоупочная ванильная луа.

зачем нужна ванильная?

Это ж какое самомнение надо иметь, чтоб считать себя умнее разработчиков компилятора, которые вложили в оптимизацию тысячи человекочасов))

Ну, у меня на работе, в базе данных, сидит ванильная. А разрабам базы данных лень портировать всё под жыт.

портировать?

Переписать куски ядра под жыт. Там много переписывать. Инфа сотка. И совместимость с частью старых скриптов поедет: например, lanes-многопоточка. Некоторые библиотеки работают только конкретной версией на жыте, а скриптов - не одна сотня мегабайт, и все нужны. Тут разработка сильно не один год длится.

Это ж какое самомнение надо иметь, чтоб считать себя умнее разработчиков компилятора, которые вложили в оптимизацию тысячи человекочасов))

Человекочасы - это миф. Производительность просто хорошего и отличного программистов различаются более чем в десять раз, а в сравнении отличного со средним - в тридцать-сорок. Но ты смотри: те кто писал компилятор такие умные и крутые потому, что они сделали компилятор универсальным. Для задач очень разного рода. Он не заточен под что-то одно конкретное, иначе был бы перекос в скорости где-то ещё. Если заточить приложулю на асме под одну конкретную задачу (например луажыт))) - это в любом случае будет быстрее чем труд неимоверно умных людей, которые в тысячу раз умнее меня. Просто потому что универсальность = снижение скорости.

И да, предложение "переписать всё на асм" было шутливым. Это я на всякий случай. Всё таки нет времени.

Мне вот никто не запрещает считать себя отличным программистом (я так, правда, не думаю), и вот один интересный факт: так себе чувак сделает быстрее, чем отличный ленивый программист

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

Ох, отличный программист не может быть ленивым. Это взаимоисключающие понятия. Коэффициент отличности = "навыки" * "активность"

> Мне вот никто не запрещает считать себя отличным программистом Я запрещаю )) Лучше считай меня отличным программистом, мне будет чуть-чуть приятно )) Боюсь таки что большая часть основных вещей (особенно традиционно-классических) сделаны отличными программистами.

Слушай, как часто ты строишь математические модели своего ПО? Ну, или хотя бы UML-диаграммы, и вообще, сначала рисуешь на бумажке, там же оптимизируешь и только потом - пишешь программку? Нет, это не критерий отличности и способ потешить чсв, мне просто интересно.

Пишу код, просто надо понятный код писать, и тогда все хорошо

Как критерий отличности - гитхаб с человеко-полезными хорошими вещами

Ну, у меня в голове не помещается больше чем три-четыре объекта. Как только появляется взаимодействие сложнее чем три-четыре штуки - рисую и строю матмодели, чтобы хотя бы не забыть, и заодно проверить гипотезу, что "эта фигня не упадёт на высокой загрузке".

два кофе

этому программисту

Когда читаешь книгу - видишь не буквы, а людей, пейзажи, и такое всякое, а когда читаешь код - видишь как раз эти модели, эти взаимосвязи, как живой организм

Их много, знаешь ли : 3 За всеми не уследишь. И каждый кусок не оттестируешь. Просто нарисовать и закодить быстрее, чем переключаясь между блоками вспоминать, написал ли ты эту штуку или это только предстоит.

модульность.

Да, модульность. Переключаясь между блоками = переключаясь между модулями. Только если ты не нарисовал и не задокументировал всё возможное - до тебя вдруг доходит: "Надо в вызываемом тут модуле дописать эту фигню, пойду допишу чтобы не забыть", "Фу, чёт медленно, надо переписать нафиг" и "Хм, я дописал вызываемую тут фигню, перед тем как переключитья сюда и всё переписывать?" Я пишу понятно если рисую. Потому что не переключаясь между контекстами, имею возможность делать сразу законченные вещи, которые гарантированно работают сразу и правильно. Юнит-тестирование тоже хорошо, потому что ты сразу знаешь весь спектр работ модуля: он не будет дописываться в процессе, ибо документирован, и его матмодель показывает что всё не так плохо как могло бы быть. Попробуй это дело, когда начнёшь возиться с чем-то действительно большим, а не "три строчки на ноде".

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

Это твой аналог switch-case?

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

for i = 1, #arg do for j = 1, #cas do вот же в коде

таки сори, есть pairs

Только после систематизации. Посмотри, систематизация - переделывает строковые ключи в целочисленные.

будет в следующей версии

Этот вариант свитч-кейса технически хуже чем a = a and b or c and d, потому что отсутствуют великолепные ленивые вычисления, и весь кейс вычисляется единомоментно. Но возможно проще для использования/восприятия непривыкшему человеку.

Имхо, кстати, забавнее такой вариант: handler = {} function handler['yo'](data, ip, port) ... end function handler['chiwawa'](data, ip, port) ... end function handler['ahahahahaha'](data, msg) ... end for i, v in ipairs(msgs) do local type = v.type handler[type](v.data, v.ip, v.port) end Чот такое. Типа, 100500 обработчиков под разнотипне сообщения, в зависимости от внешних обстоятельств. В данном случае - в зависимости от типа. Тот же свитч-кейс. Правда, нельзя пихать логические выражения. Этой же фигнёй сокращается десять тысяч if-then-else'оф. Вроде бы простая методика, но эффективная. И можно динамически добавлять новые if-else, заполняя ключи таблички.

О, кстати, ещё больше запитонил свою ООП-либу, и обрезал мелочи. Довольно долго ей пользовался, и прилично думал о краткости и комфорте пользования. Сейчас оно близко к совершенству. https://pastebin.com/9eDU94Ua Референс внутре.

локальный smt быстрее глобального, проверил, аж на 7 мс за 1000000000 итераций

Ох, какой ты милый :3 Тут для сокращения объёма текста, расслабься. Лучше восхитись краткостью и ясностью вкупе с мощью и комфортом.

я и восхищаюсь!

наследовать то тут как?

В примере написано. Наследуем класс Bar от Foo.