Я не воспеваю идею писать все на одном языке :)
Я воспеваю идею писать 90% приложения на одном языке, а 10% — на голом Си.
«не туда и не сюда, но все еще можно сделать снизу C++» — я бы назвал это адекватным балансом между производительностью, удобством поддержки ПО и производительностью.
Это же вопрос вкуса. Мне нравится, когда сверху язык совсем совсем динамический, легкий, немногословный (камень в java, но без претензий), а все что требует оптимизации, делать сразу на самом низком уровне в Си.
Вам нравится, когда сразу баланс.
Могу пояснить, откуда вообще растут корни такого подхода.
Как правило, нужно сделать 5-10 прототипов разной направленности, протестить на пользователей, понять что развивать а что нет, а потом уже делать полноценный продакшн, но не переписывать с нуля, а вертикально развивать существующий. Для этого связка JS + C подходит отлично.
Если бы мне дали энтерпрайз банкинг я бы врят-ли писал его на JS, это не его задача.
Ну, свою волшебную кнопку я дать не могу — я писал свой фреймворк для личных задач, и там кодовая база работала как в одном так и в нескольких потоках.
Не возьмусь утверждать что включение таких расширений совсем не отразится на стандартных функциях, все таки либо вы изначально пишите однопоточный псевдосинхронный код, либо сразу учитываете, или подводите кодовую базу под многопоточность, это абсолютно нормально.
Под Lua я встречал:
http://lualanes.github.io/lanes/
Под JS я глубоко не копал этот вопрос, принцип у JS и Lua в плане C++ биндингов одинаковый, и мета методы схожие, я знаю что в JS можно провернуть похожий трюк, и встречал npm пакеты утверждающие что они этот трюк проворачивают. Возможно, готовой кнопки там нет, но ее можно сделать.
Я осиливал модель с сериализацией объектов и передачей между потоков. И классическую модель, когда объект просто общий на два потока. Многие разработчики расширений под Lua и JS осиливали обе этих моделей. Их решения известны, и даже используются в ряде проектов. Но они используются тогда, и только тогда, когда разработчик знает зачем ему нужна именно многопоточность в одном процессе с общими данными. В остальных случаях он масштабирует сразу процессы, и это масштабирование можно разнести не только на ядра, но и на разные серверы.
Многопоточность с общими данными — это как бы очень специфический кейс, нужный в 0.1% задач. В остальных случаях нам важнее иметь другую многопоточность — на уровне IO, а код должен синхронно обрабатывать таски, и параллелиться по процессам.
Тогда это претензии конкретно к Chrome, IE, Firefox, Safari и другим браузерам.
Javascript не виноват, что разработчики браузеров не хотят принимать на запуск байткод.
Ну про машинный код я еще могу понять логику, это непосредственный формат для процессора. И то, сначала код переводится в ассемблер, а уже потом в машинный код, так то.
В чем же разница подачи байт кода java машины или передачи javascript кода браузеру (мог бы он принимать javascript байт код напрямую, так бы и делали) мне сложно уловить.
Ну никто не спорит, что быстрый C\C++ код без динамических типизаций будет рвать любой язык с jit и динамической типизацией. Но это просто два уровня подхода.
Ну и в lua и node можно делать C++ расширения, если в каком-то месте нужно решить проблему производительности.
Другое дело что вам возможно просто не нравится концепция «скриптовый язык сверху, C++ снизу», а больше нравится концепт «не туда и не сюда, но все еще можно сделать снизу C++», как в Java\C#
Повторюсь, включить многопоточный рантайм не проблема как в серверном Lua так и в Javascript. Но его там не включают намеренно. Полагаете, из глупости и несерьезности?
Я вам еще помогу, а то по тредам либо JS, либо TS.
Есть еще замечательный Flow, у которого есть режим совместимости синтаксиса. Он анализирует JS код и дает статические проверки. Можно не покидая JS решить эту проблему.
У меня сильно больше 20 строк кода, и даже больше 2000 строк, и все еще сплошное удовольствие
Если конечно быть в теме, использовать es7-8, не делать лапшу, а писать псевдосинхронный код, ну то есть понимать инструмент и правильно его использовать.
Непосредственно nginx использует lua, на этой базе построен openresty. На этой базе успешно строят производительные игровые серверы.
Lua Jit по производительности практически на одном порядке с нативным C++ кодом (ну конечно мета магия и динамическая типизация делают свое дело, но и применяя виртуальное наследование и динамический диспатчинг с хеш таблицами на C++ будет такой же результат).
Что касается парадигмы однопоточной работы. Это именно парадигма, а не какой-то там недостаток, как утверждали в ветке выше. Во первых, как в Lua, так и в JS на node нет никакой проблемы сделать мультитреды прямо из Lua\JS. И там и там прекрасно работают C++ расширения. Но смысл парадигмы в том, чтобы управляющий поток был один. Это шардинг из коробки, он принуждает вас писать приложение так, чтобы потом шардить его на самом первом уровне.
Это возможность, в конце концов, установить ряд глобальных состояний, и быть уверенным, что другой поток его не потеряет, потому что поток один. Второй поток — второе состояние, отдельное и независимое. Для общих данных же можно использовать как расширение с мультипоточностью, так и шардинг, оставаясь в пределах одного потока на процесс.
Вы не поверите, но меня раздражает, когда люди без спроса снимают меня на улице, случайно или специально.
На телевидении все лица прохожих замазываются, и это не просто так.
И на самом деле все нормально — право на забвение всего лишь требует удаления из выдачи поисковых систем. Если это будет слишком сложно — можно добавить сверху критерий известности. Если Вася Пупкин просит удалить из сети фото улицы, где он мимо проходил, при этом данное фото не фигурирует практически нигде, ему допустимо отказать.
Но представьте такой невероятный исход. Васю фотографируют случайно вместе с каким-то зданием. Фото затем покупается интернет-журналом и выкладывается с статьей, которая становится вирусной, и при этом журналисты забыли замазать лицо Васи. В этом случае, совершенно справедливо для Васи требовать удаления фото из выдачи.
Я не переворачиваю задачу. То, что вы считаете, что понятие числа — это его значение — единственно адекватная и верная трактовка — это заблуждение. Вы правы, что это адекватный контекст для большинства людей, но тем не менее это всего лишь контекст. Считать меньшинство людей, которые совершенно спокойно видят много контекстов, и не возвышают один над другим, вместо того уточняя какой имелся ввиду — странными — странно для меня.
А что касается задумываний менеджера и системы которую надо переписывать с нуля, это как раз относилось к задаче.
Если мы будем решать задачу через суммы, а в будущем окажется, что нам все таки где-то нужна не только сумма, но и сам объект, который ее содержал до этого, возникнет новая задача, в которой таки придется сортировкой и перебором искать искомый объект (с вашей точки зрения новая задача). Но это вполне очевидный и обыденный кейс для меня — сразу узнать будущие кейсы и уточнить с менеджером более удачную реализацию, подходящую для дальнейших хотелок. Такие ситуации у меня на работе штатные, и не поверите — бывают и такие формулировки как в этой задаче, и именно со смыслом находить объект, чтобы потом как-то работать с статистикой по нему.
Вы сами придумали этот диалог.
— Надо слово или позицию? Какие еще метаданные к этому слову нужны?
— Только слово
— Ок, но если понадобится что-то еще, придется полностью переписать алгоритм с нуля.
И тут вдруг менеджер начинает действительно думать, а не понадобится ли что-то еще.
Если не понадобится, то
— Нет, только слово
— Ок.
Можете указать, где я хоть раз что-то додумывал? Я лишь поставил вопрос — есть такая трактовка, и гипотетически рассуждал в этом направлении.
Если проблема в этом, то наконец пожимаем руки, я рад что мы поняли друг друга.
Я воспеваю идею писать 90% приложения на одном языке, а 10% — на голом Си.
Это же вопрос вкуса. Мне нравится, когда сверху язык совсем совсем динамический, легкий, немногословный (камень в java, но без претензий), а все что требует оптимизации, делать сразу на самом низком уровне в Си.
Вам нравится, когда сразу баланс.
Могу пояснить, откуда вообще растут корни такого подхода.
Как правило, нужно сделать 5-10 прототипов разной направленности, протестить на пользователей, понять что развивать а что нет, а потом уже делать полноценный продакшн, но не переписывать с нуля, а вертикально развивать существующий. Для этого связка JS + C подходит отлично.
Если бы мне дали энтерпрайз банкинг я бы врят-ли писал его на JS, это не его задача.
Не возьмусь утверждать что включение таких расширений совсем не отразится на стандартных функциях, все таки либо вы изначально пишите однопоточный псевдосинхронный код, либо сразу учитываете, или подводите кодовую базу под многопоточность, это абсолютно нормально.
Под Lua я встречал:
http://lualanes.github.io/lanes/
Под JS я глубоко не копал этот вопрос, принцип у JS и Lua в плане C++ биндингов одинаковый, и мета методы схожие, я знаю что в JS можно провернуть похожий трюк, и встречал npm пакеты утверждающие что они этот трюк проворачивают. Возможно, готовой кнопки там нет, но ее можно сделать.
Многопоточность с общими данными — это как бы очень специфический кейс, нужный в 0.1% задач. В остальных случаях нам важнее иметь другую многопоточность — на уровне IO, а код должен синхронно обрабатывать таски, и параллелиться по процессам.
Javascript не виноват, что разработчики браузеров не хотят принимать на запуск байткод.
В чем же разница подачи байт кода java машины или передачи javascript кода браузеру (мог бы он принимать javascript байт код напрямую, так бы и делали) мне сложно уловить.
Ну и в lua и node можно делать C++ расширения, если в каком-то месте нужно решить проблему производительности.
Другое дело что вам возможно просто не нравится концепция «скриптовый язык сверху, C++ снизу», а больше нравится концепт «не туда и не сюда, но все еще можно сделать снизу C++», как в Java\C#
Есть еще замечательный Flow, у которого есть режим совместимости синтаксиса. Он анализирует JS код и дает статические проверки. Можно не покидая JS решить эту проблему.
Если конечно быть в теме, использовать es7-8, не делать лапшу, а писать псевдосинхронный код, ну то есть понимать инструмент и правильно его использовать.
Непосредственно nginx использует lua, на этой базе построен openresty. На этой базе успешно строят производительные игровые серверы.
Lua Jit по производительности практически на одном порядке с нативным C++ кодом (ну конечно мета магия и динамическая типизация делают свое дело, но и применяя виртуальное наследование и динамический диспатчинг с хеш таблицами на C++ будет такой же результат).
Что касается парадигмы однопоточной работы. Это именно парадигма, а не какой-то там недостаток, как утверждали в ветке выше. Во первых, как в Lua, так и в JS на node нет никакой проблемы сделать мультитреды прямо из Lua\JS. И там и там прекрасно работают C++ расширения. Но смысл парадигмы в том, чтобы управляющий поток был один. Это шардинг из коробки, он принуждает вас писать приложение так, чтобы потом шардить его на самом первом уровне.
Это возможность, в конце концов, установить ряд глобальных состояний, и быть уверенным, что другой поток его не потеряет, потому что поток один. Второй поток — второе состояние, отдельное и независимое. Для общих данных же можно использовать как расширение с мультипоточностью, так и шардинг, оставаясь в пределах одного потока на процесс.
На телевидении все лица прохожих замазываются, и это не просто так.
И на самом деле все нормально — право на забвение всего лишь требует удаления из выдачи поисковых систем. Если это будет слишком сложно — можно добавить сверху критерий известности. Если Вася Пупкин просит удалить из сети фото улицы, где он мимо проходил, при этом данное фото не фигурирует практически нигде, ему допустимо отказать.
Но представьте такой невероятный исход. Васю фотографируют случайно вместе с каким-то зданием. Фото затем покупается интернет-журналом и выкладывается с статьей, которая становится вирусной, и при этом журналисты забыли замазать лицо Васи. В этом случае, совершенно справедливо для Васи требовать удаления фото из выдачи.
У вас на руках статистика и подводные камни. На вашу статью можно будет ссылаться при общении с UX\UI дизайнерами.
А с моей работой все в порядке.
А что касается задумываний менеджера и системы которую надо переписывать с нуля, это как раз относилось к задаче.
Если мы будем решать задачу через суммы, а в будущем окажется, что нам все таки где-то нужна не только сумма, но и сам объект, который ее содержал до этого, возникнет новая задача, в которой таки придется сортировкой и перебором искать искомый объект (с вашей точки зрения новая задача). Но это вполне очевидный и обыденный кейс для меня — сразу узнать будущие кейсы и уточнить с менеджером более удачную реализацию, подходящую для дальнейших хотелок. Такие ситуации у меня на работе штатные, и не поверите — бывают и такие формулировки как в этой задаче, и именно со смыслом находить объект, чтобы потом как-то работать с статистикой по нему.
— Надо слово или позицию? Какие еще метаданные к этому слову нужны?
— Только слово
— Ок, но если понадобится что-то еще, придется полностью переписать алгоритм с нуля.
И тут вдруг менеджер начинает действительно думать, а не понадобится ли что-то еще.
Если не понадобится, то
— Нет, только слово
— Ок.
Если проблема в этом, то наконец пожимаем руки, я рад что мы поняли друг друга.