LINUX.ORG.RU

... или python(django)

aiohttp хватит всем.

vvn_black ★★★★★
()

И то и другое, внезапно

menangen ★★★★★
()

Ни то, ни другое, внезапно.

hippi90 ★★★★★
()

Машинное обучение

Внезапно: Scala.

bvn13 ★★★★★
()

Эра nodejs прошла?

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

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

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

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

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

crutch_master ★★★★★
()

Nodejs (express)

И на express ты не будешь ничего писать, а будешь делать что-то поверх express.

crutch_master ★★★★★
()

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

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

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

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

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

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

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

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

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

Не переживай, пенсионный возраст еще раза два поднимут, 3.9 точно успеешь заценить.

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

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

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

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

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

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

Где-то эти минусы допустимы, а где-то нет.

Буду рад примеру, где допустимо использовать cpython, но не ipc.

anonymous
()

Машинное обучение - питон потому что там больше всяких либ и всего такого

Если просто веб приложение или апи какое нибудь то нода

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

вот и хипстота набижала

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

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

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

WitcherGeralt ★★
()

Используй pyramid

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

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

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

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

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

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

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

anonymous
()

и то и другое или нахер из профессии /thread

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

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

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

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

Тогда уже Connexion. Впрочем, для ноды тоже oas-tools имеются, так что нафиг ваш пыхтон.

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

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

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

Посылать ответ до того, как пришёл запрос

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Deleted
()

Эра nodejs прошла?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В итоге два языка на бэке и один на фронте. Сформировали 3 команды разработки на пустом месте)

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

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

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

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

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

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

dimuska139 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.