Да нет. Как минимум в микро-сервисной архитектуре. В идеале не должно быть общих зависимостей. Ни моделей данных базы, ни dto, ни чего либо еще. Все должно быть по максимуму независимым.
Создание зависимостей, как вы их не назовите - останутся зависимостями и может выйти боком. Версионирование, разный цикл разработки и релизов различных сервисов в конце упрется в эти зависимости.
Хотя возможно для каких-то проектов это и будет работать.
Вот убейте меня, но я все никак не пойму. Бэкендисты столько страдали, чтобы прийти к таким паттернам архитектуры как микросервисы, разделения всего и вся - от базы до моделей и обратно. И все равно придет кто-то да и посоветует делать shared dependencies.
И как бы сексуально это не выглядело, по моему личному опыту shared stuff это всегда проблемы. Это всегда зависимость от чего-то или кого-то еще.
Я тоже жаловался раньше. Все дураки. Подумаешь там формочку исправить. Это ж минутное дело. А теперь сам работают в сравнительно большом стартапе. У нас этих маленьких проблем в бэклоге - лет на 10 хватит. Поэтому прекрасно понимаю почему где-то есть глюки и их не исправляют.
В конце концов это все приорити и естимейшены, и вы с вашим опытом должны то это понимать.
По мне так влияние количество правок на направление зависимостей выглядит странно. ИМХО контекст намного важнее. А то по вашей логике, если у меня есть http клиент который инжектится но изменяется часто, я должен инжектить бизнес логику в него?
В любом нормально языке Circular Dependency решается 2мя способами.
1. Объединение 2ух файлов/классов вотевер в одине файл/класс/пекедж 2. Интерфейсами
Потому что есть легаси. Потому что фреймворки меняются. Есть фреймворки без встроенной магии DI контейнеров. Если нужно либу написать/подправить и т.д. Забери фреймворк, и человек беспомощен.
Не все же простенькие крад ендпоинты пишут. Есть вещи чуть посложнее, и хотелось бы чтобы человек понимал принципы. Фреймворк должен быть лишь инструментом.
Понимая принципы мне например все равно на каком фреймворке писать. Я их даже не "учу". Для меня это такая же "либа" с документацией.
А вот когда человек не понимает принципов, он реально "учит" фреймворк...
На бэкенде JS тоже самое. Приходит человек который работал с фреймворком X. Начинаешь спрашивать че да как там. Ну вот например вроде человек и знает что есть такая штука как dependency injection, а для чего он в принципе нужен объяснить не может. Вот он умеет им пользоваться во фреймворке, и все. Забери фреймворк - и начнутся обычные require() везде и вся... потому что человек учил фреймворк а не общие принципы и практики.
Мне кажется что в больших компаниях процессы в принципе настолько медленные что ожидание билда от нескольких часов до нескольких дней это норма.
А вот в небольших компаниях и стартапах где надо очень быстро делать деливери, очень чувствуется когда ты на задачу потратил 5 минут и потом пол дня деплоишь это чудо.
Понятно что с микро-репозиториями свои проблемы и сложности. Но там они возникают в конкретных случая и как бы выше на уровне шеред стафф и интерфейсов взаимодействия.
Да, если возможно в монорепо сделать так что реально тестируется только код который изменился и только сервисы использующие эти тесты то по идее нужно будет только ждать тесты при создании пиара (при условии что другие команды реально коммитят только в свои файлики и они не затронут тебя и не затриггерят твои тесты). Тогда придется ждать только мерж который в принципе быстрый. Вот только это сложно сделать в монорепо с монолитом + отдельные сервисы + shared dependencies и т.д. Ну и nodejs в придачу =))
Рально не знаешь где выстрелит. Поэтому приходится прогонять все тесты и билдить все и вся внутри :/
Решили что отдельные репы будет быстрее организовать. Хотя да, не очень удобно для разработчика. Когда все стянул с одного репо и у тебя все в одной папочке, удобнее. Но вроде привыкли уже. Но самое главное что боль уходит и теперь свои фичеры можно задеплоить за 5 минут.
Еще отдельная боль как результат того что билдится все и вся в монорепо - со временем появились тесты которые падают рендомно и никто не знает как их чинить. А те кто их писал уже не работают тут. Бывает задеплоить одну строчку кода берет пол дня потому что оно падает а ответственного за этот код хрен найдешь.
з.ы.
Возможно это только я замечаю, но мне кажется что отдельные репо тоже могут стать боттлнеком который в конце концо перевесит боттлнеки монорепо. Возможно при 200+ репо лучше подождать монорепо. Поэтому сейчас мы не делаем репо пер сервис а что-то вроде репо пер домейн где в своем домене можно шерить код, и там находятся свои воркеры, скедулеры и хттп сервисы. Но мы не ентерпрайз, еще стартап. Что будет лет через 5? Кто знает... Просто не первый раз читаю статьи о возвращении к монорепо но вот четкие метрики по которым можно принять решение не вижу.
У нас раз в 1000 меньше кода, разработчиков и пул реквестов. Но мы деплоим в веб. И мы ушли от монорепо. Еще не до конца, ибо распиливаем. Но новые сервисы в новых рипо по доменам. Не суть.
Одна из главных причин ухода от монорепо это ожидание своей очереди мержа в мастер и последующего деплоя.
То есть:
Ты создал пиар
Запустились тесты и если все хороше можешь мержить
Но пока твои билды бежали кто то уже замержил свой бранч в мастер, и там соответственно опять пробегаются тесты, билд и т.д.
Делаешь апдейт мастера в свой бранч и ждешь опять пока все тесты пробегут
Пытаешь опять замержить в мастер - а там опять кто то успел свой бранч запихнуть.
Надоело... Почему я должен ждать всех если изменения у меня в моем небольшом сервисе?
Понятно что можно автоматизировать. Но все равно придется ждать всех. А мы стартап. И так много проблем а тут еще и деплой ждать чтобы потом проверить все ли там норм.
С отдельными репо, небольшими, ты не зависишь от других команд и разработчиков.
Сколько у вас разработчик ждет от нажатия кнопки "деплой" (не уверен что это слово подходит в вашем случае) до нотификации - готово?
Я так понимаю в ваших масштабах билды как в интеле могут бежать от нескольких часов до суток и ожидание каких-то пару часов мержа вообще не проблема?
Возьмите любой стартап до 4 лет. Да и старше, если стартап все еще не выстрелил и нет денег на переписывание. Там будет все это и еще больше. Вот вам навскидку:
Логи? Нахрен надо. Х...к х..к и в продакшен. Кому нужны эти логи?
Тернарный оператор - чем длиннее строка тем лучше. А еще если там функция вызывает функцию с параметром где тоже тернарный оператор и вызывается другая функция - это будет вишенкой на торте.
Прочитал про функциональное программирование? Давай засовывай замыкание и каррирование где надо и где не надо. А, мутации... точно, делай клон всему и вся, память то бесконечная. А еще ко всему этому прицепи какую нибудь либу типа рамды и стримов, чтобы никто не смог продебажить это творение.
Используй везде и только примитивы и булианы. Ведь если функция которая что-то проверяет возвращает false, вряд ли завтра или даже сегодня ты захочешь знать почему она вернула false. А передавать 10+ параметров в функцию однозначно лучше упаковки их в объект... объекты они страшные. А деньги можно и в переменно price передавать. И рядом отдельную переменную currency. Зачем еще один лишний объект в системе.
Возвращай разные объекты из функций. Это круто когда ты можешь получить массив когда результатов много, и один объект когда результат один.
Так же у тебя есть возможно назвать параметр функции listingId, и в функции проверять если там массив то делай одно, а если нет - другое. Ведь нет вероятности того что следующая функция будет понимать только стринг а не массив, и что кто-то просто туда предаст это переменную.
Проходясь по легаси коду стартапов где главное - быстро в продакшен все пихнуть, можно книгу написать...
Как рассказал Singh в беседе с Stat News, отчасти проблема в том, как разрабатывался алгоритм Epic. Он диагностирует сепсис, исходя из момента выставления врачом счета на лечение, что необязательно совпадает с моментом, когда пациент впервые ощутил симптомы.
За эту бизнес идею наверное кто-то еще и бонус получил...
А вообще, глядя на то как разработчики относятся к алертам, особенно к ложным срабатываниям, я уже представляю врачей которые игнорят сообщения о потенциальной проблеме у пациента... но надеюсь я неправ и врачи ответственнее нас.
Возьму на заметку. Как раз у нас в компании поняли что написание и поддержка документации это тоже работа. Но, мы уже год не можем выбрать единственную платформу которая подходила бы для
1. Написания сухой документации аля отправьте это — получите то
2. Описания юз кейсов и различных флоу
3. Публикацию бест практис в виде статей
4. Хороший поиск
5. Вставка и форматирование кода
6. Можно было бы разделять внутреннюю документации дл] инженеров от публичной которую мы даем партнерам.
Сейчас у нас документация разбросана по гиту (wiki), wix и собственный статический сайт где нужно коммитить изменения в репо и деплоить.
Спасиб. Ща глянул, он вроде как даже умеет с консулом дружить, где у нас регистрируются сервисы. Надо будет поиграться. Retries, rate limit, circuit breaker. Вкусная штука. Будем обсуждать с девопсами =)
Сколько хочу попробовать кип элайв или http/2 во внутренних коммуникациях между сервисами, но у нас балансировка на уровне DNS. У вас нет такой проблемы автоскелинга и балансировки запросов?
Писать балансировку на клиенте не хочется, а ставить лоад балансер чтобы он держал конекшены и балансил все девопс пока не хочет…
'use strict';
var isOdd = require('is-odd');
module.exports = function isEven(i) {
return !isOdd(i);
};
Который состоит из
'use strict';
const isNumber = require('is-number');
module.exports = function isOdd(value) {
const n = Math.abs(value);
if (!isNumber(n)) {
throw new TypeError('expected a number');
}
if (!Number.isInteger(n)) {
throw new Error('expected an integer');
}
if (!Number.isSafeInteger(n)) {
throw new Error('value exceeds maximum safe integer');
}
return (n % 2) === 1;
};
Который состоит из
'use strict';
module.exports = function(num) {
if (typeof num === 'number') {
return num - num === 0;
}
if (typeof num === 'string' && num.trim() !== '') {
return Number.isFinite ? Number.isFinite(+num) : isFinite(+num);
}
return false;
};
Где-то мир свернул не туда…
Насчет безруких разработчиков. Тут проблема не в безруких. Проблема в разных. С разным бэкграундом, целями, возможностями, хотелками, опытом и т.д. И вот тут та свобода и «простота» которую дает JS выходит боком.
От части да. Именно поэтому в пхп начали появляться Type declarations.
Но добавьте к этому еще то что весь хайп зарождался фронтендерами которые теперь могли писать бэкенд. Писали как умели. Добавьте к этом коллбэки и промисы и вообще асинхронную модель. Никаких тебе паттернов написания бэкенд сервисов. Синглтоны наше все. Тесты? О да. Давайте вначале нахреначим кода нетестируемого, а потом придумает JEST который магией поможет протестировать это все.
Если в в любом статическом языке вы 100 раз будете думать использовать ли рефлекшен, то услышать от JS разработчика «давай метапрограммирование здесь заюзеам, классная штука, я тут на конференции увидел» это нормально. Он даже не понимает какие последствия всего этого могут быть. Не хватает того что язык динамический и ты можешь себе выстрелить в голову через ногу, есть люди которые не боятся, как бы это сказать, возвести эту проблему в степень.
Да, согласен, поднять серверок за 2 минуты это круто. Запилить крад апи прямо в базу с монгуси, еще 5 минут. И если это изначально маленький проектик, то нет проблем. Но для больших проектов надо понимать, что за все придется платить.
И это я еще не говорю про то что многие не понимают разницу между CPU bound/IO bound. А если начинают понимать, начинают пизать решения типа форков, от которых меня тошнит.
Многие не доходили до проблема когда GC тупо съедает все CPU потому что такое количество инлайновых обьектов и стрингов создается что он не успевает очищать память…
Рефактор без компилятора, и даже с тестами — то еще удовольствие.
Мы вот нахавались, начали внедрять Type Script с надеждой что хоть часть проблем он уберет. С оставшимися научимся жить.
Проблема в том что многие пишут на JS скриптики или что-то простенькое, и не всегда доходят до проблем реальных приложений с нагрузкой и большой кодовой базой. Вот они будут хвалить JS.
Люди с опытом уже не так сильно будут радоваться тому что вебсервер поднять на експрессе с монго в 100 раз быстрее чем на жаве или дот нет, если знают что им нужно будет в будущем это поддерживать. Потому-что понимают во что это позже выльется. А если написать, и через 2-3 годика свалить, то норм. Уже не твои проблемы. Уже другому придется объяснять почему переименовать филд в проекте это месяц работы…
Но опять же, для POC или простых проектов, особенно IO Bound нода свою работу делает.
P.S.
А еще я всегда ржу что винда на пентиуме быстрее поднимается чем билд и приложение на ноде с +100500 зависимостями =)
Стоит. На нем все еще пилят вебсервера. Но, если это с нуля пописать годик-два, это одно. А если вы придете в проект где сервисы на ноде прошли через руки 10-20 человек, да поможет вам бог в поддержке этого чуда. Вы будете молиться на каждом деплое и станете верующим. Возможно даже уйдете в монастырь =)
Вы будете мечтать о компиляторе каждый раз когда будет прилетать эксепшен или блокер из-за самых тупых вещей. Когда весь проект написан на объектах, без нормальных моделей данных, вы будет открывать любую функцию, смотреть на параметры типа options, и гадать — а что там внутри?
Есть огромная разница между людьми которые пишут POC на JS и прыгают со стартапа в стартап и никогда не доходят до момента когда простенький POC вырос в гиганта и теперь кому-то с этим жить.
Да нет. Как минимум в микро-сервисной архитектуре. В идеале не должно быть общих зависимостей. Ни моделей данных базы, ни dto, ни чего либо еще. Все должно быть по максимуму независимым.
Создание зависимостей, как вы их не назовите - останутся зависимостями и может выйти боком. Версионирование, разный цикл разработки и релизов различных сервисов в конце упрется в эти зависимости.
Хотя возможно для каких-то проектов это и будет работать.
Вот убейте меня, но я все никак не пойму. Бэкендисты столько страдали, чтобы прийти к таким паттернам архитектуры как микросервисы, разделения всего и вся - от базы до моделей и обратно. И все равно придет кто-то да и посоветует делать shared dependencies.
И как бы сексуально это не выглядело, по моему личному опыту shared stuff это всегда проблемы. Это всегда зависимость от чего-то или кого-то еще.
Переубедите меня Ж)
Я тоже жаловался раньше. Все дураки. Подумаешь там формочку исправить. Это ж минутное дело. А теперь сам работают в сравнительно большом стартапе. У нас этих маленьких проблем в бэклоге - лет на 10 хватит. Поэтому прекрасно понимаю почему где-то есть глюки и их не исправляют.
В конце концов это все приорити и естимейшены, и вы с вашим опытом должны то это понимать.
По мне так влияние количество правок на направление зависимостей выглядит странно. ИМХО контекст намного важнее. А то по вашей логике, если у меня есть http клиент который инжектится но изменяется часто, я должен инжектить бизнес логику в него?
В любом нормально языке Circular Dependency решается 2мя способами.
1. Объединение 2ух файлов/классов вотевер в одине файл/класс/пекедж
2. Интерфейсами
Потому что есть легаси. Потому что фреймворки меняются. Есть фреймворки без встроенной магии DI контейнеров. Если нужно либу написать/подправить и т.д. Забери фреймворк, и человек беспомощен.
Не все же простенькие крад ендпоинты пишут. Есть вещи чуть посложнее, и хотелось бы чтобы человек понимал принципы. Фреймворк должен быть лишь инструментом.
Понимая принципы мне например все равно на каком фреймворке писать. Я их даже не "учу". Для меня это такая же "либа" с документацией.
А вот когда человек не понимает принципов, он реально "учит" фреймворк...
ИМХО
На бэкенде JS тоже самое. Приходит человек который работал с фреймворком X. Начинаешь спрашивать че да как там. Ну вот например вроде человек и знает что есть такая штука как dependency injection, а для чего он в принципе нужен объяснить не может. Вот он умеет им пользоваться во фреймворке, и все. Забери фреймворк - и начнутся обычные require() везде и вся... потому что человек учил фреймворк а не общие принципы и практики.
Pegasus производства израильской компании
NGOмогли оказаться телефонные номера Макрона и 14 других глав государств.NSO
Мне кажется что в больших компаниях процессы в принципе настолько медленные что ожидание билда от нескольких часов до нескольких дней это норма.
А вот в небольших компаниях и стартапах где надо очень быстро делать деливери, очень чувствуется когда ты на задачу потратил 5 минут и потом пол дня деплоишь это чудо.
Понятно что с микро-репозиториями свои проблемы и сложности. Но там они возникают в конкретных случая и как бы выше на уровне шеред стафф и интерфейсов взаимодействия.
Да, если возможно в монорепо сделать так что реально тестируется только код который изменился и только сервисы использующие эти тесты то по идее нужно будет только ждать тесты при создании пиара (при условии что другие команды реально коммитят только в свои файлики и они не затронут тебя и не затриггерят твои тесты). Тогда придется ждать только мерж который в принципе быстрый. Вот только это сложно сделать в монорепо с монолитом + отдельные сервисы + shared dependencies и т.д. Ну и nodejs в придачу =))
Рально не знаешь где выстрелит. Поэтому приходится прогонять все тесты и билдить все и вся внутри :/
Решили что отдельные репы будет быстрее организовать. Хотя да, не очень удобно для разработчика. Когда все стянул с одного репо и у тебя все в одной папочке, удобнее. Но вроде привыкли уже. Но самое главное что боль уходит и теперь свои фичеры можно задеплоить за 5 минут.
Еще отдельная боль как результат того что билдится все и вся в монорепо - со временем появились тесты которые падают рендомно и никто не знает как их чинить. А те кто их писал уже не работают тут. Бывает задеплоить одну строчку кода берет пол дня потому что оно падает а ответственного за этот код хрен найдешь.
з.ы.
Возможно это только я замечаю, но мне кажется что отдельные репо тоже могут стать боттлнеком который в конце концо перевесит боттлнеки монорепо. Возможно при 200+ репо лучше подождать монорепо. Поэтому сейчас мы не делаем репо пер сервис а что-то вроде репо пер домейн где в своем домене можно шерить код, и там находятся свои воркеры, скедулеры и хттп сервисы. Но мы не ентерпрайз, еще стартап. Что будет лет через 5? Кто знает... Просто не первый раз читаю статьи о возвращении к монорепо но вот четкие метрики по которым можно принять решение не вижу.
Вы же бинарники компилируете? Не веб-сервисы?
У нас раз в 1000 меньше кода, разработчиков и пул реквестов. Но мы деплоим в веб. И мы ушли от монорепо. Еще не до конца, ибо распиливаем. Но новые сервисы в новых рипо по доменам. Не суть.
Одна из главных причин ухода от монорепо это ожидание своей очереди мержа в мастер и последующего деплоя.
То есть:
Ты создал пиар
Запустились тесты и если все хороше можешь мержить
Но пока твои билды бежали кто то уже замержил свой бранч в мастер, и там соответственно опять пробегаются тесты, билд и т.д.
Делаешь апдейт мастера в свой бранч и ждешь опять пока все тесты пробегут
Пытаешь опять замержить в мастер - а там опять кто то успел свой бранч запихнуть.
Надоело... Почему я должен ждать всех если изменения у меня в моем небольшом сервисе?
Понятно что можно автоматизировать. Но все равно придется ждать всех. А мы стартап. И так много проблем а тут еще и деплой ждать чтобы потом проверить все ли там норм.
С отдельными репо, небольшими, ты не зависишь от других команд и разработчиков.
Сколько у вас разработчик ждет от нажатия кнопки "деплой" (не уверен что это слово подходит в вашем случае) до нотификации - готово?
Я так понимаю в ваших масштабах билды как в интеле могут бежать от нескольких часов до суток и ожидание каких-то пару часов мержа вообще не проблема?
Возьмите любой стартап до 4 лет. Да и старше, если стартап все еще не выстрелил и нет денег на переписывание. Там будет все это и еще больше. Вот вам навскидку:
Логи? Нахрен надо. Х...к х..к и в продакшен. Кому нужны эти логи?
Тернарный оператор - чем длиннее строка тем лучше. А еще если там функция вызывает функцию с параметром где тоже тернарный оператор и вызывается другая функция - это будет вишенкой на торте.
Прочитал про функциональное программирование? Давай засовывай замыкание и каррирование где надо и где не надо. А, мутации... точно, делай клон всему и вся, память то бесконечная. А еще ко всему этому прицепи какую нибудь либу типа рамды и стримов, чтобы никто не смог продебажить это творение.
Используй везде и только примитивы и булианы. Ведь если функция которая что-то проверяет возвращает false, вряд ли завтра или даже сегодня ты захочешь знать почему она вернула false. А передавать 10+ параметров в функцию однозначно лучше упаковки их в объект... объекты они страшные. А деньги можно и в переменно price передавать. И рядом отдельную переменную currency. Зачем еще один лишний объект в системе.
Возвращай разные объекты из функций. Это круто когда ты можешь получить массив когда результатов много, и один объект когда результат один.
Так же у тебя есть возможно назвать параметр функции listingId, и в функции проверять если там массив то делай одно, а если нет - другое. Ведь нет вероятности того что следующая функция будет понимать только стринг а не массив, и что кто-то просто туда предаст это переменную.
Проходясь по легаси коду стартапов где главное - быстро в продакшен все пихнуть, можно книгу написать...
Да не очень то и нормально. У дефолтного клиента таймаут бесконечный. Может быть сюрпризом.
За эту бизнес идею наверное кто-то еще и бонус получил...
А вообще, глядя на то как разработчики относятся к алертам, особенно к ложным срабатываниям, я уже представляю врачей которые игнорят сообщения о потенциальной проблеме у пациента... но надеюсь я неправ и врачи ответственнее нас.
1. Написания сухой документации аля отправьте это — получите то
2. Описания юз кейсов и различных флоу
3. Публикацию бест практис в виде статей
4. Хороший поиск
5. Вставка и форматирование кода
6. Можно было бы разделять внутреннюю документации дл] инженеров от публичной которую мы даем партнерам.
Сейчас у нас документация разбросана по гиту (wiki), wix и собственный статический сайт где нужно коммитить изменения в репо и деплоить.
Может кто посоветует чего?
Писать балансировку на клиенте не хочется, а ставить лоад балансер чтобы он держал конекшены и балансил все девопс пока не хочет…
Как я понимаю проблема эта может всплыть только когда нужны постоянные соединения. То есть, либо кип элайв, либо http/2 как у вас.
Resolving: total 3402
3402 пекеджей… Карл!!!
2.5G папочка node_modules… и это мы еще rush юзаем
Почему, достаточно понять по примеру вот этого пекеджа
github.com/i-voted-for-trump/is-even
Который стостоит, из…
Который состоит из
Который состоит из
Где-то мир свернул не туда…
Насчет безруких разработчиков. Тут проблема не в безруких. Проблема в разных. С разным бэкграундом, целями, возможностями, хотелками, опытом и т.д. И вот тут та свобода и «простота» которую дает JS выходит боком.
Но добавьте к этому еще то что весь хайп зарождался фронтендерами которые теперь могли писать бэкенд. Писали как умели. Добавьте к этом коллбэки и промисы и вообще асинхронную модель. Никаких тебе паттернов написания бэкенд сервисов. Синглтоны наше все. Тесты? О да. Давайте вначале нахреначим кода нетестируемого, а потом придумает JEST который магией поможет протестировать это все.
Если в в любом статическом языке вы 100 раз будете думать использовать ли рефлекшен, то услышать от JS разработчика «давай метапрограммирование здесь заюзеам, классная штука, я тут на конференции увидел» это нормально. Он даже не понимает какие последствия всего этого могут быть. Не хватает того что язык динамический и ты можешь себе выстрелить в голову через ногу, есть люди которые не боятся, как бы это сказать, возвести эту проблему в степень.
Да, согласен, поднять серверок за 2 минуты это круто. Запилить крад апи прямо в базу с монгуси, еще 5 минут. И если это изначально маленький проектик, то нет проблем. Но для больших проектов надо понимать, что за все придется платить.
И это я еще не говорю про то что многие не понимают разницу между CPU bound/IO bound. А если начинают понимать, начинают пизать решения типа форков, от которых меня тошнит.
Многие не доходили до проблема когда GC тупо съедает все CPU потому что такое количество инлайновых обьектов и стрингов создается что он не успевает очищать память…
Рефактор без компилятора, и даже с тестами — то еще удовольствие.
Мы вот нахавались, начали внедрять Type Script с надеждой что хоть часть проблем он уберет. С оставшимися научимся жить.
Проблема в том что многие пишут на JS скриптики или что-то простенькое, и не всегда доходят до проблем реальных приложений с нагрузкой и большой кодовой базой. Вот они будут хвалить JS.
Люди с опытом уже не так сильно будут радоваться тому что вебсервер поднять на експрессе с монго в 100 раз быстрее чем на жаве или дот нет, если знают что им нужно будет в будущем это поддерживать. Потому-что понимают во что это позже выльется. А если написать, и через 2-3 годика свалить, то норм. Уже не твои проблемы. Уже другому придется объяснять почему переименовать филд в проекте это месяц работы…
Но опять же, для POC или простых проектов, особенно IO Bound нода свою работу делает.
P.S.
А еще я всегда ржу что винда на пентиуме быстрее поднимается чем билд и приложение на ноде с +100500 зависимостями =)
Вы будете мечтать о компиляторе каждый раз когда будет прилетать эксепшен или блокер из-за самых тупых вещей. Когда весь проект написан на объектах, без нормальных моделей данных, вы будет открывать любую функцию, смотреть на параметры типа options, и гадать — а что там внутри?
Есть огромная разница между людьми которые пишут POC на JS и прыгают со стартапа в стартап и никогда не доходят до момента когда простенький POC вырос в гиганта и теперь кому-то с этим жить.