LINUX.ORG.RU

Эра nodejs прошла?

Да она только началась. Хайп прошел, хипсторы уходят.

Машинное обучение (JS или Python)?

С/С++. На скриптоте просто биндинги, делать своё ml можешь хоть на луа.

На чем писать приятнее?

На чем привык/умеешь.

crutch_master ★★★★★ ()

Фреймворки совсем разного уровня.

Django мощный фреймворк «всё в одном» по типу ruby on rails. Express - легковесный фреймворк.

В js асинхронность врождённая, в django она пока по большей части ещё только в планах.

Из популярных питоновских фреймворков Flask находится примерно на одном уровне с Express. Но корректнее его будет сравнивать с aiohttp.

eternal_sorrow ★★★★★ ()
Последнее исправление: eternal_sorrow (всего исправлений: 1)
Ответ на: комментарий от anonymous

питон однопоточный.

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

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

anonymous ()
Ответ на: комментарий от anonymous

многопроцессовый

Высокая стоимость запуска очередного процесса-интерпретатора, высокая стоимость IPC между всеми процессами. Где-то эти минусы допустимы, а где-то нет.

anonymous ()
Ответ на: комментарий от anonymous

Из недавнего я youtube-dl спавнил в несколько потоков (экзешник). После замены потоков на процессы «в лоб» производительность выросла раза в 2. Да, я знаю что youtube-dl на питоне написан, дело было скорее в визуализации вывода каждого процесса. Т.е. где-то это сплошные плюсы. Отдельный привет передаю byobu — гадость ещё та. Сколько интерпретаторов питона было в этом всём? Довольно много.

anonymous ()
Ответ на: комментарий от anonymous

Ты не путай моду и моральное устаревание. async/await на дворе, каждая новая строка кода при использовании джанги превращается в легаси. Не говоря уже о том, что она вприципе омерзительна.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

моральное устаревание. async/await на дворе

Какой с них профит в веб-приложении? Посылать ответ до того, как пришёл запрос? Может wsgi-сервер не справляется с нагрузкой?

Нет, я тупо притащу это дерьмо в проект, чтобы когда я сбегу, кому-то досталось поддерживать две технологии вместо одной. Такое легаси от меня, чо.

Хипстота, как она есть.

anonymous ()
Ответ на: комментарий от anonymous

Это «дев лок-ин», нагородить кучу неподдерживаемых и по сути не нужных костылей, чтобы никто кроме тебя в этой куче не смог ориентироваться. Становишься незаменимым работником.

anonymous ()
Ответ на: комментарий от anonymous

Высокая стоимость запуска очередного процесса-интерпретатора, высокая стоимость IPC между всеми процессами.

Сейчас бы на тормозной скриптухе считать скорость ipc.

crutch_master ★★★★★ ()
Ответ на: комментарий от anonymous

API обычно ходит в бд, иногда общается с другими API, может держать long-poll, отправлять server-sent events или работать с веб-сокетами. Обезьянкам, которые умеют только html джангой рендеретить этого не понять, конечно. Но асинхрон, внезапно, очень нужен.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

API обычно ходит в бд, иногда общается с другими API,

Хипстота. У меня апи — это интерфейс между двумя системами. Он в бд не ходит и вообще сам по себе ничего не делает.

может держать long-poll

Костыли не нужны принципиально.

отправлять server-sent events или работать с веб-сокетами.

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

этого не понять, конечно.

Мне не понять, зачем ты постоянно тащишь всякое нинужно. Расскажи что-ли, что ты делаешь.

anonymous ()
Ответ на: комментарий от anonymous

У меня апи — это интерфейс между двумя системами

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

Нужно полутора вебсайтам

Нужны любым сайтам, которые обновляют какие-то данные в режиме live, например биржам.

Расскажи что-ли, что ты делаешь

Конкретно сейчас пишу сервис (не web), который анализирует события из нескольких очередей, ходит в бд и уведомляет другие сервисы. Сплошной I/O. Здесь бы посинхронней, да?

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

У меня апи — это интерфейс между двумя системами

до общеупотребимого сленга, это тупо.

Этот общеупотребимый сленг вылез, как прыщ, вслед за нодой. Эталон хипстототы.

Конкретно этот не переношу, тк противоречит собственному названию.

Нужно полутора вебсайтам

Нужны любым сайтам, которые обновляют какие-то данные в режиме live, например биржам.

А я что сказал?

Конкретно сейчас пишу сервис (не web), который анализирует события из нескольких очередей, ходит в бд и уведомляет другие сервисы. Сплошной I/O. Здесь бы посинхронней, да?

Ясно. Это, конечно, аргумент чтобы переписать веб на асинхронщине.

У меня этим nginx с uwsgi занимаются

Ты бредишь.

Вроде нет. Или nginx стал синхронно работать?

anonymous ()
Ответ на: комментарий от anonymous

А я что сказал?

Таких сайтов более чем дохрена.

Это, конечно, аргумент чтобы переписать веб на асинхронщине

Опять включаешь клоуна и передёргиваешь. Ты спросил чем занимаюсь я, а не аргументы в пользу веба (которые и так очевидны).

Вроде нет. Или nginx стал синхронно работать?

Значит даже не одупляешь. nginx ни коим образом не решает проблему тупых и бесполезных блокировок в твоём приложеинии.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

Таких сайтов более чем дохрена.

Другеих сайтов более чем более чем дохрена.

Опять включаешь клоуна и передёргиваешь. Ты спросил чем занимаюсь я, а не аргументы в пользу веба (которые и так очевидны).

Спросил и принял, что в твоём проекте оно оправдано, не бурчи.

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

Значит даже не одупляешь. nginx ни коим образом не решает проблему тупых и бесполезных блокировок в твоём приложеинии.

Во первых у меня в приложении нет проблемы тупых и бесполезных блокировок. Блокирующие сисколы придумали внезапно не просто так, а от того, что ты скедулер вынес из ядра в свой процесс, умнее ты не стал.

Во вторых я отвечал на конкретное высказывание. Ты уверен что сам одупляешь, чем занимается nginx?

anonymous ()
Ответ на: комментарий от anonymous

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

Чтоб не решать банальные вещи «специальным, написаным не на питоне, чтоб не жрал память на каждое соеденение, инструментом, отдельно от обычного веба».

Интересно, что за инструмент такой и на каком языке написан

spoonbob ()

Эра nodejs прошла?

В России еще не пришла. Может и не придет. Может гошечка всех победит

На чем писать приятнее?

koa.js. Намного лучше чем express заточена на async/await мидлевари. Более чистый синтаксис. В express намудрили с роутинг API

Вангую новую волну хайпа по ноде после того, как там стабилизируют modules. Вновь толпы восторженных хипстеров будут кричать про единый код на клиенте и сервере. А там и deno заматереет и бэкенды начнут разворачивать одной командой на сервере:

deno https://unpkg.com/browse/my_super_backend/index.ts

spoonbob ()
Ответ на: комментарий от spoonbob

Чтоб не решать банальные вещи

Эти «банальные» вещи подавляющему большинству веба нафиг не нужны. Вы мне предлагаете выкинуть кучу готового, известного, оттестированого кода, чтобы решать проблемы, которых тупо нет.

Интересно, что за инструмент такой и на каком языке написан

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

anonymous ()
Ответ на: комментарий от anonymous

Эти «банальные» вещи подавляющему большинству веба нафиг не нужны

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

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

MQTT это тема. Для чтения с сенсоров. Но там только pub/sub. RPC поверх pub/sub это неприятная история. Какой инструмент выберешь, если понадобится быстро обмениваться мелкими JSON-сообщениями в обе стороны?

spoonbob ()
Ответ на: комментарий от spoonbob

Какой инструмент выберешь, если понадобится быстро обмениваться мелкими JSON-сообщениями в обе стороны?

Мне такое не нужно было, да и вообще задача не ясна. От балды, на что-то типа rabbitmq бы посмотрел.

anonymous ()
Ответ на: комментарий от spoonbob

Ну вообще-то только одна новая, потому что для Питона и фронта уже и так команды разработки были до этого. Так и норм же использовать те инструменты там, где они реально нужны, а не юзать универсальную балалайку. Тем более что питон/js даже с использованием асинхронщины панацеей все равно не станет, так что почему б не заюзать, помимо питона/js, инструмент, который и в потоки умеет, и шустрее, и памяти жрет меньше.

А если речь шла вообще про только одну команду, которая знает js и пилит на нем и фронт, и бэк, и все подряд, то это вообще странная ситуация, потому что у фронтенд и бэкенд разработки, кроме языка программирования, общего мало. Сильно сомневаюсь, что фронт сможет пилить спокойно хайлоад-бэкенд, написанный на js, только потому, что он знает js.

dimuska139 ()