.NET Fest: полная программа конференции на сайте. Присоединяйся к самому большому .NET ивенту
×Закрыть

Переход на NodeJS

Добрый день!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

у кого то руки из жоп* растут
поэтому
на ней так принято писать

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

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

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

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

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

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

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

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

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

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

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

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

фанатизме и нежелании изучить что то еще.
Читайте внимательно топик, пожалуйста. Про ноду я спрашиваю как альтернативу Java, C++ :)

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

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

Как бы я не оптимизировал код на 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... (це сторонні, нерідні модулі ноди).

PHP — багатопоточна

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

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

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

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

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

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

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

Це я десь трохи проспав чи ви пишете повну дурницю?
C добрым утром.
github.com/krakjoe/pthreads

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

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

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

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

try {
    var azaza = my.unknown.property;
} catch (e) {
    var azaza = 'вообще похрен';
}

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

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

req.hasOwnProperty('body')

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

меньшим знаниям необходимым чтобы что то налепить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но это весьма странно писать код который не проверяет ошибки, и менеджеры процессов тут не помогут. Если объекта req.body в вашем обработчике может не быть — эту ситуацию нужно обработать, а не рассчитывать, что и так сойдет.
Ну тут разные подходы есть, «let it crash» лично мне кажется довольно логичным.
stackoverflow.com/...ophy-applicable-elsewhere

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

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

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

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

Нода конечно может отдавать страницу при помощи тех же шаблонизаторов, но лучше сделать синглпейдж, а ноде оставить работу с данными. Часто делают Angular/React + Node JS REST API
До смешного уже доходит. Звучит будто нода не может отрендерить страничку и нужно делать только синглпэйдж. Кстати вопрос. А можно на ноде сделать сайт новостей? Например www.bbc.com

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

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

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

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

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

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

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

Плюс Джавистам удобнее переходить на ts, чем на js.

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

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

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

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

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

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

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

Просто надстройка над обычным жс

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

Рили, это уже сектантство какое-то.
Кто бы говорил :)
это лишь пиар акция от фанатов. Как видим которая не получила успех

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

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

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

Вы будете спотыкаться об js постоянно до тошноты.

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

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

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

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

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

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

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

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

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

Если проект написан грамотно

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

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

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

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

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

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

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

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

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

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

Держать двух синьйоров вместо одного фулстэк...
я думаю це малоімовірно поки що. оскільки бекенд все таки не тільки простий круд а маса інших систем тих же баз даних. Фронт тоже постійно ускладнюється

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Посмотрите в сторону Elixir...

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

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

интересное у тебя понимание вопроса)
если хочешь расширить кругозор — погугли как это сделали в асп с помощью тред пула

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

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

потоки заняты ожиданием ввода/вывода или еще какого внешнего события

все дело в коде ->
Решается грамотным асинхронным программированием

спасбо за комментарий

смотреть на загрузку проца
на потребление памяти

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

хибернейт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

отсутствует строгость типов
PHP 7, strict mode? Не, не слышал

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

. Вы действительно верите что пехопешники начнут это юзать?
Я и моя молодая пехопешная команда умпешно используем PHP 7 со строгой типизацией на новом проекте, так что мой ответ — да. По поводу
правила кодирования.
, с теми, кто упорно не соблюдает PSR 2 — 4, на текущем месте работы расстаются после исп. срока. А еще мы используем SOLID и другие страшные слова и обычно при тех. собесе потенциальному разработчику подсовывают примеры с кодом и просят обьяснить, где тот или иной принцип SOLID нарушен и почему.

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

используем PHP 7 со строгой типизацией на новом проекте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лол, это как?
решают не девы а тот кто платит. Хотя иногда и девам дают право выбора. Вообще, а почему не питон? Реально? Он чем то уступает пхп? Тем что нельзя арендовать хостинг за 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)

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

решают не девы а тот кто платит
Разве что на фрилансе, где common way — искать специалиста Вордпресс 5$ час. Нормальные проекты требуют експертизу, за которую тех. специалистам платятся хорошие деньги.
ол, наивный пехапешник, такой наивный:

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

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

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

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

C быдло-троллями дискуссии не веду. Всего доброго.
И пхпшная эта крутость
да как бы 46% Top Million Sites

trends.builtwith.com/framework

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

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

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

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

Так спадает использование пхп в вебе
спадет. когда html исчезнет.
Я не спорю про скорость разработки.
ну и замечательно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как то вы однобоко рассуждаете.
это я то? ;)

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

Мне жаль что вы кушаете колбасу за 50 гривен киллограм.
который только и может что прибегать к аналогиям. гуманитарий видать. эмоции, чуйства — на первом плане. а не рациональные, холодные рассуждения.
А потом ломать голову и переписывать все это на норм язык. Знаем эти стори.
бывает и так, да.
Я ведь не блондинка
по вашему стилю — я бы сказал обратное :)
Он чем то уступает пхп?
конечно :)
Я ж пишу что ваш пхп только для выдачи страничек ;)
это да, никому не нужная задача. зачем в интернете какие-то странички?
конечно :)

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

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

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

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

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

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

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

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

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

да, на C++ тоже можно.

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

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

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

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

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

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

а, да

быдлокодерство
да. вы ж джавист? значит быдлокодер! ни асилили Scala!
если вы прибегаете к эмоциональным выпадам и аналогиям — которые всегда врут — то этот вывод был закономерен.

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

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

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

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

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

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

Кстати тут меня поклонники пхп назвали быдлотроллем.
согласен с ними :D

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

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

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

в интернете всегда кто-то не прав.

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

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

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

Если бы я не приводил аргументов, фактов то меня бы уже давно забанили.
на доу не банят, насколько я зная.
а то я был бы давно забанен :D я правда тролю по другому.
Если вам не нравятся эти аргументы
аналогии и обвинение в быдлокодерстве — убогие аргументы.
на доу не банят

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

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

Ну конечно.

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

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

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

Или вы считаете что быдлокодерства не существует?
я считаю что оно слабо связано с ЯП.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

мечта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну своровали кое как новых фич у джавы.
ну да, адепт джавы не в курсе что она вся сама ворованная :D

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

З усією повагою, javascript хейтер.
Вибачай, Сашко, але рекламувати Go в тебе виходить «не в ту сторону». Увесь оцей твій недбалий стиль письма з мільйонами помилок, усі оці твої приказки «мільони мух не можуть помилитись», «франкенштейн-обрубок» і т.д.... ще залишилось у себе біля аватарки зробити підпис «я вибираю Go!», і вважай 90% із тих, хто читають твої коментарі на рік позбулись бажання експерементувати із Go.

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

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

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

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

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

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

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

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

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

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

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

с отсутствием backward compatibility

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

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

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

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

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

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

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

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

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

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

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

Рост предложений по работе — www.indeed.com/...-q-Nodejs.html?relative=1 .
Вот в указанном графике нужно переключиться на абсолютные цифры. Тогда все встанет на свои места.
www.indeed.com/...ds/q-Golang-q-Nodejs.html

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

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

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

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

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

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. Все в этом мире относительно.

Зачем shared memory если есть Redis or Memcached
Потому что redis или memcached является узким местом в некоторых highload проектах, где нужно делать сотни тысяч запросов в секунду к shared кэшу или kv storage’у.
Не нашел где Го справляется с миллионом конкурентов
у нас в продакшне есть серваки, которые держат более 1.5 миллиона одновременных http keepalive подключений каждый. Подключения принимаются непосредственно программой на go без каких-либо посредников типа nginx/haproxy.
Асинхронность это круто
Асинхронность — это в первую очередь сложно, а потом уже круто.
Стоит понимать что любой синхронный код — это как зеленый свет на одной улице во всем городе, где на всех других улицах горит красный.
Не понял. Можете пояснить другими словами?
Но если хотите сидеть в синхронном коде, то не будет миллиона конкурентов.
Тогда почему у нас в проде серваки на го держат 1.5М одновременных коннекшнов? Там нет асинхронного кода.
Докер ноде не нужен, у докера другие задачи подходящие любому языку.
Какие задачи у докера?
А на Го все придется писать самому.
Большинство программ на Go прекрасно обходится стандартной библиотекой плюс пару внешних зависимостей для работы с БД и другими внешними сервисами. Сравните это с тысячами внешних зависимостей для средней программы на nodejs.
Потому что 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.

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

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

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

Вот тут совсем не понял про что мы сейчас? 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 каждый? :) Ниже вам уже объяснили, почему вы ошибаетесь.

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

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

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

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

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

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

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

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

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

Зачем Вы меня путаете, горутины это не потоки. И каждая горутина блокирует 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.

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

О! Свої люди!

Зачем Вы меня путаете, горутины это не потоки.
Горутины ничем не отличаются от потоков с точки зрения прикладного программиста, пишущего на Go. Отличия становятся видны, если спуститься на уровень среды исполнения (aka runtime). А туда спускаются только разработчики самого Go — прикладным программистам там делать нечего. Разработчики же nodejs ошибочно решили, что обычные прикладные программисты разберутся с асинхронностью — в результате получили callback hell плюс кучу костылей, полностью не решающих эту проблему.

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

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

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

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

нода будет обрабатывать их параллельно
Это как это? о_О паралельное испольнение на одном потоке? Тогда получает не должно возникать проблем с синхронизацией Shared memory?
у Го нет более стандартных вещей, и список будет достаточный длинный.
Перечислите хотя бы три полезных вещи, которые есть в ноде, но отсутствуют в гоу.

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

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

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

фронтендщики счастливы возможности делать что то еще кроме эффектиков на странице
И насколько они способны за 3-4 недели сделать стабильный сервис который будет обслуживать 2-3к qps?
2-3к qps

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

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

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

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

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

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

Писать на Го большое приложение с ветвистой логикой сложнее, чем на js
Спасибо, посмеялся

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

Нода начинает жутко тормозить при хипе больше 1Гб

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

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

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

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

На 128GB нода выдержит 12млн. конкурентов
Какой там лимит по памяти в ноде?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ваш велосипед мало кому подойдет, не несет никаких инновационных подходов и явно не тянет на то что бы стоять в ряд с редисом или мемкешем с точки зрения реализации да и думаю SLA
Наш велосипед отлично справляется с возложенными на него обязанностями. В отличие от memcache и redis, от которых пришлось отказаться при нагрузке в 10К запросов в секунду на сервер. Сейчас у нас под 200К запросов в секунду на сервер.

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

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

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

Потому что redis или memcached является узким местом в некоторых highload проектах, где нужно делать сотни тысяч запросов в секунду к shared кэшу или kv storage’у.
+1. Просто прочитали мою боль) Только запросов пока еще не милионы. Но к 1000 уже приблизились)
у нас в продакшне есть серваки, которые держат более 1.5 миллиона одновременных http keepalive подключений каждый. Подключения принимаются непосредственно программой на go без каких-либо посредников типа nginx/haproxy.
Мне кажется я бы по такое писал свой HTTP сервер (не обтяженный оверхедами). На С++ или Java)

Прочел книгу по Го, прошел тур на оф сайте. И решил сравнить Го с нодой.
Условия задачи просты:
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 нервно курит в сторонке. Все плюшки к которым привык, и которые считаются просто стандартными придется писать самому. Язык не интуитивно понятный, в некоторых случаях совсем неочевидный.
Я конечно понимаю, что где-то есть некрономикон по Го, и куча всего крутого в сумрачном инете, но при быстром гуглении этого не найти. Не верьте, что на Го можно писать без знаний асинхронного механизма и понимания как работает система. Сесть и быстро что-то наваять на Го не получится. А если говорить про чужой опыт, то Го тяжело поддерживается. Приложение валится от неочевидных проблем, та же заблокированная синхронная горутина способна вызвать шквал проблем и влияет на все остальные горутины. В теории все хорошо, а на практике как оказалось в нубских руках Го хуже, чем нода.

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

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

и можем общение перенести туда.
Ноу проблем. Можно в ФБ (линка в моем профиле), можно по почте (oleksandr.tkalenko в гмейле).
На Гошный или Js?
На js код. Тогда подскажем, как улучшить код на Go.

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

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

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

На втором этапе уперся в так называемую синхронную модель Го, после которой горутины не стартанули. Оказывается, мое приложение вышло до момента старта горутин.
Да, это типичные грабли для начинающих — при выходе из функции 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.
Не уловил связи между асинхронностью и горутинами.
дык она прямая, горутины это асинхронный механизм.
Согласен — сначала тяжело, т.к. это не похоже на другие языки программирования. Но через пару дней начинаешь понимать всю мощь механизмов 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.

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

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

горутины это асинхронный механизм.
В каком месте он асинхронный? Повторю еще раз — горутины ничем не отличаются от обычных потоков операционной системы с точки зрения прикладного программиста. Единственное отличие — в 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но кричать во всю нода говно, берите Го — не конструктивно и не этично.

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

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

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

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

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

Зачем shared memory если есть Redis or Memcached
Для быстрой обработки некторого «горячего» массива информации, который при этом имеет высокие требования к консистентности. В Связке PHP + Redis (или + MySQL/PostgreSQL) хз как сделать реально быстрое и консистентное при этом решение....

Aliaksandr Valialkin

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

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