Вхід і реєстрація
Розробка · 12 жовтня 2016, 21:13 7544
Alexander Baranetsky, Software engineer

Переход на NodeJS

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Добрый день!

Стала задача писать тяжело нагруженные микросервисы. Задумался о выборе NodeJS. Как альтернативе JAVA, C++.

Требования к процессу:
1. Каждый HTTP запрос обрабатывается в отдельном физическом потоке.
2. Механизмы синхронизации.
3. Наличие фреймворка. Поддержка полноценного MVC механизма из коробки. С базой и html шаблонами.

Посмотрел в инете посты про «ноду» и чет меня она меня не вдохновляет.

Вопрос: сможет ли NodeJS удовлетворить 3 выше описанных требования, и каким образом (какие инструменты юзать)?

UPDATE:
Прочитав множетство околохоливарных постов. Для себя выбрал инструментом JAVA(если конечно дело дойдет до переписания).
Также можно обратить внимание на Go, Python языки. NodeJS как то расстроила меня еще больше... Незнаю почему...

Теми: node.js
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Aliaksandr Valialkin программист в VictoriaMetrics 02.11.2016 10:30

Вот картинка, характеризующая всю суть node.js — image.prntscr.com/...d4590a6c539a7a9c8c859.png

Відповісти
Підтримати
Artyom Krivokrisenko 02.11.2016 10:59

Это картинка, характеризующая всю суть гоубоев — они умудряются засунуть JPEG артефакты в PNG картинку.

Відповісти
Підтримати
Aliaksandr Valialkin
Костя Третяк 02.11.2016 15:52

Ну а аналізувати побачене ви не осилили?

По-перше, сам підбір пошукових термінів туповатий, навіть просто щоб створити «прикольну картинку»?

По-друге, для приколу можна було б і більше постаратись, і трохи пошевелити мізками, бо «Quality software» падав вниз явно під більшим кутом, ще до початку пошуків слова «Node.js», а з появою Node.js якість розробки стала вищою =).

Це такий рівень приколів у Гоуферів? Слабенько-слабенько, черговий раз пересвідчуюсь.

Відповісти
Підтримати
Aliaksandr Valialkin
Юрий Ярош developer в bitsnap 18.10.2016 13:11

1. Ужс. Disruptor или multireactor в помощь.
2. Paxos/Raft и CRDT ?
3. Это CQRS-ES — берём Rx и пилим что надо. MVC... ну мы ж уже не в 2008ом.

Если действительно хотите лепить микросервисы — надо влазить в событейно-ориентированные подходы и реактивные расширения (reactive extensions RxJava Rx.js RxPy etc) и использовать эффективные транспорты типа grpc или tchannel.

Быстрее всего вы не будете готовить это дело правильно ставя подобные вопросы.
Кристиан Поста со мной в этом тоже согласен blog.christianposta.com/...oing-to-do-microservices

Відповісти
Підтримати
Богдан PickupSoul 18.10.2016 00:16

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

Відповісти
Підтримати
ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 17.10.2016 22:11

Кстати, недавно заходил в Вавилон (трц в Днепре), там на вылетевшем терминале был исходник на Ноде, так вот в одном файле было что то 3000 — 4000 строк кода с какими то обработчиками запросов по 300-500 строк кода каждый.

А теперь вопрос к комьюнити, — это у кого то руки из жоп* растут или Нода виновата (ну типа на ней так принято писать).

Відповісти
Підтримати
Vitaliy Lebedev Backend Developer в Leia Inc 18.10.2016 09:54

С каких это пор «на ней так принято писать» == «нода виновата»?

Відповісти
Підтримати
ScorpZ Lapshov
Глеб Кузнецов Independent contractor 18.10.2016 14:31

нода это как пхп4 — нет вменяемого ооп, неймспейсов, автоподгрузки, в общем тех инструментов, которые бы тонко намекали разработчику, что лепить код в один файл НЕ НУЖНО.

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

вот и получается, что нода не виновата, просто

у кого то руки из жоп* растут
поэтому
на ней так принято писать
Відповісти
Підтримати
ScorpZ Lapshov
Olexandr Vovchok 18.10.2016 14:33

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

Відповісти
Підтримати
Глеб Кузнецов
Глеб Кузнецов Independent contractor 18.10.2016 14:51
Когда то и пхпсты радовались отсутствию ООП, типа все просто было, для народа.
тогда и веб-приложения это был набор страниц, где суть пхп сводилась к тому, чтоб взять GET-параметр, дернуть по нему статью из субд да шапку с футером подставить.
Так если в ноде или джаваскрипте введут синтаксис на уровне даже того же пхп то у многих фанатов забомбит.
да тут много факторов, поскольку js позиционируется как язык для фронтенда и бекенда одновременно, то нельзя просто взять и запилить что-то хорошее хотя бы в node.js, не тронув фронтенд.
а фронтенд это лебедь, рак и щука. у нас requestFullscreen() уже минимум пару лет, а до сих пор экспериментальный, для каждого браузера функция с разным префиксом. что уж говорить о поддержке нового стандарта языка. на это уйдут годы.
Відповісти
Підтримати
Olexandr Vovchok
Nikita Galkin Software Engineer, System Architect, Node.js Tech Speaker 17.10.2016 13:56

Александр, у вас не верное понимание микросервиса.

Відповісти
Підтримати
Alexander Baranetsky Software engineer 17.10.2016 19:39

Возможно, а что я понимаю «не так»? )

Відповісти
Підтримати
Nikita Galkin
Nikita Galkin Software Engineer, System Architect, Node.js Tech Speaker 17.10.2016 22:15

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

В моей работе микросервис делает что-то одно. Например, у вас один репозиторий это статика для UI которая раздается Nginx-ом, а второй репозиторий содержить REST API микросервис которые берет данные из MongoDB и кладет в очередь задачи по отправки емейлов, третий микросервис слушает очередь и заполняет шаблоны емейлов и отправляет их, четвертый обеспечивает аунтификацию, пятый генерирует отчеты и кладется в очередь для отправки емейлов, шестой реализует WebSocket для оповещения пользователей в реалтайм, седьмой сервис выполняет мониторинг, восьмой сервис является адаптер для какой-то внешней системе, и т.д.

Зачем такие сложности? Чтобы мастабироваться и оперативно устранять ботлнеки. Будут ли у вас большие нагрузки, распределенные команды, чтобы юзать микросервисы? Мне почему-то кажется что нет.

Відповісти
Підтримати
Alexander Baranetsky
Alexander Baranetsky Software engineer 17.10.2016 22:20

Спасибо, я понял Вас. Микросервис о котором я говорю. Отдает одну и только одну html страницу.

Відповісти
Підтримати
Nikita Galkin
Nikita Galkin Software Engineer, System Architect, Node.js Tech Speaker 17.10.2016 22:35

Может стоит начать не с требований к инструменту, а с формулировки задачи? Вдруг форум посоветует другой путь ее решения?

Відповісти
Підтримати
Alexander Baranetsky
Alexander Baranetsky Software engineer 17.10.2016 22:37

NDA)
Задача — на одной машине обрабатывать ~3к qps. При этом нужно удерживать существенный блок важных данных(которые обновляются при каждом запросе) в консистентном состоянии.

Как бы я не оптимизировал код на PHP опустится ниже 50ms для response не получается ((( . И скинуть нагрузки с CPU...

Відповісти
Підтримати
Nikita Galkin
Olexandr Vovchok 17.10.2016 22:47

Да потому что PHP тупо не предназначен для такого. Оставье этого парня в покое и наедине с вордпресом! Диву даешься до чего доходят люди в фанатизме и нежелании изучить что то еще. Будут лепить кучу костылей вместо юзания подходящей стабильной технологии.

Відповісти
Підтримати
Alexander Baranetsky
Alexander Baranetsky Software engineer 17.10.2016 22:51
фанатизме и нежелании изучить что то еще.
Читайте внимательно топик, пожалуйста. Про ноду я спрашиваю как альтернативу Java, C++ :)
Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 17.10.2016 22:54

Ну ладно. Просто я так, в общем. Начитался как с пхп извращаются просто потому что не хотят выучить другое, всякие костыли, пытаются делать его не умирающим а как демоном, который там помирает от обжирательства памяти, и что там еще. В то время есть куча других норм технологий. Особенно лол у меня вызывает когда делают РЕСТ АПИ на медленном ларавеле. Даже не на его меньшем брате люмене а на этом самом прожорливом фреймворке среди пхп. Еще б на цмске делали...

Казалось бы программисты одни из самых умных людей. А фиг там, те же блондинки с айфоном.

Відповісти
Підтримати
Alexander Baranetsky
Костя Третяк 18.10.2016 11:11
Как бы я не оптимизировал код на PHP опустится ниже 50ms для response не получается (((

І який ви висновок із цього робите? Що 3k req/s у вас не вийде забезпечити? PHP — багатопоточна, у сьомій версії вона досить ефективно використовує opcache із shared memory, щоправда код повинен бути написаний на ООП для більш ефективного використання цих можливостей. Оцю вашу мету «3k req/s» думаю досить реально зробити на PHP7, навіть на одній машині.

Ну а мінус PHP7 в порівнянні з Node.js звичайно ж в тому, що якраз через багатопоточність використовується значно більше пам’яті, при тому ще й PHP7 помітно повільніша (при умові використання для Node.js багатьох ядер чи багатьох машин)...

Не знаю як кому, мені не було вже аж сильно складно перейти із PHP на Node.js, використовуючи TypeScript, Promise, asyn/await... Десь через три тижні практики, вже писав код, який навіть не валить процес Node.js =), і знав де копати, якщо він все ж по-якійсь причині таки падає...

До речі, про па́дання — це одне із самих незвичних моментів. Тобто програмуючи на Node.js ви можете ненароком... наприклад, написати щось таке безневинне (як для PHP)

req.body

і якщо у об’єкта req не буде властивості body, то усьо — процес упаде, Node.js відчитається про цю помилку, причому самостійно не перезапустить процес, і ваш веб-сервак буде лежати аж поки ви вручну його не перезапустите, ну або не зробить це за вас якийсь із менеджерів процесів, типу pm2, forever... (це сторонні, нерідні модулі ноди).

Відповісти
Підтримати
Alexander Baranetsky
Olexandr Vovchok 18.10.2016 13:14
PHP — багатопоточна

Це я десь трохи проспав чи ви пишете повну дурницю?

і якщо у об’єкта req не буде властивості body, то усьо — процес упаде

Жах. Важко пхпшникам сприймати таке, розумію.

Відповісти
Підтримати
Костя Третяк
Костя Третяк 18.10.2016 13:21

Можливо й дурницю пишу, бо не особливо розрізняю потоки й процеси. На скільки я знаю, кожен запит PHP обробляється в окремому процесі. З іншого боку є ще fpm, який, здається, запускає по одному процесу на ядро... Хз, може я тут щось плутаю.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 13:32

Ну от. В процесі а не потоці. І це якраз і є найбільшим недостатком пхп. Не перевагою як ви собі думаєте. Бо ресурси дуже сильно забиваються. PHP створений щоб померати. Він не живе як програма, а тупо перезапускається під час кожного запиту і помирає після обробки. Тому придумовують різні костилі де в інших мовах все робиться елементарно а не потребує такої кучі ресурсів на обробку кожного запиту. Це типу як джава апп який бере значну кількість ресурсів для запуску(оперативки), але він залишається працювати і обробляти усі запити не перезапускаючи себе. Тобто щоб пхп обробив 10 одномоментних запитів йому потрібно х10 використовуваних ресурсів, коли джава апу достатньо х1, ну і там якась невелика частина ще ресурсів на саму обробку.

Відповісти
Підтримати
Костя Третяк
Andriy Maletsky 18.10.2016 14:02

Ну взагалі ти проспав. Але, дивлячись на їхній багтрекер, складається враження, шо потоки в пхп — це просто ше один ефектний спосіб померти.

Відповісти
Підтримати
Olexandr Vovchok
Глеб Кузнецов Independent contractor 18.10.2016 14:20

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

Відповісти
Підтримати
Andriy Maletsky
Глеб Кузнецов Independent contractor 18.10.2016 14:15
Це я десь трохи проспав чи ви пишете повну дурницю?
C добрым утром.
github.com/krakjoe/pthreads

а еще можно поднять пулл процессов, например, php.net/...u/function.pcntl-fork.php

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 14:22

Да здравствуют новые костыли на пхп. Будем кушать ежей, но писать на пхп не перестанем!

Відповісти
Підтримати
Глеб Кузнецов
Yuri Karadzhov Software Engineer 18.10.2016 13:45

Не упадет процесс при таких условиях. Вот если вы будете обращаться к req.body.param и req.body не будет, то тогда упадет. Но это весьма странно писать код который не проверяет ошибки, и менеджеры процессов тут не помогут. Если объекта req.body в вашем обработчике может не быть — эту ситуацию нужно обработать, а не рассчитывать, что и так сойдет.

Відповісти
Підтримати
Костя Третяк
Olexandr Vovchok 18.10.2016 13:48

Кстати это еще одно «преимущество» джаваскрипта — не можно знать точно что свойство существует. При строгой типизации все ок, еще на стадии компиляции такие штуки ловятся.

Відповісти
Підтримати
Yuri Karadzhov
Глеб Кузнецов Independent contractor 18.10.2016 14:18 
try {
    var azaza = my.unknown.property;
} catch (e) {
    var azaza = 'вообще похрен';
}
Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 14:23

Ну так в том и суть что везде нужно фигачить трай кетч когда в джаве айдишка не пропустит несуществующие свойства. Это так же как и с типами — в норм языках проверка этой штуки по дефолту а во всяких динамических надо самому писать.

Відповісти
Підтримати
Глеб Кузнецов
Костя Третяк 18.10.2016 14:23

Це ви просто такий «джаваскриптор», як ви кажете. Можна перевіряти наявність властивості body:

req.hasOwnProperty('body')
Відповісти
Підтримати
Olexandr Vovchok
Yuri Karadzhov Software Engineer 18.10.2016 14:54

Это чушь, как скажите на милость статическая типизация поможет вам разобрать произвольный запрос клиента? Если у вас есть ситуация когда ответ клиента не содержит тела, то эту ситуацию нужно обрабатывать отдельно и javascript тут совершенно ни при чем, это проблемы вашей архитектуры либо фреймворка, который вам это тело не добавил раз вы хотите его везде. Но это опять же не спасет вас от случаев типа req.body.param.whatever нельзя обращаться к свойствам объекта которого нет и нельзя решить с помощью статической типизации проблему разбора динамического объекта. А плохому танцору всегда будет что-то мешать, то язык, а то и еще что.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 14:55

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

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 15:10

Я уже объяснил почему, перечитайте. И про проверки так же чушь. Все что вам даст статическая типизация это автодокументирование, автодополнение и защиту от описок на этапе сборки.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 15:16

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

Хотя нет, еще есть вариант не то чтобы описка, а неверное использование части кода написанной другим программистом. Плюс тут еще какая проблема — в слабой типизации когда то что тебе приходит конвертируется по магическим законам и в итоге может наделать очень много бед. Вы ж не будете отрицать это? Вообщем статическая строгая есть очень хорошая штука, и преимущества над ней у динамической и слабой только в скорости разработки и меньшим знаниям необходимым чтобы что то налепить.

П.С, то что джаваскрипт очень небезопасный язык есть факт. Отрицать это глупо. Все, пойду я.

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 16:11

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

Я буду отрицать «магические законы», если бы у вас были знания, которых как вы утверждаете нужно меньше, то никакой магии там не осталось. На самом то деле знаний нужно как раз что больше, и не только знаний, но и аккуратности. И это действительно сложно, для того и придумывают статически типизированные надстройки.

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

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 16:16

Ваша высокомерность не делает вас правым. Пытаться затоптать других потому что у вас другая позиция это очень низко. Речь изначально шла об использовании несуществующего свойства объекта, что в статическом языке бы отловилось на стадии компилации. А так оно выстрелит в рантайме, при чем не обязательно сразу. Что не понятно? Могу обяснить еще раз, раз уж так тяжело доходит.

Вы предлагаете описки и ошибки в коде отлавливать проверками? Серьезно?

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

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 16:39

Меня делают правым мои знания. Я вас не пытаюсь затоптать, я вам объясняю почему вы не правы, вы можете чему-то научиться, а можете обидеться, выбор ваш.

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

Вот вы разработчик стороннего модуля. Разве не нужно проверять что приходит в метод? Или вы пустите на обработку все что придет?
Все то же самое нужно делать и в статически типизированных языках.

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

На счет высокомерия — это вы беретесь судить о знаниях фронтенд разработчиков говоря

меньшим знаниям необходимым чтобы что то налепить.
Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 16:47

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

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

Неужели? Т.е. указание типа необходимого входящего аргумента не делает работу по проверке типа за программиста?

а должны кидать исключение

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

На счет высокомерия — это вы беретесь судить о знаниях фронтенд разработчиков говоря

Вы себе снова что то придумали. Я не судил о знаниях фронтенд разработчиков. Я судил о причинах любви к языкам с динамической типизацией и более меньшим синтаксисом.

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 16:59

В примере были пользовательские данные req.body

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

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

Працюйте за сири, пишiть як навчились, у нас з вами шансiв працювати разом все одно нуль тому нема через що сперечатись =)

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 17:09
В примере были пользовательские данные req.body

Я вроде как написал что не имел ввиду разбор пользовательских данных. Да, тут виновен что не посмотрел внимательно о чем тема была.

Это вы себе что-то придумали
конечно. Это я перекрутил ваши сообщения, не вы мои. А как же =)
о количестве знаний которых у вас в этой области нет

В какой области и по чему видно что нет?

у нас з вами шансiв працювати разом все одно нуль тому нема через що сперечатись =)

Я как то и не напрашиваюсь с вами работать, лол. Кстати, «Senior» это кто вас так оценил? А то видел я уже синьеров на фрилансе, было забавно. Надеюсь вы не такой.

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 17:25

Так все i було, дитя. Це я сам таке собi написав, вирiшив, шо вже старий i пора.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 17:27
дитя
тут еще надо разобраться кто из нас дитя. Ладно если бы вы хоть умели хорошо троллить, а то уровень какой то, первокласника. Вообщем учитесь либо троллить либо вести нормально дискуссию. Удачи.
Відповісти
Підтримати
Yuri Karadzhov
Костя Третяк 18.10.2016 15:51
Все что вам даст статическая типизация это автодокументирование, автодополнение и защиту от описок на этапе сборки.

Ви так написали це, начебто це «ніщо». Зрозуміло, що динамічну типізацію не може замінити статична типізація, але лише дуже мала частина коду працює із вхідними даними, де потрібна динамічна перевірка. Більшість же коду потребує саме статичної типізації, особливо якщо потрібна складна якась архітектура.

Статична типізація прямо дуже сильно допомагає в розробці.

Відповісти
Підтримати
Yuri Karadzhov
Olexandr Vovchok 18.10.2016 15:54

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

Відповісти
Підтримати
Костя Третяк
Yuri Karadzhov Software Engineer 18.10.2016 16:02

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

Відповісти
Підтримати
Костя Третяк
Olexandr Vovchok 18.10.2016 16:05
Человек выше просто путает данные с моделью и вообще выдвигает какие-то безумные предложения

Можно пример?

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 16:16

Это ваш ответ на коментарий про разбор пользовательского запроса:

Кстати это еще одно «преимущество» джаваскрипта — не можно знать точно что свойство существует. При строгой типизации все ок, еще на стадии компиляции такие штуки ловятся.
Но на статической гораздо меньше придется проверок лепить чем на динамической.
Ну так в том и суть что везде нужно фигачить трай кетч когда в джаве айдишка не пропустит несуществующие свойства. Это так же как и с типами — в норм языках проверка этой штуки по дефолту а во всяких динамических надо самому писать.

Вот вам целая коллекция. Это все ложные утверждения.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 16:18

Это проблема вашего понимания моего комментария. То что вы себе придумываете что то я в этом не виноват. О последнем пункте читайте мой комментарий свежий.

Это ваш ответ на коментарий про разбор пользовательского запроса:

Лол конечно. Фантазировать мы любим. Вы там немного свою волну включили, бывает.

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 16:28

Понимаете, это не правильно «фигачить трай кетч» в ситуации когда иде может отливить ошибку в статически типизированном коде и мои «фантазии» тут ни при чем.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 16:30

В случае написания стороннего кода которым будут пользоваться другие программисты это вполне правильно при использовании динамического языка о проблемах которого мы и говорим. Допускать пропуск неверных данных вот это неправильно. Ведь программы пишет не один человек. Хотя даже он делает ошибки.

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 16:49

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

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 16:51

Я понимаю только то что вы уже перекрутили все что только можно было. И что дальнейший спор с вами не имеет никакого смысла. Преимущества статики сто лет как известны. Почитайте как то может, а то спорите непонятно о чем. Удачи.

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

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 17:07

Вибачте, не хтiв вас ображати, не побачив з ким спiлкуюсь. Буду навчатась, читати, може колись зрозумiю i щось з мене буде

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 17:15

Так остроумно что уже монитор мой раскололся на части. Жгите еще.

Відповісти
Підтримати
Yuri Karadzhov
Olexandr Vovchok 18.10.2016 17:24

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

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

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 17:50

Дитя, low level разработчики це тi хто на асмi та сях пишуть, не плутай

Відповісти
Підтримати
Olexandr Vovchok
Yuri Karadzhov Software Engineer 18.10.2016 17:57

Вчись дитя, поки я живий, то й на новий заробиш. А то будеш така бестолочь — доведеться в ебам йти!

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 16:29

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

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

Відповісти
Підтримати
Yuri Karadzhov
Valentin Nechayev архімаггриб в Дарницькі печери 19.10.2016 09:07
Это чушь, как скажите на милость статическая типизация поможет вам разобрать произвольный запрос клиента?

Это почему сразу «произвольный»? Произвольный не разбирают, его вначале классифицируют. А уже уложив в предполагаемые рамки — типизируют.

Если у вас есть ситуация когда ответ клиента не содержит тела, то эту ситуацию нужно обрабатывать отдельно

Так и будет — запрос не будет типизирован и получит отлуп, говоря юридическим языком, при рассмотрении по форме до рассмотрения по сути :)

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 19.10.2016 09:31

Правильно, если у вас есть классификация запросов то у вас есть и модель данных под эти запросы с которой вы и работаете. Ситуация обращения к свойству несуществующего объекта у вас возникнуть не может так как вы теперь работаете с моделью. Так что это проблемы архитектуры. Классификация и есть этап разбора данных, типизация при этом не обязательна (да как уже говорилось это поможет избежать описок при обращении к модели но не более и это можно сделать и без типизации). Сейчас тенденция сдвинулась к опциональным и выводимым типам (это не обязательно должна быть динамическая типизация) и системы типа flow помогают отслеживать большую часть ошибок без указания типа вообще.

Відповісти
Підтримати
Valentin Nechayev
Костя Третяк 18.10.2016 14:28

Правильно ви написали за req.body.param, і за обробники помилок, я ж кажу про баг, який пройшов мимо уваги, і який може завалити сервак легко.

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 14:53

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

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

Відповісти
Підтримати
Костя Третяк
Andrii Studinskyi Software engineer 18.10.2016 15:50
Но это весьма странно писать код который не проверяет ошибки, и менеджеры процессов тут не помогут. Если объекта req.body в вашем обработчике может не быть — эту ситуацию нужно обработать, а не рассчитывать, что и так сойдет.
Ну тут разные подходы есть, «let it crash» лично мне кажется довольно логичным.
stackoverflow.com/...ophy-applicable-elsewhere
Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 16:23

Конечно, но я думаю мы обсуждаем проблему в контексте javascript, и сравнивать его с эрлангом будет не корректно. Да и в эрланге let it fail не везде применим и череват зависаниями транзакций и прочими прелестями. Опять же данный пример — это явно некорректно обработанная ситуация, если у вас клиент может отправить такой запрос а вы на него тихо не отвечаете, то это скорей всего не правильно.

Відповісти
Підтримати
Andrii Studinskyi
Andrii Studinskyi Software engineer 18.10.2016 17:18

Конечно не в 100% случаев применим. Но не хотелось бы, чтобы один сбойнувший поток негативно влиял на все приложение, какая-нибудь ошибка рано или поздно возникнет даже при параноидальных проверках. В таком случае supervisor должен поток перезапустить, убить после n неудачных попыток (в зависимости от стратегии), но не вешать все приложение. Я ноду вообще не знаю, если там так и есть — отлично.

Відповісти
Підтримати
Yuri Karadzhov
Yuri Karadzhov Software Engineer 18.10.2016 17:39

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

Відповісти
Підтримати
Andrii Studinskyi
Владимир Котов System Architect 14.10.2016 23:24

1/2. В ноде есть multithreading, на 1 ядро кпу один поток. Занимается этим модуль cluster. Более мажорная тулза pm2.keymetrics.io Собственно pm2 частично может решить вопросы п.2
Если нужно потоки поднимать без привязки к ядрам кпу, то их можно поднять на разных портах и роутить чем душе угодно, начать можно c того же nginx.
3. Фреймворков действительно куча, так же как и всяких шаблонизаторов типа jade, ejs. MVC из коробки наверное sailsjs.org, но обычно каждый себе делает свой набор модулей. Да и разносят бэк с фронтом. Нода конечно может отдавать страницу при помощи тех же шаблонизаторов, но лучше сделать синглпейдж, а ноде оставить работу с данными. Часто делают Angular/React + Node JS REST API

Відповісти
Підтримати
Elance Test 15.10.2016 16:25
Нода конечно может отдавать страницу при помощи тех же шаблонизаторов, но лучше сделать синглпейдж, а ноде оставить работу с данными. Часто делают Angular/React + Node JS REST API
До смешного уже доходит. Звучит будто нода не может отрендерить страничку и нужно делать только синглпэйдж. Кстати вопрос. А можно на ноде сделать сайт новостей? Например www.bbc.com
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 15.10.2016 17:09

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

На ноде можно сделать даже два сайта новостей))

Відповісти
Підтримати
Elance Test
Mikhail Dubovskiy 15.10.2016 17:34

а як потім з підтримкою у такому великому проекті ?

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 15.10.2016 19:44

Можно подробней вопрос, что имеется ввиду? Я не разрабатывал ВВС, и как я понимаю новостные сайты это системы с многоуровневым кешем. А уже кто этот кеш строит вопрос второстепенный.

Відповісти
Підтримати
Mikhail Dubovskiy
Владимир Котов System Architect 15.10.2016 20:41

Предположу, что Вы имели ввиду как поддерживать на ноде большие проекты.
Если проект написан грамотно с тестами и ci, то нода поддерживается хорошо. Если это фронтЭнд стайл на ноде, то будет ужас и кошмар.

Відповісти
Підтримати
Mikhail Dubovskiy
Костя Третяк 15.10.2016 21:40

Таким чином, ми плавно підбираємось до TypeScript =), хоча насправді його можна застосовувати будь-де, де є JavaScript.

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 15.10.2016 23:02

Вполне, тем более ангулар 2 на TypeScript, делать и фронт и бэк на одном языке, намного удобнее. Плюс Джавистам удобнее переходить на ts, чем на js.

Відповісти
Підтримати
Костя Третяк
Olexandr Vovchok 16.10.2016 14:45
Плюс Джавистам удобнее переходить на ts, чем на js.

Тогда зачем им нужна нода на беке? если можно фронт писать на джава стайл языке. Или они дураки должны выкинуть годы опыта и знаний чтобы писать на новомодной фигне которая через пару лет может загнуться как и ангуляр первый. Не хочу показаться троллем и оскорбить вас как ноде девелопер, но джаваскриптерам следует не лезть везде а сидеть в своей нише где нода подходит. А то получается так:
— топором тоже можно забивать гвозди!
— можно, но зачем, если есть молоток?

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 01:16

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

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

Попытки сделать подобное на Джаве, на сколько я знаю были, но они провалились. Эпоха Java everywhere не наступила, хотя она для этого предназначена, а эпоха JavaScript everywhere уже идет, нравиться это мне/Вам/кому-то или нет.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 17.10.2016 13:27

Успокойтесь, никуда ничего не идет.

JavaScript everywhere
это лишь пиар акция от фанатов. Как видим которая не получила успех. Все что получилось это низкокачественные поделки в мобайл на которых пишут только для пицерий, и нода которая полезная только в узкой нише, в других местах уже на го переписывают те кто ошибся выбрав ноде. Я вам больше скажу — скоро и веб сайтов то не будет, все перейдет на веб апы, как в мобайл. Эпоха веб 2.0 проходит. начинается разработка серьезных приложений, где javascript ну слабоватенько катит. Чему пример появление Typescript и Angular 2 с ним же. А с выходом Webassembly вообще все печально станет у javascript. Желание джаваскриптеров и реальность сильно расходятся. Серьезные апы пишутся на серьезных языках.
Відповісти
Підтримати
Владимир Котов
Artem Perchyk Front-end developer 17.10.2016 16:11

>Typescript
Просто надстройка над обычным жс
>выйдет Webassembly и тогда JS всё
«хх октября 1928 года Земля налетит на небесную ось!»
Рили, это уже сектантство какое-то.

Відповісти
Підтримати
Olexandr Vovchok
Valentin Nechayev архімаггриб в Дарницькі печери 19.10.2016 09:05
Просто надстройка над обычным жс

Тогда и C++ - просто надстройка над обычным ассемблером. Исполнять-то, в итоге, всё равно машинные команды...

Рили, это уже сектантство какое-то.
Кто бы говорил :)
Відповісти
Підтримати
Artem Perchyk
Владимир Котов System Architect 17.10.2016 16:53
это лишь пиар акция от фанатов. Как видим которая не получила успех

Да ну как это? Оглянитесь. Расширьте свой кругозор, начните смотреть по сторонам, Вы будете спотыкаться об js постоянно до тошноты.

в других местах уже на го переписывают те кто ошибся выбрав ноде
Ну да, те которые не смогли разобраться с промисами (sporto.github.io/.../concurrency-node-vs-go/, потому что не хватило мозгов. Потом ушли на Го писать супер-пупер проекты, которые потом снова будут переписывать на ноду или что-то другое.
Эпоха веб 2.0 проходит. начинается разработка серьезных приложений

Та выйдите Вы уже на улицу из своей реальности. Куча легаси пхп кода поддерживается, о каких серьезных проектах Вы говорите, все работает на древнем на (нецензурная лексика). При разговоре с заказчиками пробуйте предложить веб разработку серьезного веб проекта, где есть фронт и бэк заставить писать на двух языках. Он спросит зачем? Если фронт все равно будет на js? Пока бразуеры будут на js, его эра не закончится. Webassembly как раз является развитием js, а не конкурентом.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 17.10.2016 18:47
Вы будете спотыкаться об js постоянно до тошноты.

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

Ну да, те которые не смогли разобраться с промисами (sporto.github.io/.../concurrency-node-vs-go/, потому что не хватило мозгов.

Ну конечно, разработчикам хайлоад сервисов действительно не хватает мозгов. Куда им до жаваскрипт фанатиков.

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

Лол, т.е. других проектов не на жабоскрипте нет?)) Я знал что джаваскриптеры живут в манямирке, но не думал что настолько. Кстати серьезные проекты как раз таки пишутся на C# и Java, а не на Node.js

Webassembly как раз является развитием js, а не конкурентом.

Я согласен. Развитием в плане ухода от написания на нем к написанию на более нормальных языках. Ну а жаваскрипт просто будет кодом прокладкой между нормальным языком и браузером. Все верно.

П.С. что там, фонегап уже уничтожил нативную разработку?

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 19:52

С быдло-троллями дискуссии не веду. Всего доброго.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 15.10.2016 22:12
Если проект написан грамотно

Есть 2 вида языков программирования:

1. языки которые помогают писать правильный код
2. и языки которые мешают писать правильный код

Фанаты второго типа всячески пытаются возложить недостатки языка на разработчика.

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 15.10.2016 23:05

Это холивар между гибким типом языков и строгими. Те кто пользуется языками со строгими требованиями — хотят гибкости, а те кто пользуется гибкими — хотят строгости.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 16.10.2016 00:44

Нет тут холивара. Его создают те кто языки предназначеные для написания скриптов и эффектов на страничке пытается использовать в серьезных апликейшин девелопментах где уже давно есть нормальные инструменты, со строгой типизацией и адекватным поведением. По поводу кто что хочет тут вы описали мне кажется только часть людей. По поводу гибкости и строгости то как мне кажется С# отличный пример сочетания всей необходимой строгости с вкраплениями гибкости для использования где надо а не везде где попало. По поводу ноды то как бы Го вроде как ее уже уделал, что доказывается тем что переписывают свои сервисы топовые ресурсы.

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 16.10.2016 04:16

Вот и начался холивар ))
процитирую слова своего друга, который увидел Ваш комментарий на счет Го:
«Не показывай мне про этот Го, любая проблема, наши синьоры Го ломают голову пока ее решат, все неочевидно.» — Пишет на Го пол года.

В группе Ноды в фб была статья, что востребованность ноды в Европе за этот год выросла в 4-ре раза.

Два переписывают с ноды на Го, а двадцать два стартуют на ноде. А все от человеческой лени, и от того, что js знает больше людей, чем тот же C#. И их будет становиться больше, потому что js проще и гибче. Маркетинг, что тут сделаешь. А если добавить к холи вару asm.js, то перспективы js возрастают.

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

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

Відповісти
Підтримати
Olexandr Vovchok
Mikhail Dubovskiy 16.10.2016 09:21
Держать двух синьйоров вместо одного фулстэк...
я думаю це малоімовірно поки що. оскільки бекенд все таки не тільки простий круд а маса інших систем тих же баз даних. Фронт тоже постійно ускладнюється
Відповісти
Підтримати
Владимир Котов
Костя Третяк 16.10.2016 13:11

Для розробника JavaScript full stack не складно вивчити й MongoDB яка є дуже дружньою до JavaScript. В тому то і вигода, що JavaScript full stack розробники можуть робити дуже широкий спектр задач (я вже нічого не кажу про TypeScript-full-stack розробників =). Мабуть можна сказати що у веб-розробці, такий спектр є значно ширшим, в порівнянні з іншими мовами програмування.

Відповісти
Підтримати
Mikhail Dubovskiy
Владимир Котов System Architect 16.10.2016 13:29

Вы еще скажите мэджик слово БИГДАТА...Не вижу противоречий. Под ноду существует куча драйверов под базы данных, не встречал ситуации за почти 5 лет, чтобы не было драйвера под ноду для какой-то БД. Или чтобы нода не справилась с какой-то задачей. Как раз наоборот. Хочешь сервер — нода, хочешь кроссплатформ десктоп приложение — nwjs, хочешь ардуино — firmata, хочешь мобайл — phonegap, хочешь бинарник — Nexe. Учишь всего один язык, а возможности зашкаливают.

Відповісти
Підтримати
Mikhail Dubovskiy
Mikhail Dubovskiy 16.10.2016 18:33

ну в тому і проблема що крім підключити базу ще треба вміти нею користоватися.

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 01:00

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

Відповісти
Підтримати
Mikhail Dubovskiy
Mikhail Dubovskiy 17.10.2016 09:32
Попробуйте найти хорошего строителя или юриста, или не дай бог врача. А ведь они “пишут на одном языке” и у них нет такого разнообразия
я вам просто наведу приклад ви ж не підете робити операцію на серце до стоматолога ?
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 16:04

А Вы пишите веб приложения на bash?

Відповісти
Підтримати
Mikhail Dubovskiy
Mikhail Dubovskiy 17.10.2016 17:04

фронт пишу на js але основний профіль це бекенд на джаві.

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 17:14

Вы предлагаете мне пойти к врачу, который не приспособлен к операциям на сердце. Почему же сами пользуетесь языками, которые приспособлены к вебу? Bash к вебу не приспособлен — это стоматолог в Вашем примере. Отсюда и был вопрос.

Відповісти
Підтримати
Mikhail Dubovskiy
Mikhail Dubovskiy 17.10.2016 17:23
Почему же сами пользуетесь языками, которые приспособлены к вебу? Bash к вебу не приспособлен — это стоматолог в Вашем примере.
 я і пропоную не пихати ноду туди де не її місце . . .
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 17:30

Вы адресовали свое сообщение лично мне, в топике касающимся ноды. Я пихал ноду туда, где ей не место? Я ответил на вопросы ТС, так как большинство комментаторов ориентируются на статьи на хабре 2011 года.

Відповісти
Підтримати
Mikhail Dubovskiy
anonymous 17.10.2016 17:36

многие джава программисты от слова совсем не умеют пользоватся БД

Відповісти
Підтримати
Mikhail Dubovskiy
Mikhail Dubovskiy 17.10.2016 21:15

без вміння користуватися і розуміння не напишеш норм архітектури в норм проекту . . .

Відповісти
Підтримати
anonymous
Костя Третяк 15.10.2016 21:50

Прямо зараз не готовий дати лінк на рекомендації написання модулів до Nginx (nginx також є представником однопоточної програми як і node.js), але можу сказати, що там згадується за необхідність «постійно пам’ятати, що якщо ви виконуєте якийсь код довго, то вас очікують усі клієнти, а не лише той, клієнт, який ініціював цей запит. Використовуйте асинхронний підхід замість синхронного».

А раз це згадується як важливий момент, то зрозуміло що накосячити з «одним потоком і асинхронністю» можна навіть на такому надійному веб-сервері як Nginx.

Точно такі ж рекомендації можна давати й для Node.js

Відповісти
Підтримати
Mikhail Dubovskiy
Владимир Котов System Architect 15.10.2016 23:03

Накосячить можно на любом языке ))

Відповісти
Підтримати
Костя Третяк
Olexandr Vovchok 16.10.2016 00:45

Но на некоторых сделать это проще ©

Відповісти
Підтримати
Владимир Котов
Valentyn Ponomarenko Працює в Oracle 13.10.2016 22:18
осмотрел в инете посты про «ноду» и чет меня она меня не вдохновляет.

Посмотрите в сторону Elixir...
Відповісти
Підтримати
Andrii Studinskyi Software engineer 17.10.2016 16:37

Нужно быть готовым тогда в Erlang нырять, одним эликсиром не всегда можно обойтись. А так то язык отличный.

Відповісти
Підтримати
Valentyn Ponomarenko
schwarzlichtbezirk 13.10.2016 20:56

Если каждый запрос будет обрабатываться в отдельном физическом потоке, сервер ляжет. Поскольку ОС будет вынуждена обслуживать большой пул потоков, причём на каждый ещё выделяется несколько мегабайт памяти под стек. Для наглядности можете просто запускать в цикле спящие потоки Sleep(INFINITY), и смотреть на загрузку проца.

Відповісти
Підтримати
Dmytro Lapshyn Tech Lead в Fulcrum Rocks 15.10.2016 15:57

Ну справедливости ради, в ASP .NET thread pool есть своя проблема с истощением, вызванным тем, что потоки заняты ожиданием ввода/вывода или еще какого внешнего события. Решается грамотным асинхронным программированием, но эта концепция, по моим наблюдениям, пока не очень распространена среди дотнетчиков, даже опытных.

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

Відповісти
Підтримати
anonymous
Андрей Литвинов C Señor 14.10.2016 11:13
смотреть на загрузку проца
на потребление памяти
Відповісти
Підтримати
schwarzlichtbezirk
Глеб Кузнецов Independent contractor 13.10.2016 14:45

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

1. Каждый HTTP запрос обрабатывается в отдельном физическом потоке.
bfy.tw/8AUr
2. Механизмы синхронизации.
bfy.tw/8AV0
bfy.tw/8AV5
3. Наличие фреймворка. Поддержка полноценного MVC механизма из коробки. С базой и html шаблонами.
это все гуглится, конкретно фреймворки не знаю, но есть шаблонизаторы html и другие приятные вещи.
Посмотрел в инете посты про «ноду» и чет меня она меня не вдохновляет.
посмотрел в интернете посты про Java, в общем ОЛОЛО ЖАБА МАСДАЙ.

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

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

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

Відповісти
Підтримати
Gennady Dogaev full-stack web developer (freelance) 13.10.2016 14:20

Нода однопоточна и асинхронна, первые 2 требования не вижу выполнимыми.

Відповісти
Підтримати
Леонид Мартынюк инженер-программист в 1World online R&D Сenter 13.10.2016 13:19

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

Відповісти
Підтримати
Victor Mikhaylov junior manual tester 13.10.2016 13:18

это такая сейчас хипстерская мода пихать везде NodeJS? :-)
nodeJS задумывался для конкретного типа приложений с высоким параллелизмом — которые держат одновременно огромное количество соединений с клиентами, но каждая операция очень короткая по времени. категорически не подходит для модели , когда клиент инициирует длительную по времени или ресурсоемкую задачу на сервере... убьет перформанс на корню
про недостатки его на хабре хорошо расписано, поэтому не нужно пихать его везде , а только в тех задачах где это действительно дает преимущества

Відповісти
Підтримати
Alexander Baranetsky Software engineer 13.10.2016 20:23

Спасибо, можете привести примеры реальных задач? :)

Відповісти
Підтримати
Victor Mikhaylov
Victor Mikhaylov junior manual tester 13.10.2016 21:24

например многопользовательская онлайн игра

Відповісти
Підтримати
Alexander Baranetsky
Vladimir Krasulya Web Dev в Ciklum 13.10.2016 22:05

Запустите ноду в несколько инстансов (по количеству ядер) и разница от сервера на Java будет лишь в типе многозадачности (нативные threads вытесняют друг друга, в ноде код должен доработать перед тем как запустится следующая итерация event-loop), но так как все операции неблокирующие (кроме собственно вычисления) — упрётся в обоих случаях в CPU.

Відповісти
Підтримати
Victor Mikhaylov
anonymous 13.10.2016 10:51

Если опыта хватает и руки из правильного места — очень легко на ноде реализовывается паттерн аля апачевского pfm или worker, причем можно не ограничиваться и выходить за рамки взаимодействия лишь только с процессами ;) ну, а изкоробки.. если это javascript , ыыы alert $.scrollto — вообще не вариант

Відповісти
Підтримати
Костя Третяк 13.10.2016 08:32

Видно що джун пише «требования к процессу», який є досить далеким від цього.
1. «в отдельном физическом потоке»? Мається на увазі «в окремому процесі»?
2. «механизмы синхронизации» — це теж дуже не однозначна вимога, синхронізувати можна багато чого...
3. Із приводу Node.js-фреймворків, вам треба було хоч трохи піднапрягтись і погуглити на цю тему, після чого розписати що ви прочитали і в чому у вас є сумніви/питання... Гляньте такий сайт: Node Frameworks

Відповісти
Підтримати
Нестор Иванович 13.10.2016 05:57

1 такого не завезли
2 поржал
3 100500 микро костылей от криворуких еврогеев

бери akka или vertex и не мучайся

Відповісти
Підтримати
anonymous 13.10.2016 01:57

1. Каждый HTTP запрос обрабатывается в отдельном физическом потоке.
2. Механизмы синхронизации.
3. Наличие фреймворка. Поддержка полноценного MVC механизма из коробки. С базой и html шаблонами.
Это все не к ноде. Пишите себе на джавке и горя не знайте. Главное — не использовать хибернейт.
Відповісти
Підтримати
NewOne NewOne 13.10.2016 10:39

А что посоветуете вместо

хибернейт
Відповісти
Підтримати
anonymous
anonymous 13.10.2016 11:10

Jooq конечно же, ну или на худой конец mybatis/jdbi. В общем любой тул с которым можно использовать нативный sql и фишки которые младше стандарта sql92. Те же window функции, json/bson/hstore, gis и прочие вкусности которые есть например в постгре, но хибером без костылей не поддерживаются.

Відповісти
Підтримати
NewOne NewOne
anonymous 17.10.2016 00:14

Для бесплатных баз (постгре, мускуль) — бесплатный. Для платных (оракл, мсскл) — платный.

Відповісти
Підтримати
А Р
Olexandr Vovchok 16.10.2016 20:35

А в чем плюс нативного sql? Вроде как ОРМ это модерн подход

Відповісти
Підтримати
anonymous
anonymous 16.10.2016 20:40

Омг...
Так, между прочим, nosql db в реальности старше sql db.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 17.10.2016 13:29

Хз, no sql модная штука просто, которая мало где используется.

Відповісти
Підтримати
anonymous
anonymous 17.10.2016 14:39

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

модерн
ибо модерн может окажется еще более древним чем то что он замещает.

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

Відповісти
Підтримати
Olexandr Vovchok
anonymous 17.10.2016 00:15

ОРМ освобождает от нативного sql до первой миграции.

Відповісти
Підтримати
Olexandr Vovchok
Elance Test 23.10.2016 12:42

До первого запроса сложнее чем выборка селектом с условием.

Відповісти
Підтримати
anonymous
Olexandr Vovchok 24.10.2016 00:17

Тем не менее надо использовать ОРМ по полной и только при необходимости переходить на sql. Рутины станет намного меньше.

Відповісти
Підтримати
Elance Test
Alexander Baranetsky Software engineer 13.10.2016 20:16

Спасибо! Скорее всего это будет Java, если конечно дойдем до того что в текущей модели код будет дешевле переписать нежели маштабировать один микросервис на 2 и более сервера.

Відповісти
Підтримати
anonymous
Artem Zaika 13.10.2016 01:14

Тк я кодил промышленные приложения на Java и на Node.js, могу ответить следущее:
1. В ноде нет многопоточности, но есть многозадачность. Если убрать такие ньюансы, то нода на простых запросах работает очень быстро
2. Нет такого и не нужно
3. Есть
Но все-таки на вашем месте я бы провел более глубокий анализ двух технологий и во главу угла поставил бы еще скорость написание на ЯП поддерживаемый платформой, удобоство, поддержка коммьюнити итд. Я после получения своего опыта на Nodejs вот что решил для себя:
* Нода обсолютно и полностью заточена под REST. Это значит что писать сервисы на ней кайф и очень быстро, но если вы решите делать монолит, — вы получите охеренный баттхерт, особенно если у вас с самого начала не будет привычки выделаять главные сущности в модули
* JS и ассинхронность. Если вы не отформатируете голову для понимания ассинхронности и будете писать и думать в ноде так же, как в Java, то закончите тем, что или утонете в безконечных коллбеках или начнете использовать библиотеки, которые делают из ассинхроннго кода последовательный код и тем самым убъете производительность.
* Как я уже писал поддерживать и понимать монолит на Node.js — занятие малоприятное. Если написать кусок говна на Java надо еще постараться, то в ноде наоборот- надо крепко подумать, чтоб написать понимаемый всеми код, который бы еще был и асинхронным
* Ну и напоследок: весь тот базар-вокзал который начался два года назад с форками разных версий ноды, потом мерж — весьма разочаровал и неприятно удивил. Вся эта возня не прибавляет ощущения, что платформа поддерживается серъезными ребятами, которые приведут ее к успеху.
Что касается Java и скоростных ассинхронных серваков, то их хватает, плюс используя аннотации Spring можно генерить REST, DAO и много чего полезного, что в разы увеличивает скорость разработки.

Відповісти
Підтримати
Mikhail Dubovskiy 13.10.2016 21:34

зараз spring boot з версії 1.4 став особливо рулити . багато чого роблять для пришвидшення розробки.

Відповісти
Підтримати
Artem Zaika
Sergio Gonzales 13.10.2016 00:46

снова( год времени потратите на интеграцию и борьбу за производительность, потом плюнете и напишете на плюсах

Відповісти
Підтримати
Егор Добровольский 13.10.2016 00:42

1. Нет (да).
В ноде поток один и всегда один. В единицу времени обрабатывается только 1 запрос, остальные ждут. Но вы можете форкнуть на несколько процессов, каждый из которых будет обслуживать свой пул запросов.
2. Отпадает за ненадобностью.
3. Есть. Советовать не буду — их тыщи разных.

Что посоветую — почитайте про Go, изучите юзкейсы, почитайте success stories (twitch, iron.io, etc). Быть может, вам подойдёт.
BTW: MVC & microservices? Впрочем, MVC в Go есть. Но фреймворки не особо популярны из-за идиоматики языка. Взгляните на Beego.

Відповісти
Підтримати
Aliaksandr Valialkin программист в VictoriaMetrics 16.10.2016 16:42

Success stories про Go найдете тут — github.com/golang/go/wiki/GoUsers

1. Программы на Go отлично масштабируются на все ядра процессора, в отличие от однопоточного nodejs. При этом не нужно извращаться с shared memory при взаимодействии между процессами nodejs, ведь в Go достаточно одного процесса, чтобы загрузить работой все ядра CPU.
2. Веб-сервер на Go отлично справляется с миллионом одновременных клиентских подключений, где каждое подключение обрабатывается отдельным потоком. Т.е. под Go не нужно извращаться с асинхронностью, калбэками, промисами, async / await и т.п. костылями при обращении к файлам и внешним сервисам типа базы данных, key-value storage/cache или самописным микросервисам — достаточно обычного простого и понятного синхронного кода.
3. Программы на Go работают быстрее программ на nodejs. См. techempower benchmarks.
4. Программы на Go содержат меньше багов, т.к. простой синхронный код легче дебажить, поддерживать и расширять, чем закрученный асинхронный.
5. Код на гоу написан в едином стиле благодаря go fmt, поэтому его легко читать и править. Благодаря этому в среде go-разработчиков отсутствуют споры о правильной расстановке скобок, табов и пробелов.
6. Программа на гоу компилируется в один исполняемый файл, который не нуждается ни в каких дополнительных зависимостях, в т.ч. не нужна и установка Go на серверы, где будет работать программа. Поэтому деплой и обновление программ на Go представляет из себя заливку новой версии бинарника и его перезапуск. Не нужно никаких докеров и никакой специальной подготовки окружения. При выходе новой версии гоу достаточно просто перекомпилировать программы новой версией компилятора и перезалить их в прод. Сравните это с апгрейдом nodejs.
7. ....
8. PROFIT!!!

Відповісти
Підтримати
Alexander Baranetsky
Костя Третяк 16.10.2016 17:23

Одні профіти. Питання ще залишається: чому не усі переходять на Go?

Відповісти
Підтримати
Aliaksandr Valialkin
Olexandr Vovchok 16.10.2016 17:41

Тому що джаваскриптерам не сидиться на дупі. А є табун джаваскриптерів то й використовують їх. Це саме питання чому php такий популярний в фреймворк розробці, хоча python кращий. На ринку грає роль не лише якість і потужність інструменту а й кількість розробників, ну і що дуже головне то це розпіареність. Але піар штука тимчасова, як би там не кричали «soon javascript will be everywhere because you can program on it everything, including your cat!». Якщо ваш джаваскрипт такий збц то чому постійно шукають як би від нього позбутися? (coffescript, typesript etc). Хоча не переживайте, скоро webassembly вийде і дійсно всі будуть javascript використовувати, в якості результату компіляції з старших братів які писалися не за 10 днів.

Відповісти
Підтримати
Костя Третяк
Костя Третяк 16.10.2016 17:57
є табун джаваскриптерів то й використовують їх
Тобто вони усі тупі?
Це саме питання чому php такий популярний в фреймворк розробці, хоча python кращий
Погане порівняння, бо PHP заточена для веб-розробки, тоді як Python, на скільки я знаю, лише пристосований для цього... з усіма відповідними наслідками...
головне то це розпіареність
Типу Go не піарять... слабенький аргумент, не бачу я проплаченого піару взагалі... окрім хіба що Laravel, ну то вже інша історія.
Якщо ваш джаваскрипт такий збц то чому постійно шукають як би від нього позбутися? (coffescript, typesript etc).
Його виправляють, удосконалюють, а не позбавляються від нього...
Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 16.10.2016 18:24
Тобто вони усі тупі?

Звичяайно ні. Вони просто захищають своє болото, як і всі інші.

Погане порівняння, бо PHP заточена для веб-розробки, тоді як Python, на скільки я знаю, лише пристосований для цього... з усіма відповідними наслідками...

PHP заточений під пірсенальну сторінку Лінуса Торвальдса, а потім як і джаваскрипт був «удосконалений». Що з чього вийшло всі ми добре знаємо.

тоді як Python, на скільки я знаю, лише пристосований для цього... з усіма відповідними наслідками...

Наслідки тут лише одні — Python повноцінна мова програмування, а не франкенштейн-обрубок.

Типу Go не піарять...

Якось не бачив його піар. А от воні від «революційної» ноди вистачає на весь інет. При чому прикол такий що як тільки щось нове на жаваскрипті виходить то вже кричать як він скоро усіх витіснить. І потім він померає і на його місце приходить інший жаваскрипт фреймворк. Така сумна доля жаваскрипту — жити не довго, померати швидко. А тим часом норм фреймворки на норм мовах стоять на ринку десятками років і споглядають на всю цю однодевну маячню посміхуючись.

Його виправляють, удосконалюють, а не позбавляються від нього...

Абсолютно згідний. Скоро його вдосконалять остаточно, за допомогою Webassembly.

З усією повагою, javascript хейтер.

Відповісти
Підтримати
Костя Третяк
anonymous 16.10.2016 18:29

Вообщето пхп давно стал очень продвинутым языком. Единственная беда которая осталась — стандартная библиотека, ее уже не пофиксят, но во всем остальном нынешний php очень крут

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 16.10.2016 18:45

Крут но как ты написал либы у него просто упоротые. И тут следует вопрос — зачем его использовать когда есть норм языки изначально? Кроме того он прожорлив, отсутствует строгость типов, правила кодирования. Да, он все больше пытается содрать с Java, но он никогда не будет хорошим языком, потому что нельзя сделать из монстра красавицу. Он стал популярным потому что позволял домохозяйкам покодировать между варкой борща. Для любого пхпшника который изучал нормальный язык понятно что пхп именно для этого и был создан. Мое мнение что он свое отжил. Ну кроме цмсок конечно, эту нишу у него никто не отберет. А вот начинать на нем делать проект с фреймворком где на каждый запрос создается отдельный процесс, т.е. на нем нельзя создавать быстрый РЕСТ или тем более реалтайм. Зачем он сдался. Есть такая статья «PHP создан чтобы умирать».

А да, еще мое мнение что скриптовые языки как доминантные в вебе свое отжили. Время мелких апов проходит.

Відповісти
Підтримати
anonymous
Anton Khristiansen web back end developer 16.10.2016 21:15
отсутствует строгость типов
PHP 7, strict mode? Не, не слышал
Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 16.10.2016 21:52

Очередные костыли которые работают только в указанных функцией твоих файлах. Просто смешно. Я ж пишу — зачем использовать плохие языки которые на себя навешивают что то, когда существуют нормальные языки у которых все эти фичи включены изначально, ну или по крайней мере включены нормально а не как тупой костыль. Вы действительно верите что пехопешники начнут это юзать? Учитывая еще и саму декларацию типов которая сделана так чтобы удобно было их не использовать чем использовать.

Відповісти
Підтримати
Anton Khristiansen
Anton Khristiansen web back end developer 16.10.2016 22:48
. Вы действительно верите что пехопешники начнут это юзать?
Я и моя молодая пехопешная команда умпешно используем PHP 7 со строгой типизацией на новом проекте, так что мой ответ — да. По поводу
правила кодирования.
, с теми, кто упорно не соблюдает PSR 2 — 4, на текущем месте работы расстаются после исп. срока. А еще мы используем SOLID и другие страшные слова и обычно при тех. собесе потенциальному разработчику подсовывают примеры с кодом и просят обьяснить, где тот или иной принцип SOLID нарушен и почему.

Скажу еще так, чтоб было понятно мое мнение: разработчики на PHP делятся на 2 лагеря: в одной — те, кто увяз в «джейвейри» и «пехопе» в виде CodeIgniter или Yii на худой конец,и которые без задней мысли инициализируют обьекты в методе других моделей, не задумываясь как это потом натянуть на PHP UNIT, и те, которые используют DI для управления зависимостями, стараются построить SOA архитектуру с максимально ортогональными, реюзабельными модулями, в новые проекты внедряют строгую типизацию, и активно используют phpdoc. И если первый тип «пехопешников» продолжает отправлять «false» вместо 0 в json массивах, за что будут прокляты теми же гоферами, которым этот массив надо будет обработать, второй тип разработчиков активно растет с каждой версией PHP. А наговнякать можно на любом языке.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 16.10.2016 23:03
используем PHP 7 со строгой типизацией на новом проекте

Зачем? Не проще и лучше ли взять Java or C#?

Відповісти
Підтримати
Anton Khristiansen
Alexander Baranetsky Software engineer 17.10.2016 01:08

Если ваш проект уже на PHP. То явно не проще)
Жалко что PHP процессы — короткоживущие сущьности. И к ним нельзя применить такую фичу как shared memory((((

Відповісти
Підтримати
Olexandr Vovchok
Anton Khristiansen web back end developer 17.10.2016 11:06

Ну, это больше вопрос к тех лидам, но в виду того, что в тиме, в которой я работаю, бек енд разработчики — php девы, то в случае другого языка для бек енда, этим проектом занималась бы другая тима :). А так, PHP в обертке Symfony на данный момент справляется с теми задачами которые у нас поставлены. Так что, думаю так — писать проще, а найти коллег в команду, труднее :)

Відповісти
Підтримати
Olexandr Vovchok
undefined pointer 17.10.2016 23:11

Скорость разработки на пхп — выше.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 17.10.2016 23:14

Жигуль дешевле. Все покупаем жигули.

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

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 11:27

та можете набрасывать.
А для бизнеса критичными являются ресурсы: время и деньги, а не какие-то перфекциониские набрасывания программистов.

В среде функциональщиков набросов и против Джавы полно. И кого это интересует, кроме их самих?

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

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 13:19

Все бы гуд, но у пхп и по скорости разработки есть альтернатива — python. А то как определяется язык для бизнеса я знаю(мы ведь не про большой бизнес говорим с кучей аналитиков?). А определяется оно просто — человек идет гуглить, и что самое пропиареное то и выбирает. Потом появляется на пхп всякий абсурд типа попытка заюзать для реста, чата или же даже ентерпрайза(ну это надо сильно накуриться чтобы такое выбрать). Кстати это не только про пхп. Я видел на апворке как жертвы пропаганды джаваскрипт решений под мобайл потом просили переписать нативно.

По поводу Java — да, в ней есть недостатки. Вот С# отбирает у нее рынок уже. А вы говорите что трушность языка не играет роли. Играет, только пиар еще больше играет.

П.С. есть конечно вариант когда в наличии только пхпшники и стараются их заюзать а не переобучать или искать других.

Відповісти
Підтримати
undefined pointer
Anton Khristiansen web back end developer 18.10.2016 13:47
А то как определяется язык для бизнеса я знаю(мы ведь не про большой бизнес говорим с кучей аналитиков?).
А про что мы говорим?
А определяется оно просто — человек идет гуглить, и что самое пропиареное то и выбирает.
Лол, это как? Вот звонит кастомер к аутсорсерам и говорит — я тут погуглил, хочу кароч свое приложение написать \ переписать на Пайтоне! А почему ? Ну дак это ведь круто!

Или наоборот, идет митинг, и тех лид говорит — я кароч, погуглил, будет использовать {% TechnologyName %}, это ща модно!

Так что ли представляете?

А Фейсбук, который юзает пхп — лохи, по вашему? Надо переписать на .net ? А Upwork, который тоже использует PHP как middleware между фронтендом и различными сервисами?

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 13:54
Лол, это как?
решают не девы а тот кто платит. Хотя иногда и девам дают право выбора. Вообще, а почему не питон? Реально? Он чем то уступает пхп? Тем что нельзя арендовать хостинг за 2 доллара в месяц разве что, но мы ведь о сеьезной разработке говорим, верно?
А Фейсбук, который юзает пхп — лохи, по вашему?

Ох, начинается. Почему у пхпшников всегда одно и то же? Фейсбук использовал пхп потому что его создатели тогда знали только пхп. Но после как они разраслись пхп стал непригодным и его уже там переписали полностью, сам пхп. Плюс пхп там только отдает страницы, для большего он совсем не подходит. Все остальное делается на других более производительных языках.

Надо переписать на .net ?
лол, наивный пехапешник, такой наивный:

PHP is used for the front-end, Erlang is used for Chat, Java and C++ are also used in several places (and perhaps other languages as well)

Я ж пишу что ваш пхп только для выдачи страничек ;)

Відповісти
Підтримати
Anton Khristiansen
Anton Khristiansen web back end developer 18.10.2016 14:00
решают не девы а тот кто платит
Разве что на фрилансе, где common way — искать специалиста Вордпресс 5$ час. Нормальные проекты требуют експертизу, за которую тех. специалистам платятся хорошие деньги.
ол, наивный пехапешник, такой наивный:

Как то слабенько набрасываете, старайтесь лучше.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 14:02
Как то слабенько набрасываете, старайтесь лучше.

Как то вы быстро слились.

Остыла ваша гордость
Забыли про Фейсбук
И пхпшная эта крутость
Оказалось просто стук

Відповісти
Підтримати
Anton Khristiansen
Anton Khristiansen web back end developer 18.10.2016 14:05
C быдло-троллями дискуссии не веду. Всего доброго.
Відповісти
Підтримати
Olexandr Vovchok
undefined pointer 18.10.2016 14:38
И пхпшная эта крутость
да как бы 46% Top Million Sites

trends.builtwith.com/framework

вторым идет ASP.NET.
и опять по причине — скорость разработки на нем выше чем например на Джаве.

для позаказной разработки — это очень важный критерий — скорость разработки.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 14:41

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

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

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 14:47
Так спадает использование пхп в вебе
спадет. когда html исчезнет.
Я не спорю про скорость разработки.
ну и замечательно.

а значит — когда скорость разработки на пыхе станет такой же как и на других ЯП, ну тогда да, можно будет говорить о начале спада.

Но не все ищут самую дешевую колбасу просто потому что она дешевле
Всегда и везде.

Дорога ложка к обеду. Если портал можно сделать за 3 месяца, а не за 6, то бизнес предпочтет его сделать за 3.

в третий раз подчеркну — действительности плевать на желания перфекционистов. она идет по пути «наименьшего сопротивления».
и если что-то можно сделать быстрее — то будет делаться быстрее.

а не выбираться какой-нить православный «Haskell».

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

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

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

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 14:50
и на других ЯП, ну тогда да, можно будет говорить о начале спада.

Как то вы однобоко рассуждаете. Но это свойственно фанатам плохих языков.

Всегда и везде.

Мне жаль что вы кушаете колбасу за 50 гривен киллограм.

Если портал можно сделать за 3 месяца, а не за 6, то бизнес предпочтет его сделать за 3.

А потом ломать голову и переписывать все это на норм язык. Знаем эти стори.

Слушайте, ну кому вы лапшу вешаете? Я ведь не блондинка и не ваш потенциальный клиент.

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 14:54
Как то вы однобоко рассуждаете.
это я то? ;)

мне казалось что в вашем лице обрел «упоротого плевателя в пых» :)

Мне жаль что вы кушаете колбасу за 50 гривен киллограм.
который только и может что прибегать к аналогиям. гуманитарий видать. эмоции, чуйства — на первом плане. а не рациональные, холодные рассуждения.
А потом ломать голову и переписывать все это на норм язык. Знаем эти стори.
бывает и так, да.
Я ведь не блондинка
по вашему стилю — я бы сказал обратное :)
Відповісти
Підтримати
Olexandr Vovchok
undefined pointer 18.10.2016 14:30
Он чем то уступает пхп?
конечно :)
Я ж пишу что ваш пхп только для выдачи страничек ;)
это да, никому не нужная задача. зачем в интернете какие-то странички?
Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 14:36
конечно :)

Ну приведите примеры

это да, никому не нужная задача. зачем в интернете какие-то странички?

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

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 14:42
Ну приведите примеры
гуглите и думайте.
вы так пишите, как будто уже все познали, незачем на вас тратиться :)
но с ней и те более мощные языки которые юзаются для серьезной логики подойдут.
да, на C++ тоже можно.

но зачем? уже второй раз спрашиваю. чтобы вас не раздражали реалии действительности? а то ишь — не по вашему мир живет :)

Преимущество пхп для страничек что можно включать код в хтмл.
не только.

то за что ругают пых — и дает ему преимущества в скорости разработки.

У меня вот ассоциация
то ваши проблемы.
обычный снобизм и желание прихвастнуть используем ЯП.

обычно холивары Нечто vs PHP причиной имеют именно психологические проблемы у отстаивающих Нечто, а не технические.
по крайней мере вы это и демонстрируете :)

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 14:46
да, на C++ тоже можно.

Не надо тут тралировать, это оскрбляет мои чувства нелюбви к пхп. Java и C# в помощь, все гуд. На шарпе говорят быстрее пишется чем на джаве, но я еще не успел заценить.

то за что ругают пых — и дает ему преимущества в скорости разработки.

Все верно. быдлокодерство это большое преимущество для пицерий.и разработчиков уровня пицерий. Зачем там исопльзовать какие то стандарты, разделять все это. Так пицерия успешной не станет. А вот куяк куяк и в подакшин это самое оно.

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

Это вы сегодня придумали? Вроде как пхп не любят именно с технической стороны.

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 14:57
Не надо тут тралировать, это оскрбляет мои чувства нелюбви к пхп.
если вы прибегаете к эмоциональным выпадам и аналогиям — которые всегда врут — то этот вывод был закономерен.
Вроде как пхп не любят именно с технической стороны.
раз он массово используется — и в новых проектах, и в новых тяжелых проектах — то что-то с этим тезисом не так. не находите?

а, да

быдлокодерство
да. вы ж джавист? значит быдлокодер! ни асилили Scala!
Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 15:03
если вы прибегаете к эмоциональным выпадам и аналогиям — которые всегда врут — то этот вывод был закономерен.

Ну я ж не виновен что вы не понимаете шуток. Хотя скорее не хотите их понимать. Кстати тут меня поклонники пхп назвали быдлотроллем. Сделаете вывод?)

раз он массово используется — и в новых проектах, и в новых тяжелых проектах — то что-то с этим тезисом не так. не находите?

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

да. вы ж джавист? значит быдлокодер! ни асилили Scala!

Та к сожалению нет, я так, то пробую, это. Уровень моего знания конкретно разработки гораздо меньше чем уровень многих с кем я тут спорю. Но тут хватает моих знаний и понимания, обширности видения ситуации чтобы спорить с вами. Верно?) Суть то простая — люди они везде одинаковые и пользуются не 100% рациональностью, а еще и любви к инструменту и нежеланию признавать что есть что то лучше, плюс лень и т.д. Как я писал программисты не особо отличаются от блондинки с айфоном.

П.С. давайте уже перемирие, как я написал в верху. Мне надоело. лучше ж нам пойти делом занятся.

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 15:29
Кстати тут меня поклонники пхп назвали быдлотроллем.
согласен с ними :D

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

давайте уже перемирие
принимаю. мало ли что вас таких, а в интернете всегда кто-то не прав. а уж о пыхе — так вообще.

просто стало интересно, что-то кроме быдлотроллинга будет? не-а, как оказалось, не будет ничего нового.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 15:35
в интернете всегда кто-то не прав.

Абсолютно верно. Иначе я бы не вступал в споры.

просто стало интересно, что-то кроме быдлотроллинга будет?

Если бы я не приводил аргументов, фактов то меня бы уже давно забанили. Если вам не нравятся эти аргументы и факты то дело не в троллинге(хотя так ли я часто тут троллил? не думаю), а в вашей необъективности. Ладно, расходимся. Удачи ;)

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 15:40
Если бы я не приводил аргументов, фактов то меня бы уже давно забанили.
на доу не банят, насколько я зная.
а то я был бы давно забанен :D я правда тролю по другому.
Если вам не нравятся эти аргументы
аналогии и обвинение в быдлокодерстве — убогие аргументы.
Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 15:44
на доу не банят

Я забыл, но тут удаляют сообщения. Вот сообщения мои бы поудаляли точно если бы там был «быдлотроллинг».

то я был бы давно забанен :D я правда тролю по другому.

Ну конечно.

аналогии и обвинение в быдлокодерстве — убогие аргументы.

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

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

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 16:03
Или вы считаете что быдлокодерства не существует?
я считаю что оно слабо связано с ЯП.

конечно, корреляция есть. например если язык прост в освоении, то на нем будет программировать больше быдлокодеров, чем на более сложном.
вот возьмем Джаву — одной из целей ее создания было добиться бОльшей простоты чем С++.

ну вот быдлокодеров на ней и больше на С++, в процентном отношении от общего числа программистов на ЯП.
Scala — сложней чем Джава, ну вот на ней меньше.

Хз, вроде персонально никого не обвинил в быдлокодерстве.
Так вы на чем пишите, на Джава? ну значит быдлокодер?
Кстати аргументы были
аргументы ваши стопицот лет как известные.

вы их только открыли для себя?

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

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

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 16:11
аргументы ваши стопицот лет как известные.
вы их только открыли для себя?

Ну раз известные то зачем вы пытаетесь оспаривать их?

не подставляйтесь впредь

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

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 16:44
Примеры техники?
авиакомпании предпочитают выплачивать компенсации родственникам погибшим, чем удорожать безопасность полетов до бесконечности. а там есть куда.
Примеры строительства?
тоже самое. если бы здания строить на основе «скелетов» из титана, или еще какого высокопрочного сплава, — то круто было бы.

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

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

а так бы да, уволить нах таких быдлокодеров как вы, да нанять хаскелистов и академиков им в тех лиды...

мечта.

Вот ваш пых это вариант подешевле, чем вы тут аппеллируете постоянно.
да. и джава вариант подешевле чем С++.

хотя ж для высоконагруженных приложений — на С++ можно написать более эффективное в рантайме приложение.

уволить бы джавистов, да дать годы плюсовикам — только экономия на электроэнергии у датацентров — ух какая бы была.

но нет, быдлокодеров на джаве полно, строчат быстрее, вот и — вклад датацентров в глобальное потепление!

ишо раз:
«хлопчыку» — весь твой снобизм на лбу написан.

и в отношении джс тоже.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 17:39

Я не стал читать весь ваш комментарий потому что вы кидаетесь в крайности. Мир сложнее. Давайте закончим.

Про С++ то там совсем другие причины появления джавы а именно безопасность разработки, Хотя игры пишутся на с++, представляете?

«хлопчыку» — весь твой снобизм на лбу написан.
 та я ж так, по доброму кое где чуть троллил. На самом деле у меня нет снобизма, а наоборот, у меня заниженая самооценка.
Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 14:24
Все бы гуд, но у пхп и по скорости разработки есть альтернатива — python.
да, близок.

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

А определяется оно просто — человек идет гуглить, и что самое пропиареное то и выбирает.
и так бывает. но чаще — выбирается то что работает, то что апробировано. это и решений на Джаве касается. Она тоже весьма «пропиаренная» ;)
Я видел на апворке как жертвы пропаганды джаваскрипт решений под мобайл потом просили переписать нативно.
да, вот тут — пиар. решения на джс для мобайл — не апробированы годами.
а за решениями на пыхе или джаве — много лет успешных проектов.
А вы говорите что трушность языка не играет роли.
не такую сильную как хотелось бы программистам :)

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

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

вот если низя, то понятно. а если можно — то зачем?

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 18.10.2016 14:29
но посмотрев что он сейчас из себя представляет — вижу что джависты просто не в курсе причин его живучести.

А что в нем происходит? Ну своровали кое как новых фич у джавы.

зачем искать других, или переобучать — если можно сделать и на пыхе?

Та в данном случае действительно не зачем, даже если вариант не самый лучший.

Відповісти
Підтримати
undefined pointer
undefined pointer 18.10.2016 15:41
Ну своровали кое как новых фич у джавы.
ну да, адепт джавы не в курсе что она вся сама ворованная :D
Відповісти
Підтримати
Olexandr Vovchok
Elance Test 18.10.2016 14:02

Она выше потому что кто-то открывает соединение с базой и делает sql запрос прямо на странице.

Відповісти
Підтримати
undefined pointer
Костя Третяк 16.10.2016 18:38
З усією повагою, javascript хейтер.
Вибачай, Сашко, але рекламувати Go в тебе виходить «не в ту сторону». Увесь оцей твій недбалий стиль письма з мільйонами помилок, усі оці твої приказки «мільони мух не можуть помилитись», «франкенштейн-обрубок» і т.д.... ще залишилось у себе біля аватарки зробити підпис «я вибираю Go!», і вважай 90% із тих, хто читають твої коментарі на рік позбулись бажання експерементувати із Go.
Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 16.10.2016 19:10

Так я до Го не маю ніякого відношення. Я просто знаходжусь в коаліції прихильників нормальних мов програмування. Чесно кажучи я й сам ще пихпихер, все ніяк не зберуся з силами покинути це і пробитися в норм люди, довести до кінця. До речі от тепер замість навчання сиджу на доу в срачах беру участь. Соромно мені.

А от Aliaksandr Valialkin вже є гошником як я зрозумів. Він тут ветеран боїв Go vs Node.js

Відповісти
Підтримати
Костя Третяк
Oleksandr Tkalenko . 16.10.2016 19:50

А что такое в данном контексте «нормальный язык программирования»? И чем он отличается от «ненормальных»?

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 16.10.2016 20:37

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

Відповісти
Підтримати
Oleksandr Tkalenko
Oleksandr Tkalenko . 16.10.2016 21:41

все языки эволюционируют и развиваются. И неважно как они изначально писались, важно — во что они выросли.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 16.10.2016 21:57

Конечно все, но некоторые изначально были нормально спроектированы, спроектированы языками программирования а не чем то для тупого вывода страницы или изменения цвета на странице. Кроме того нормальные языки вводят фичи тоже нормально а не костылями. Увы, PHP is an example of bad design, сколько ты в него не воруй фич с джавы.

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

Жду ответа как и от других — зачем юзать костыли как пхп если есть java, c#, python даже? Оставьте пхп в покое и для тех для кого он был придуман — домохозяек.

Відповісти
Підтримати
Oleksandr Tkalenko
Valentin Nechayev архімаггриб в Дарницькі печери 16.10.2016 22:08

Так где эволюция-то, если все кошмарики (по крайней мере в библиотеке) из статьи про «fractal of bad design» остались, не имеют правильных аналогов и не объявлены deprecated?

Відповісти
Підтримати
Oleksandr Tkalenko
Olexandr Vovchok 16.10.2016 22:36

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

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

Відповісти
Підтримати
Valentin Nechayev
Valentin Nechayev архімаггриб в Дарницькі печери 17.10.2016 09:13
с отсутствием backward compatibility

Ну вот если установить какие-то разумные временны́е рамки (для мира веб+PHP это где-то 4-5 лет), за которым теряется backward compatibility на открыто устарелое, да ещё и пару раз продлить этот срок по настойчивым просьбам — то вполне получится. Только нужны воля и настойчивость...

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 17.10.2016 13:31

Да ничего не получится. Никто не будет ждать 5 лет. Просто возьмут уже хороший язык и все.

Відповісти
Підтримати
Valentin Nechayev
Olexandr Vovchok 16.10.2016 20:40

Самое время для цитатки

PHP is Object Oriented as at PHP 5. However, its just like your old uncle just registered to facebook. ©

Відповісти
Підтримати
Oleksandr Tkalenko
Alexander Baranetsky Software engineer 16.10.2016 17:29

Спасибо за ваш ответ. Очень интересный топик. Вот только поддержу коллегу вопросом: а почему Go не стает таким популярным?

Відповісти
Підтримати
Aliaksandr Valialkin
Olexandr Vovchok 16.10.2016 17:42

Тому що мільйони мух не можуть помилятися.

Відповісти
Підтримати
Alexander Baranetsky
Aliaksandr Valialkin программист в VictoriaMetrics 16.10.2016 23:31

Go стремительно набирает популярность — см. www.google.com/...explore?date=all&q=Golang .
Рост предложений по работе — www.indeed.com/...-q-Nodejs.html?relative=1 .

Відповісти
Підтримати
Alexander Baranetsky
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 00:41

График по Scala неправильный — туда попадает не только язык программирования.

Динамику nodejs vs Go лучше видно по этому графику — www.google.com/...?date=all&q=Golang,nodejs . Отсюда видно, что golang перегонит nodejs через пару лет. Не стоит забывать, чио «golang» — не единственное слово, по которому гуглят Go. Так что go на самом деле уже обогнал nodejs :)

Відповісти
Підтримати
anonymous
anonymous 17.10.2016 00:51

ну по запросу scala на первых позициях только язык. а nodejs вообще никто не гуглит, там больше js + чтото, но там go будет курить в нервной сторонке.

короче, по вашим показателям go нервно курит в сторонку, а если через пару лет go догонит nodejs тогда и пишите, а пока это все глупости

Відповісти
Підтримати
Aliaksandr Valialkin
Oleksandr Tkalenko . 17.10.2016 01:04
Рост предложений по работе — www.indeed.com/...-q-Nodejs.html?relative=1 .
Вот в указанном графике нужно переключиться на абсолютные цифры. Тогда все встанет на свои места.
www.indeed.com/...ds/q-Golang-q-Nodejs.html
Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 08:46

На графике с абсолютными значениями не так заметен взрывной рост Go начиная с 2014 года. Поэтому динамику развития спроса go vs nodejs лучше наблюдать на графике с относительными значениями.

Відповісти
Підтримати
Oleksandr Tkalenko
Alexander Baranetsky Software engineer 17.10.2016 01:10

Хм, спасибо интереные посты. Задумался)

Відповісти
Підтримати
Aliaksandr Valialkin
Костя Третяк 17.10.2016 08:50

Якщо міряти вашою мірялкою, то Laravel — ваще мега фреймворкіще, такий же як і Go. www.indeed.com/...q-laravel.html?relative=1

Відповісти
Підтримати
Aliaksandr Valialkin
Anton Khristiansen web back end developer 17.10.2016 11:03

Грубо говоря, так и есть :). Симфони и Ларавел, построенный на базе первого, являются, по моему теми фреймворками, за которыми будущее PHP.

Відповісти
Підтримати
Костя Третяк
Olexandr Vovchok 17.10.2016 13:33

А других нормальных вариантов и нет в пхп мире. Ларавель берет нишу малых проектов и средних, а симфони для покрупнее. По мне так набор отличный.

Відповісти
Підтримати
Anton Khristiansen
Владимир Котов System Architect 17.10.2016 02:02

1. Node js отлично масштабируется, и загружает все ядра кпу. Зачем shared memory если есть Redis or Memcached, это не php. Если хочется shared memory можно взять чужой говномодуль или написать свой.
2. Не нашел где Го справляется с миллионом конкурентов, нашел где Го справляется с миллионом в минуту. Это два разных миллиона. Асинхронность это круто, потому она есть в Го, и имплементируется в новых версиях других языков, как пример в питоне реализовали идею even loop`а node js. Не можете понять промисы и другие асинхронные заморочки ноды caolan.github.io/asyc в помощь,( и Ваши волосы будут чистыми и шелковистыми))). В любом случае любой обработчик асинхронных событий в итоге вернет колбэк, будь то промис, асинк или другой зверь. Стоит понимать что любой синхронный код — это как зеленый свет на одной улице во всем городе, где на всех других улицах горит красный.
3. Да, потому что Го компилируется. Можно откомпилить node js и попытаться сравнить быстродействие. Хотя пусть Го работает быстрее, надо же ему хоть что-то оставить.
4. Синхронный код легче дебажить, а вот Го дебажить по сравнению с нодой ужас ужасный. Но если хотите сидеть в синхронном коде, то не будет миллиона конкурентов.
5. Я сегодня читал Го код, его сложно понимать, он ни на что не похож и похож на все сразу, опыт других языков будет только мешать. Js напротив похож на Java, С, Ruby, Pyton и его можно сделать похожим на Го. А вот Го нельзя сделать похожим на Js.
6. Программа на ноде компилируется в один исполняемый файл, который не нуждается ни в каких дополнительных зависимостях, в т.ч. не нужна и установка ноды на серверы, где будет работать программа. А можно и не компилить, тогда придется за всем этим следить и работать будет медленнее. Докер ноде не нужен, у докера другие задачи подходящие любому языку.
7. На ноде великолепная экосистема, много модулей, как хороших, так и плохих. Много обучающих материалов nodeschool.io. Много чего работает из коробки. А на Го все придется писать самому.
8. Все в этом мире относительно.

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 10:02
Зачем shared memory если есть Redis or Memcached
Потому что redis или memcached является узким местом в некоторых highload проектах, где нужно делать сотни тысяч запросов в секунду к shared кэшу или kv storage’у.
Не нашел где Го справляется с миллионом конкурентов
у нас в продакшне есть серваки, которые держат более 1.5 миллиона одновременных http keepalive подключений каждый. Подключения принимаются непосредственно программой на go без каких-либо посредников типа nginx/haproxy.
Асинхронность это круто
Асинхронность — это в первую очередь сложно, а потом уже круто.
Стоит понимать что любой синхронный код — это как зеленый свет на одной улице во всем городе, где на всех других улицах горит красный.
Не понял. Можете пояснить другими словами?
Но если хотите сидеть в синхронном коде, то не будет миллиона конкурентов.
Тогда почему у нас в проде серваки на го держат 1.5М одновременных коннекшнов? Там нет асинхронного кода.
Докер ноде не нужен, у докера другие задачи подходящие любому языку.
Какие задачи у докера?
А на Го все придется писать самому.
Большинство программ на Go прекрасно обходится стандартной библиотекой плюс пару внешних зависимостей для работы с БД и другими внешними сервисами. Сравните это с тысячами внешних зависимостей для средней программы на nodejs.
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 16:31
Потому что redis или memcached является узким местом в некоторых highload проектах, где нужно делать сотни тысяч запросов в секунду к shared кэшу или kv storage’у.

Вот тут совсем не понял про что мы сейчас? Redis или memcached изначально и разрабатывались для работы с кешем и key-value. Это тот же shared memory, но только с плюшками и удобствами. И опять же повторяюсь, Вам нужен shared memory есть готовые модули для ноды, не устраивают они пишите свой. Где ограничения, в чем аргумент?

у нас в продакшне есть серваки, которые держат более 1.5 миллиона одновременных http keepalive подключений каждый. Подключения принимаются непосредственно программой на go без каких-либо посредников типа nginx/haproxy.

А кто/что балансирует серваки? Сколько серваков? Какого типа запросы? Какой транспорт? Нода так же может принимать запросы без nginx/haproxy они выступают в роли балансировщиков.

Не понял. Можете пояснить другими словами?

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

Тогда почему у нас в проде серваки на го держат 1.5М одновременных коннекшнов? Там нет асинхронного кода.

Я не знаю архитектуры Вашей системы, 1.5м запросов может вообще не от Го зависеть.

Какие задачи у докера?
Наверное проще Вам доку глянуть, но одна из его задач это инкапсуляция, создание изолированной среды для приложения.
Большинство программ на Go прекрасно обходится стандартной библиотекой плюс пару внешних зависимостей для работы с БД и другими внешними сервисами. Сравните это с тысячами внешних зависимостей для средней программы на nodejs.

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

Відповісти
Підтримати
Aliaksandr Valialkin
Yury Gavrilenko 17.10.2016 17:03

Го повністю асинхронний, причому асинхронніст менеджиться за вас. Якщо горутина зависла в очікуванні відповіді, з каналу, з іо, не суть важливо — то управління переходить наступній горутині.
За рахунок цього ядра використовуються максимально ефективно, при чому оверхед по пам’яті та часу на перемикання набагато менший, аніж у випадку з системними тредами.

Відповісти
Підтримати
Владимир Котов
Дмитро 17.10.2016 17:52

Go ничего нету кроме горутин — как и во всем остальном безальтернативность, и все видели в соседнем топе как он сливается вчистую асинхронному .net/java коду с тред пулом при работе на коротких задачах, да в каких-то случаях контекс свитч может и быстрее и хайлоад лучше, больше подключений — но никто массово не будет перескакивать обратно решать все бизнес задачи с настолько деревянным императивным стилем кода из 90х как в Go, когда все тренды в этом направлении ведут к максимально декларативному стилю, который эконом время и деньги.

Відповісти
Підтримати
Yury Gavrilenko
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 19:09
Вот тут совсем не понял про что мы сейчас? Redis или memcached изначально и разрабатывались для работы с кешем и key-value. Это тот же shared memory, но только с плюшками и удобствами.

Для сохранения объекта во внешнем процессе наподобие memcached и redis нужно выполнить следующие операции:
1) Сериализовать объект в массив байт.
2) Отправить массив байт в подключение к memcached.
3) Дождаться ответа «все готово» от memcached.

Memcached, в свою очередь, должен:
1) Считать массив байт из клиентского подключения.
2) Распарсить его.
3) Сохранить результат в кэше.
4) Отправить ответ «все готово» клиенту.

Похожий набор операций необходим и при чтении объекта из memcached.

Если держать shared кэш прямо в памяти процесса, где работает ваш сервер, то из вышеописанных шагов остается только третий шаг для memcached — «сохранить результат в кэше». Таким образом, избавляемся от здоровенного оверхеда на вышеуказанные операции.

И опять же повторяюсь, Вам нужен shared memory есть готовые модули для ноды, не устраивают они пишите свой. Где ограничения, в чем аргумент?
Прикол в том, что в гоу shared cache делается в 10 строчек кода на базе стандартного map’а и стандартных примитивов синхронизации. А в ноде нужно костылить с помощью сторонних глючных и неудобных в использовании говномодулей.
А кто/что балансирует серваки? Сколько серваков? Какого типа запросы? Какой транспорт?
Сейчас балансировка идет с помощью DNS round robin. В ближайшем будущем собираемся переходить на client-side балансировку — это когда клиент сам выбирает сервер, с которым будет потом общаться. Клиенты отправляют обычные http get-запросы по keep-alive соединениям. Каждый из серверов держит по 1.5М одновременных соединений: 
# ss -s
Total: 1482066 (kernel 1482443)
TCP:   1614487 (estab 1480880, closed 125740, orphaned 6732, synrecv 0, timewait 125643/0), ports 0

Transport Total     IP        IPv6
*	  1482443   -         -        
RAW	  0         0         0        
UDP	  18        14        4        
TCP	  1488747   1488744   3        
INET	  1488765   1488758   7        
FRAG	  0         0         0
Пока в синхронном подходе не завершиться операция, все остальные операции будут ждать ее завершения. Го дает параллельность только благодаря ядрам, т.е. больше, чем количество ядер параллельных потоков быть не может (Поправьте если ошибаюсь)
Т.е. по-вашему мы используем сервера с 1.5М ядрами CPU каждый? :) Ниже вам уже объяснили, почему вы ошибаетесь.
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 20:22

А причем тут потоки к соединениям? У Вас 1,5М конкурентных параллельных потоков?

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

Тот же DNS round robin механизм применим к ноде, потому использовать это как аргумент против round robin nginx, то же слабовато. Вы уверены что нода не сможет удержать 1лям конкурентов по keep alive? Лень гуглить, но в какой-то статье по ноде речь шла о 10 лямах соединений. Но опять же не суть, я про то что нода умеет тоже самое. То, что горутины автоматом тушатся и переподнимаются в случае затыка, решает тот же pm2 у ноды.

P.S. Я не говорил что специалист в Го, потому и попросил чтобы меня поправили если мое предположение неверно. И передергивать меня не нужно. Вы гость в этом топике, и все сообщения о Го это офтоп, потому придерживайтесь элементарных правил приличия.

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 20:55
А причем тут потоки к соединениям? У Вас 1,5М конкурентных параллельных потоков?
Каждое соединение обрабатывается отдельным потоком. Я об этом вроде уже писал в предыдущих комментариях.
Відповісти
Підтримати
Владимир Котов
Olexandr Vovchok 17.10.2016 21:25

Кстати я читал об этом где-то, и что это очень хорошо. Плюс в Го нет колбек хела, все намного проще пишется. Как раз прошел вчера раздел C# async где тоже все сделано очень удобно в процедур стайл. Правда пока только в теории знаю.

Відповісти
Підтримати
Aliaksandr Valialkin
Oleksandr Tkalenko . 17.10.2016 23:37

async/await присуствует в stage 3 драфте следующей версии ES tc39.github.io/ecmascript-asyncawait

пока что его вполне можно заменить генераторами и промисами — тот же самый процедурный стиль. www.promisejs.org/generators

Відповісти
Підтримати
Olexandr Vovchok
Yuri Karadzhov Software Engineer 18.10.2016 20:17

async/await в es2017 proposal и будет в node7

Відповісти
Підтримати
Oleksandr Tkalenko
Владимир Котов System Architect 17.10.2016 21:47

Зачем Вы меня путаете, горутины это не потоки. И каждая горутина блокирует io. У Вас 1м горутин, а не тредов. Сами будете гуглить, надеюсь. То что Вы имеете 1м горутин блокирующих io, не означает что это нельзя сделать меньшим количеством тредов при помощи асинхронного подхода. Вы сравниваете мягкое с теплым. Тем более это хорошо будет работать если запросы небольшие, но не факт что синхронный механизм не создаст проблему при увеличении длительности ответа, ведь Ваша горутина заблокирует io, с одной стороны вроде у Вас есть параллельность, но с другой стороны это магия, который Вы не управляете.

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

Я вижу что у Вас нет понимания что такое нода и зачем она нужна, но у Вас есть опыт работы с Го и свое понимание зачем нужен он. У меня нет знаний Го, но читая доку я вижу, что нода и Го использует разные подходы при обработке io. Это хорошо, что принципы разные, для каких-то задач будет хорош Го, для каких-то нода. Давайте оканчивать этот холивар, так как для более глубокого сравнения мне нужно углубиться в Го, а Вы как я вижу, не хотите углубляться в ноду. Потому это контрпродуктивно.

Отвечу цитатой Kaveh Shahbazian, по крайне мере он знает две технологии и может их сравнить:

I’m currently using Go for implementing TCP servers and some high performance Web APIs and Node.js for the web and mobile app.

I started with Go but after using TypeScript I’m using Node.js too.

Відповісти
Підтримати
Aliaksandr Valialkin
Костя Третяк 17.10.2016 22:04
I started with Go but after using TypeScript I’m using Node.js too.

О! Свої люди!

Відповісти
Підтримати
Владимир Котов
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 22:20
Зачем Вы меня путаете, горутины это не потоки.
Горутины ничем не отличаются от потоков с точки зрения прикладного программиста, пишущего на Go. Отличия становятся видны, если спуститься на уровень среды исполнения (aka runtime). А туда спускаются только разработчики самого Go — прикладным программистам там делать нечего. Разработчики же nodejs ошибочно решили, что обычные прикладные программисты разберутся с асинхронностью — в результате получили callback hell плюс кучу костылей, полностью не решающих эту проблему.
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 22:25

Колбэк хел был до версии ноды 0.6, примерно в это время был написан async, и колбэк хел исчез. Позже появились промисы в ноде. Сейчас нода аж 6.8 разница в 3-4 года, вы бы еще jquery c Ангуларом сравнивали.
У ноды другой подход, ей не нужно создавать горутины, чтобы обработать соединения. нода в одном потоке будет обрабатывать тучу соединений.

Відповісти
Підтримати
Aliaksandr Valialkin
Alexander Baranetsky Software engineer 17.10.2016 22:27
У ноды другой подход, ей не нужно создавать горутины, чтобы обработать соединения. нода в одном потоке будет обрабатывать тучу соединений.

То есть, если прилитело 1000 реквестов. Она их будет в очередь ставить?

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 22:38

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

Відповісти
Підтримати
Alexander Baranetsky
Alexander Baranetsky Software engineer 17.10.2016 22:43
нода будет обрабатывать их параллельно
Это как это? о_О паралельное испольнение на одном потоке? Тогда получает не должно возникать проблем с синхронизацией Shared memory?
Відповісти
Підтримати
Владимир Котов
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 21:16
у Го нет более стандартных вещей, и список будет достаточный длинный.
Перечислите хотя бы три полезных вещи, которые есть в ноде, но отсутствуют в гоу.
Відповісти
Підтримати
Владимир Котов
Olexandr Vovchok 17.10.2016 21:29

1. на нем могут писать фронтендщики
2. фронтендщикам не надо изучать что то еще кроме javascript
3. фронтендщики счастливы возможности делать что то еще кроме эффектиков на странице

Лови гоист гранату! Какие вам еще нужны даказательства што нода рулит???

Відповісти
Підтримати
Aliaksandr Valialkin
Alexander Baranetsky Software engineer 17.10.2016 21:32

Вы это серьезно? Вам приходилось когда нить выбирать технологии на которые потом будут опираться десятки людей каждый день?

фронтендщики счастливы возможности делать что то еще кроме эффектиков на странице
И насколько они способны за 3-4 недели сделать стабильный сервис который будет обслуживать 2-3к qps?
Відповісти
Підтримати
Olexandr Vovchok
Костя Третяк 17.10.2016 21:43
2-3к qps

Це «детский лепет», щоправда якщо не вдаватись до збочень.

Раніше я заради інтересу порівнював PHP7 vs. Node.js 4.4.7, так на хелоуворді Restify, на чотирьох ядрах (в кластерному режимі), робить більше 4 запитів за секунду.

Відповісти
Підтримати
Alexander Baranetsky
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 21:25
Вы уверены что нода не сможет удержать 1лям конкурентов по keep alive? Лень гуглить, но в какой-то статье по ноде речь шла о 10 лямах соединений.
Нода будет жрать память и тормозить при таком количестве одновременных соединений, т.к. v8, движок ноды, заточен под браузеры, а не под сервер с миллионом коннекшнов и миллионами мелких долгоживущих объектов, как в кэше.
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 21:51

Горутина 4к, нода 10к на запрос. 1мл горутин помещается в 4GB памяти, значит для ноды нужно будет 10GB. На 128GB нода выдержит 12млн. конкурентов. При таком подходе Го выглядит привлекательнее, но если учесть все его недостатки, я все же выберу ноду. По крайне мере смогу уйти в отпуск или на больничный.

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 22:31
1мл горутин помещается в 4GB памяти, значит для ноды нужно будет 10GB. На 128GB нода выдержит 12млн. конкурентов.
Нода начинает жутко тормозить при хипе больше 1Гб, а вы тут рассуждаете о каких-то 128Гб :) Go же отлично справляется с таким объемом хипа, т.к. специально заточен под это. Например, у нас в продакшне прекрасно работают сервисы с 50Гб хипом. Могли бы разрастить его до сотен гигабайт, но это на данный момент экономически неэффективно.
При таком подходе Го выглядит привлекательнее, но если учесть все его недостатки, я все же выберу ноду. По крайне мере смогу уйти в отпуск или на больничный.
Что это за недостатки у Go? И как Go влияет на отпуск с больничным?
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 17.10.2016 22:43

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

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 23:42
Писать на Го большое приложение с ветвистой логикой сложнее, чем на js
Спасибо, посмеялся
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 18.10.2016 01:00

Это не мое мнение, посмеялись над своей безграмотностью. Я же говорил, Го не знаю.

Відповісти
Підтримати
Aliaksandr Valialkin
Костя Третяк 18.10.2016 11:35
Нода начинает жутко тормозить при хипе больше 1Гб

Зараз не можу у свіжій документації знайти, але раніше читав ось таке (обмеження на одне ядро):

the memory limit can be bumped to ~1GB on 32-bit systems and ~1.7GB on 64-bit systems

Можливо такі ліміти були раніше, схоже зараз такого вже немає.

Відповісти
Підтримати
Aliaksandr Valialkin
Владимир Котов System Architect 18.10.2016 12:38

—max-old-space-size=8192 решает эту проблему. Если на сервере при 128GB 32 ядра, то на одно ядро нужно 4GB.

Відповісти
Підтримати
Костя Третяк
Artyom Krivokrisenko 20.10.2016 05:23
На 128GB нода выдержит 12млн. конкурентов
Какой там лимит по памяти в ноде?
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 20.10.2016 18:23

нас егодняшний день лимиты сняты, даже не нужно прописывать max-old-space-size. Есть лимит на размер буфера в 2GB.

Відповісти
Підтримати
Artyom Krivokrisenko
Владимир Котов System Architect 20.10.2016 18:24

На сегодняшний день лимитов нет, даже не нужно прописывать max-old-space-size. Limit буфера 2ГБ.

Відповісти
Підтримати
Artyom Krivokrisenko
Дмитро 17.10.2016 20:23
Если держать shared кэш прямо в памяти процесса, где работает ваш сервер, то из вышеописанных шагов остается только третий шаг для memcached — «сохранить результат в кэше».
Прикол в том, что в гоу shared cache делается в 10 строчек кода на базе стандартного map’а и стандартных примитивов синхронизации.
Сейчас балансировка идет с помощью DNS round robin.

как кеш между серверами под балансировщиком синхронизируеться\инвалидируеться?

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 21:02

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

Відповісти
Підтримати
Дмитро
Дмитро 17.10.2016 21:17

Так синхронизации кеша нету? локальный сервер один что ли?

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 21:40

Не понял вопроса. Если вы о синхронизации доступа к кэшу из разных потоков, то там стандартный мьютекс используется.

Відповісти
Підтримати
Дмитро
Дмитро 17.10.2016 22:13

я не про это. У вас есть шардинг и локальный сервер с кешом in process. Но, из того что описано выше у вас нету всего, что есть в redis для нормальной работы нагруженной системы например:
* кластера;
* репликации;
* persistance;
Я правильно понял?
Представим кейс — локальный сервер упал в описаной выше системе с быстрым кешом на go. Что происходит дальше?

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 23:26

Давайте еще раз. За одним доменным именем стоит несколько http-серверов. Запросы распределяются между серверами согласно dns round robin.

Внутри каждого сервера есть самописный in-process кэш, представляющий из себя небольшую надстройку над стандартным map’ом.

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

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

Відповісти
Підтримати
Дмитро
Дмитро 18.10.2016 02:28

При все прочих нюансах все равно не понятно, как работает ваш round robin, когда сервера под ним не имеют избыточного Кеша, и при этом ещё и умудряются обрабатывать большинство запросов в рамках одного правильного сервера. Звучит как магия какой не видали самые матёрые функциональщики на Scala.

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 18.10.2016 09:32

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

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

Відповісти
Підтримати
Дмитро
Дмитро 18.10.2016 13:33

так в чем профиты? если в вашей системе можно хранить 90% требуемого для работы с системой состояния клиента в сессии на одном сервере — это удача, а не заслуга хорошо проектированного кеша или уж тем более языка.
Чем меньше эти условия удовлетворяються со стороны требований — тем больше это решение становиться аналогичным другим распределенным кешам с доп сетевыми запросами и сериализацией. Ваш велосипед мало кому подойдет, не несет никаких инновационных подходов и явно не тянет на то что бы стоять в ряд с редисом или мемкешем с точки зрения реализации да и думаю SLA.

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 18.10.2016 20:07
Ваш велосипед мало кому подойдет, не несет никаких инновационных подходов и явно не тянет на то что бы стоять в ряд с редисом или мемкешем с точки зрения реализации да и думаю SLA
Наш велосипед отлично справляется с возложенными на него обязанностями. В отличие от memcache и redis, от которых пришлось отказаться при нагрузке в 10К запросов в секунду на сервер. Сейчас у нас под 200К запросов в секунду на сервер.
Відповісти
Підтримати
Дмитро
Дмитро 18.10.2016 21:38

Это ж обычный MemTable — он бы держал не меньше коннекшинов и на Java только памяти бы выжрал побольше. Это конечно преимущество, но если бы у Golang не было этих особенностей, он бы нахер никому не нужен был. Из всех кто использует хеш-мапы, вы наверное первый, кто решил им всерьез заменить редис — думаю это не очень удачная компания за популяризацию Golang.

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 18.10.2016 22:25
Из всех кто-то использует хеш-мапы, вы наверное первый, кто решил им всерьез заменить мемкеш и редис — думаю это не очень удачная компания за популяризацию Golang
Зато это позволило сэкономить на хостинге в 20 раз.
Відповісти
Підтримати
Дмитро
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 19:17
Я не знаю архитектуры Вашей системы, 1.5м запросов может вообще не от Го зависеть.

1.5М не запросов, а одновременных соединений. Запросов всего 1М в секунду суммарно на все серверы — grafana.videe.tv/...uEX8WgaornADBRR7FDR0mpqAv :)

Відповісти
Підтримати
Владимир Котов
Alexander Baranetsky Software engineer 17.10.2016 19:45
Потому что redis или memcached является узким местом в некоторых highload проектах, где нужно делать сотни тысяч запросов в секунду к shared кэшу или kv storage’у.
+1. Просто прочитали мою боль) Только запросов пока еще не милионы. Но к 1000 уже приблизились)
у нас в продакшне есть серваки, которые держат более 1.5 миллиона одновременных http keepalive подключений каждый. Подключения принимаются непосредственно программой на go без каких-либо посредников типа nginx/haproxy.
Мне кажется я бы по такое писал свой HTTP сервер (не обтяженный оверхедами). На С++ или Java)
Відповісти
Підтримати
Aliaksandr Valialkin
Владимир Котов System Architect 21.10.2016 20:02

Прочел книгу по Го, прошел тур на оф сайте. И решил сравнить Го с нодой.
Условия задачи просты:
1. HelloWolrd server
2. Максимальное колличество паралелльных запросов к этому серверу
3. Сервер и генератор запросов на одном тазике с двумя ядрами.

Node JS
В начале уперся в 4к-5к конкурентов, но это известная проблема 10к, так как и сервер и генератор запросов на одном тазике, они вместе как раз и упираются в этот лимит. Включил keepAlive:
Finish time: 261003.732ms
concurrent: 400 000.
Хотел конечно сделать 500к, но так как 400к обрабатываются долго, остановился на этом значении. На все про все ушло чуть больше часа кодинга с тестами и перекурами.

GoLang
На первом этапе уперся в пакетный менджер, я вот до сих не понимаю зачем тянуть с собой все глобальные зависимости?! Но, может я недоразобрался, так как нуб.

На втором этапе уперся в так называемую синхронную модель Го, после которой горутины не стартанули. Оказывается, мое приложение вышло до момента старта горутин. Ладно, пофиксил.

Далее возникла проблема остановить Горутины. Оказывается, нужно зкарывать канал, но когда закрываешь канал следуюшая горутина не может туда ничего посылать, и бросается ошибка, что канал уже закрыт. Т.е. не понимая асинхронный механизм писать горутины все же нельзя. Ок, пофиксил и это, при помощи sync.WaitGroup, привет промисам и калбэкам из ноды. И о ужас, оказывается при возврате горутины приходиться ставить defer, нужно же же как-то обрабатывать response от сервера и ошибки. Снова привет ноде и калбэкам с промисами. Глянул я на получившийся код, и понял, что он мне что-то напоминает. А ведь если после defer поставить еще defer, а после него еще, то получиться defer hell.)) Причем если учесть, что у Го нет тернарных операций, а только if, и сама горутина вызывается анонимной самовызывающейся функцией, плюс обработка ошибок в defer`ах получется такая себе всеми нелюбимая лесенка. Конечно, код можно организовать иначе, для всего сделать функции обработчики. А лучше вынести все в пакет. Но все что связано с пакетами и его структурами, наследованием и областью видимости в них называется магией. Опыт других языков бесполезен.

Следующая проблема возникла на пустом месте, долго не мог обработать os.Args аргументы командной строки, стринга отказывалась конвертиться в инт. Гугуление не приносило результатов, так как в основном отвечали такие же нубы как и я, но потом оказалось все очень просто. _ помогло не сойти мне сума, и избавило меня от обработки ошибки от неудачного преобразования стринги в инт.

Вроде все работает, запустился мой генератор запросов. Прошел лимит в 5к конкурнетов:
time elapsed: 1.588817224s concurrent: 5000
против нодовского генератора:
finish time: 1.353331s
concurrent: 5000
Т.е. нода даже оказалсь быстрее. Я тестировал оба hello world сервера, отдавали они примерно одинаково. Нода была чуть шустрее, но не значительно.

Улыбнулся скорости Го, но понятно что 5к запросов это не нагрузка. Да и у меня не сервер. Продолжил тесты и Го лихо перевалил за 10к, и тут я задумался куда делось ограничение в 10к конкурентов. Ладно, в Го все под капотом.

На 13к получил ошибку too many open files, ага! Хотя не понятно почему ulimit, который по умолчанию 1024 сработал на 13к?! Ну ок, поправил ulimit и на 14к вылезла ошибка: connect: cannot assign requested address. Странно, нода была послушнее и ласковее ко мне, но там был keepAlive. А тут хз, включен он или нет.

Оказалось решается Timeout:0 в http.Client, были там слова про keppAilve что-то. Но я проигнорировал и где-то на 19к получил ту же ошибку.

Ладно, нужно тюнить MaxIdleConnsPerHost. Дошел до 24к.

Окей, следует DisableKeepAlives:true. И тут я задумался выключить keppAlive чтобы стало больше конкурентов? Это что же за магия то такая? В Ноде включить, а в Го выключить?

For client requests, setting this field prevents re-use of
TCP connections between requests to the same hosts, as if
Transport.DisableKeepAlives were set.

Потом меня заставили прописать http.DefaultClient.Timeout = timeout *time.Second. Далее я плясал выставляя эти таймауты и MaxIdleConnsPerHost, и у меня погас свет.))) Вроде случайность, но на перегруженном тазике мне удалось сделать:
time elapsed: 5.202161006s concurrent: 30000

УРА! Скорость супер, хочу еще. Но больше повторить этот успех у меня не вышло. Пляски мои возвращали меня обратно то 13к, то к 24к, но не 30к. Я уже был готов к эмуляции 400к, хоть как-то. Но запустить 400к паралельных запросов из коробки, как мне обещали у меня не вышло.

Вывод:
Го по сравнению с нодой выглядит очень молодо, эко система слабая. Нет устоявшихся практик, ошибки гугляться плохо, много нубских ответов. Пакеты все обрезанные, martini с его 400 строками против нескольких тысяч express нервно курит в сторонке. Все плюшки к которым привык, и которые считаются просто стандартными придется писать самому. Язык не интуитивно понятный, в некоторых случаях совсем неочевидный.
Я конечно понимаю, что где-то есть некрономикон по Го, и куча всего крутого в сумрачном инете, но при быстром гуглении этого не найти. Не верьте, что на Го можно писать без знаний асинхронного механизма и понимания как работает система. Сесть и быстро что-то наваять на Го не получится. А если говорить про чужой опыт, то Го тяжело поддерживается. Приложение валится от неочевидных проблем, та же заблокированная синхронная горутина способна вызвать шквал проблем и влияет на все остальные горутины. В теории все хорошо, а на практике как оказалось в нубских руках Го хуже, чем нода.

Відповісти
Підтримати
Aliaksandr Valialkin
Oleksandr Tkalenko . 21.10.2016 20:11

Было бы интересно еще на код взглянуть.

Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 21.10.2016 20:31

На Гошный или Js? На самом деле, заруба была что на Го легко пересесть, и все прям из коробки работает, а у js callback hell и промисы непонятные. Я дал отчет по первому дню изучения Го, понятное дело языка не знаю и делал по примерам. Но хз, пройдет время, и мне вдруг начнет нравится Го, а тут мой нубский код. Можете вопросы наводящие позадавать, или рассказать, где подводные камни могут быть. Но код показывать, мне не хочется. Я делал just for fun, становиться мишенью для троллей, коих тут рассадник не хочется. Или могу Вам на почту скинуть, и можем общение перенести туда.

Відповісти
Підтримати
Oleksandr Tkalenko
Oleksandr Tkalenko . 21.10.2016 22:06
и можем общение перенести туда.
Ноу проблем. Можно в ФБ (линка в моем профиле), можно по почте (oleksandr.tkalenko в гмейле).
Відповісти
Підтримати
Владимир Котов
Aliaksandr Valialkin программист в VictoriaMetrics 23.10.2016 20:53
На Гошный или Js?
На js код. Тогда подскажем, как улучшить код на Go.
Відповісти
Підтримати
Владимир Котов
Aliaksandr Valialkin программист в VictoriaMetrics 23.10.2016 20:51

Классно, что попробовали программировать на Go и описали свой опыт. Ничего, что с первого раза не вышло — с течением времени все получится. Go как наркотик — для привыкания достаточно одной дозы :)

Відповісти
Підтримати
Владимир Котов
Olexandr Vovchok 24.10.2016 00:19

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

Відповісти
Підтримати
Aliaksandr Valialkin
Yury Gavrilenko 24.10.2016 10:17

І не згадуйте. Я довго плювався і хейтив еррніли, але здогадайтесь на чому пишу свою штуку.
Для штук, для яких він створений — неймовірно затягує.

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 25.10.2016 00:07
На втором этапе уперся в так называемую синхронную модель Го, после которой горутины не стартанули. Оказывается, мое приложение вышло до момента старта горутин.
Да, это типичные грабли для начинающих — при выходе из функции main завершается вся программа, даже если перед этим было запущено миллион горутин.
Далее возникла проблема остановить Горутины.
Горутина автоматически останавливается при выходе из функции, запущенной в этой горутине.
Оказывается, нужно зкарывать канал, но когда закрываешь канал следуюшая горутина не может туда ничего посылать, и бросается ошибка, что канал уже закрыт.
Да, есть такая особенность. После первых неудачных попыток станут понятны следующие вещи:
1) Каналы не являются серебряной пулей — не нужно пихать их везде, где только возможно. На самом деле каналы можно использовать в очень ограниченном наборе случаев.
2) Если при проектировании программы предполагается закрытие канала, то в этот канал должна писать только одна горутина и только эта горутина должна закрывать канал. Количество читающих горутин может быть произвольным.
Т.е. не понимая асинхронный механизм писать горутины все же нельзя.
Не уловил связи между асинхронностью и горутинами.
Ок, пофиксил и это, при помощи sync.WaitGroup, привет промисам и калбэкам из ноды.
Опять не понял связи между sync.WaitGroup и промисами с калбэками из ноды.
И о ужас, оказывается при возврате горутины приходиться ставить defer, нужно же же как-то обрабатывать response от сервера и ошибки. Снова привет ноде и калбэкам с промисами.
В первый раз слышу, что при выходе из горутины нужно ставить defer. Вообще, defer, как и каналы, нужны в очень ограниченном наборе случаев. К сожалению, новички переоценивают их применимость.
И откуда опять взялись калбэки с промисами? Понимаю — тяжело отвыкать от программирования на node.js :)
сама горутина вызывается анонимной самовызывающейся функцией
 В горутине можно запустить любой метод либо функцию — не обязательно анонимную.
Но все что связано с пакетами и его структурами, наследованием и областью видимости в них называется магией. Опыт других языков бесполезен.
Согласен — сначала тяжело, т.к. это не похоже на другие языки программирования. Но через пару дней начинаешь понимать всю мощь механизмов Go и ущербность других языков программирования :)
Следующая проблема возникла на пустом месте, долго не мог обработать os.Args аргументы командной строки, стринга отказывалась конвертиться в инт.
См. flag.Int.
_ помогло не сойти мне сума, и избавило меня от обработки ошибки от неудачного преобразования стринги в инт
Тоже распространенная ошибка новичков — ошибки нужно обрабатывать, а не игнорировать или скрывать, как это принято в node.js :) Из-за этого в node.js такая жесть с невнятными сообщениями об ошибках и дебаггингом.
Я конечно понимаю, что где-то есть некрономикон по Го, и куча всего крутого в сумрачном инете, но при быстром гуглении этого не найти.
Читайте официальную документацию — там есть ответы на все ваши вопросы.
Не верьте, что на Го можно писать без знаний асинхронного механизма и понимания как работает система.
Опять не понял, причем тут асинхронность?
Сесть и быстро что-то наваять на Го не получится.
С первого раза может не получиться. Как и в любом другом языке программирования. Со второго точно получится :)
А если говорить про чужой опыт, то Го тяжело поддерживается.
Это вы с чего такой вывод сделали? У меня диаметрально противоположные сведения. Go изначально проектировался для использования в больших долгоживущих проектах, над которыми работают тысячи программистов (aka для внутреннего использования в гугле).
Приложение валится от неочевидных проблем, та же заблокированная синхронная горутина способна вызвать шквал проблем и влияет на все остальные горутины. В теории все хорошо, а на практике как оказалось в нубских руках Го хуже, чем нода.
Согласитесь, что благодаря тому, что го моментально валится при неправильном использовании, вы моментально находили косяки в ваших нубских программах. В отличие от node.js, где некорректный код зачастую превращается в хорошо замаскированную мину замедленного действия, которая «взырвается» в самый неподходящий момент через пару месяцев в продакшне. И для выявления которой нужно будет потратить несколько дней работы профессиональных программистов node.js.
Відповісти
Підтримати
Владимир Котов
Владимир Котов System Architect 25.10.2016 14:21
Не уловил связи между асинхронностью и горутинами.
дык она прямая, горутины это асинхронный механизм.
Согласен — сначала тяжело, т.к. это не похоже на другие языки программирования. Но через пару дней начинаешь понимать всю мощь механизмов Go и ущербность других языков программирования :)
Это очень субъективно, люди коптели над патернами и бест практисами, а тут пришел Го и все в мусорник. Когда начинаешь писать на Го складывается ощущение, что пишешь с поломанными пальцами. Вообще не понимаю как можно написать что-то большое без ООП.
Опять не понял связи между sync.WaitGroup и промисами с калбэками из ноды.
wg.Add(1) то же что и new Promise(function(resolve, reject)

wg.Done() то же что и reslove() reject()
wg.Wait() то же что и обработчик then

Тоже распространенная ошибка новичков — ошибки нужно обрабатывать, а не игнорировать или скрывать, как это принято в node.js :) Из-за этого в node.js такая жесть с невнятными сообщениями об ошибках и дебаггингом.
Это у Вас желание есть такое, видеть в собеседнике недопрограмиста, вероятно потребность в самоутверждении высока, отсюда и выводы ошибочные.
Зачем вообще давать возможность программисту обрабатывать ошибку приведения типов? Если тип невозможно преобразовать это критическая ошибка, дальше приложение работать не должно, потому кидается экзепшн. Для принудительной обработки таких ошибок во всех мажорных языках есть try catch, но Го не такой. Ему нужно навязывать эту обработку, и даже не важно что считается нормой потом делать err=nil. Это недостаток языка.

Не удивлюсь если скоро появиться троллинг Го x,err = 2+2

В первый раз слышу, что при выходе из горутины нужно ставить defer.
defer нужно ставить в обработчик запроса. Вы прочли первую часть предложения, и упустили вторую часть, там после запятой продолжение.)))
Согласитесь, что благодаря тому, что го моментально валится при неправильном использовании, вы моментально находили косяки в ваших нубских программах. В отличие от node.js, где некорректный код зачастую превращается в хорошо замаскированную мину замедленного действия, которая «взырвается» в самый неподходящий момент через пару месяцев в продакшне. И для выявления которой нужно будет потратить несколько дней работы профессиональных программистов node.js.

Я могу только согласиться, что если ошибка возникнет в асинхронном куске кода стэк ошибки ужасен в ноде. К примеру, на одном знакомом проекте на Го, неделю искали переполнение буфера, возврат ошибок был не очевиден. Так что, Ваше заключение субъективно.

Асинхронность тяжело пишется, дебажится и поддерживается. Но хоть Вы и не понимаете этого, когда Вы пишете на Го, Вы пишете асинхронный код, который так же пишется и на ноде. И работает асинхронно.

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 25.10.2016 17:15
горутины это асинхронный механизм.
В каком месте он асинхронный? Повторю еще раз — горутины ничем не отличаются от обычных потоков операционной системы с точки зрения прикладного программиста. Единственное отличие — в Go можно запустить миллион одновременно исполняющихся потоков без потерь в производительности. Для обычных потоков ОС, которые используются в других языках программирования, потолок составляет пару тысяч. Дальше начинается трэш — потоки сжирают всю память под стэк и все время процессора тратится на переключение между потоками вместо выполнения полезной работы.
Когда начинаешь писать на Го складывается ощущение, что пишешь с поломанными пальцами.
Не беспокойтесь — это ощущение обычно проходит через пару дней программирования на Go. Затем такое же ощущение будет при переключении с Go на node.js :)
Вообще не понимаю как можно написать что-то большое без ООП.
Так никто же не мешает — Go поддерживает ООП. Просто он немного другой — там нет наследования, конструкторов и перегрузки методов, т.к. программисты склонны создавать больше проблем с помощью этих «фич», чем решать. Зато там есть усовершенствованные интерфейсы.
wg.Add(1) то же что и new Promise(function(resolve, reject)
wg.Done() то же что и reslove() reject()
wg.Wait() то же что и обработчик then
Пусть будет так, раз вы привыкли к промисам. Хотя взаимосвязь притянута за уши — промисы на порядок сложнее.
Зачем вообще давать возможность программисту обрабатывать ошибку приведения типов? Если тип невозможно преобразовать это критическая ошибка, дальше приложение работать не должно, потому кидается экзепшн
Вообще-то это не преобразование типов, а парсинг числа из строки. В строке может быть все что угодно. Поэтому удобно возвращать ошибку, которая обычно тут же и обрабатывается. Сравните, что проще для понимания:
try {
    n = parseInt(s)
}
catch (err) {
    logError("cannot parse s=%q: %s. Using zero value", s, err)
    n = 0
}

или

if n, err = parseInt(s); err != nil {
    logError("cannot parse s=%q: %s. Using zero value", s, err)
    n = 0
}
defer нужно ставить в обработчик запроса. Вы прочли первую часть предложения, и упустили вторую часть, там после запятой продолжение.)))
Вы имеете ввиду «defer resp.Body.Close()»? Так можно просто написать resp.Body.Close() после чтения resp.Body. defer может понадобиться только в двух случаях:

— Для гарантированного освобождения ресурсов при выходе из функции, если функция содержит много строчек с return’ами. Без defer’а придется перед каждым return’ом копипастить код для освобождения ресурсов.
— Для перехвата panic’ов с помощью recover() внутри defer’а. Некоторые пытаются использовать этот механизм в качестве замены эксепшнов. Не стоит так делать — panic’и должны валить приложение, чтобы баги в коде можно было быстро обнаружить и починить, а не спрятать в пустом catch’е, как это принято в node.js и java :)

К примеру, на одном знакомом проекте на Го, неделю искали переполнение буфера, возврат ошибок был не очевиден
Может, кто-то просто по привычке игнорировал обработку ошибок в Go, пряча их за _? Иначе ошибка была бы мгновенно обнаружена, локализирована и исправлена.
Но хоть Вы и не понимаете этого, когда Вы пишете на Го, Вы пишете асинхронный код, который так же пишется и на ноде
 Не вижу ни одного признака асинхронного кода в моем коде на Go — калбэков, промисов, async / await’ов и state machines.
Відповісти
Підтримати
Владимир Котов
Alex Koshterek погромизд 25.10.2016 18:26

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

Відповісти
Підтримати
Aliaksandr Valialkin
Владимир Котов System Architect 25.10.2016 23:07
Единственное отличие — в Go можно запустить миллион одновременно исполняющихся потоков без потерь в производительности.

Там очередь стоит из миллиона потоков? События могу быть только двух видов синхронными, и асинхронными. Синхронные события, блокирующие, ожидающие завершения блокирующей операции. Раз Го стартует на всех ядрах, а он таки стартует => ядра работают асинхронно, и горутины работают асинхронно.

Сложность понимания этого механизма заключается в том, что на одном ядре стартует не одна горутина. Го создает логические процессоры и на них стартует GOMAXPROCS горутин. Как только поток с каким-то количеством горутин встречает блокирующую операцию, блокируется весь поток. Потому на уровне логического процессора горутины асинхронны, а на уровне горутин в потоке горутины синхронные.

Пусть будет так, раз вы привыкли к промисам. Хотя взаимосвязь притянута за уши — промисы на порядок сложнее.

Да ничем они не сложнее. Если существует много разных вариантов использования промисов, это не означает что самый для Вас простой неверный.

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

Может, кто-то просто по привычке игнорировал обработку ошибок в Go, пряча их за _?

Ну-да, все вокруг идиоты.

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 26.10.2016 18:59
Пример с try catch нужен в очень редких случаях, зачем его запиливать в язык, не ясно.
Тоже этого не понимаю. К счастью, в Go нет try catch :)
Відповісти
Підтримати
Владимир Котов
Olexandr Vovchok 17.10.2016 13:35

Не говорите ерунду. Го намного, намного быстрее работает чем нода(счет идет в несколько раз, вплоть до 10 если хорошо помню). Погуглите бенчмарки. Тут даже вопрос не стоит. Найдите какой то получше аргумент. Ибо именно из за относительной тормознутости ноды и начали переписывать на го.

Відповісти
Підтримати
Владимир Котов
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 16:08

Вот ссылка на бенчмарки для ленивых и тех, кого забанили в гугле — www.techempower.com/...12&hw=peak&test=plaintext .

Результаты:
— nodejs: 314,418 запросов в секунду
— go: 6,371,358 запросов в секунду

Отставание ноды от гоу — 20 раз.

Відповісти
Підтримати
Olexandr Vovchok
Костя Третяк 17.10.2016 16:17

Я бачу у Go результат кращій, але трохи менше ніж в тричі (926,099). Ви написали мабуть результат для fasthttp-postgresql, який начебто написано на Go. Не знаю як може щось працювати швидше, ніж на рідному веб-сервері Go, fasthttp-postgresql мабуть же якийсь кеш видає...

Відповісти
Підтримати
Aliaksandr Valialkin
Aliaksandr Valialkin программист в VictoriaMetrics 17.10.2016 18:48

Никакого кэша там нет — см. PlaintextHandler в github.com/...http/src/common/common.go .

Відповісти
Підтримати
Костя Третяк
Владимир Котов System Architect 17.10.2016 16:10

Ну да, кусочек кода работает в 10 раз быстрее, а из-за синхронности мы ждем пока завершится операция и проигрываем сотни раз. Компильте ноду, получайте профит и от скорости, и от асинхронности. Но у меня нет столько времени холи варить и говорить одно и то же. Каждая технология заточена на что-то свое, и если использовать инструмент для своих задач, то выигрыш будет больше, что логично. В чем-то выигрывает нода, в чем-то Го. Но кричать во всю нода говно, берите Го — не конструктивно и не этично.

Відповісти
Підтримати
Olexandr Vovchok
Olexandr Vovchok 17.10.2016 18:52
Но кричать во всю нода говно, берите Го — не конструктивно и не этично.

Хорошо что кричать

эпоха JavaScript everywhere уже идет, нравиться это мне/Вам/кому-то или нет

очень умно. Во как бывает когда прижимают, приходится уже идти на мировую :)

Відповісти
Підтримати
Владимир Котов
Aliaksandr Valialkin программист в VictoriaMetrics 24.10.2016 20:03

Вот еще один бенчмарк, где node.js со swift’ом проиграли Go почти в 20 раз — github.com/valyala/swift-response

Відповісти
Підтримати
Olexandr Vovchok
Vladimir Krasulya Web Dev в Ciklum 27.10.2016 00:02

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

Відповісти
Підтримати
Aliaksandr Valialkin
Alexander Baranetsky Software engineer 17.10.2016 19:43
Зачем shared memory если есть Redis or Memcached
Для быстрой обработки некторого «горячего» массива информации, который при этом имеет высокие требования к консистентности. В Связке PHP + Redis (или + MySQL/PostgreSQL) хз как сделать реально быстрое и консистентное при этом решение....

Aliaksandr Valialkin

Потому что redis или memcached является узким местом в некоторых highload проектах, где нужно делать сотни тысяч запросов в секунду к shared кэшу или kv storage’у.
Відповісти
Підтримати
Владимир Котов

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.