Всем здравствуйте! Хотелось бы узнать мнения разработчиков о будущем Node.js. Насколько JavaScript перспективен как серверный язык программирования? Некоторые платформы переводят с PHP на Node.js. Неужели PHP уже не имеет будущего?
Работаю с нодой 3 года, с версии 0.8. Много букв
Плюсы:
1.Способность держать овермного «сквозных» реквестов. В самом распространённом случае, сервак не ждёт, когда БД ответит, а обрабатывает ещё остальные реквесты, то же самое с I/O, сообщениями/реквестами, заливкой файлов на S3 и так далее и тому подобное (Вы скажете твистед и прочее event loop based, но совсем не торт, асинхронная модель пайтона и иже с ними до ноды не дотягивает)
2. Streams Streams Streams! Нет, серьёзно, это круто, как с точки зрения архитектуры, так и memory efficiency
3. Масштабируемость заложена в дизайне. Вы никогда не будете запускать 1 процесс ноды. 10, 20 (Наш потолок — 24 на одном сервере с 24 ядрами)
4. npm. Самый вменяемый пакетный менеджер, из тех, что я видел
5.Возможность писать изоморфные универсальные приложения, работающие на клиенте и на сервере, что абстрагирует фронтендщиков от бекенда — профит очевиден, бэки не занимаются ерундой и написанием темплейтов, и сконцентрированы на АПИ
6.Легковесность. Как упомянуто выше, очень помогает в разворачивании банды микросервисов
7. Javascript же! Он и был приятен(ну лично мне, по крайней мере), а с выходом ES6 и генераторов избавился от детских болячек с контролем асинхронности, так что сейчас как никогда приятно на нём писать
Минусы
Их тоже хватает.
1.Самый главный, на мой взгляд — Порог входа. Манки кодить на ASP.NET MVC, к примеру, зажатым конвеншенами, фреймворком и строго типизированным языком, куда проще. Как следствие — поиск специалистов — нетривиальная задача. Но есть и плюс, если человек пишет на ноде, то он в большинстве случаев знает, что он делает
2.Без тестов в ноде делать нечего. Снова серьёзно. Если писать ноду без тестов — лучше возьмите что-нибудь другое.
3.Совершенно не подходит для математических операций, тяжёлого рендеринга(Да и для лёгкого, в силу синхронности этого дела, не очень), и вообще любых «не сквозных» операций. Перебрать массив на 2000 айтемов — нет. Держать в памяти KD-tree с индексами или хэштаблицу — нет.
4. Как дополнение к пунктам 1 и 2, необходимость очень тщательно следить за кодом и обрабатывать ошибки.
З.Ы. Golang тоже пишем, но там всё довольно печально с менеджментом зависимостей и вообще читабельностью кода. Возвращать по 2 объекта из функций — ВЦ. Надо привыкать. Пока, ИМХО, писать на нём что-то больше микросервиса на 3 файла — самоубийство.
читаю и вот: а-ха-ха-ха-ха, сарказм по поводу js — это хорошо. только:
1) один язык для фулл-стек разработки, никаких маппингов-конверсий начиная с фронтенда, заканчивая вашей любимой БД (sql/nosql)
2) отличная экосистема
3) быстро создавать быстрые решения
3.1) да-да, веб и сети — это ввод-вывод, а не вычисления
3.2) да-да, писать на js продуктивно можно, юзернейм же не быдокодер, синтаксическо-инфраструктурных ограничений уж точно нет
и не надо про:
1) недостатки динамики
2) о боги, отсутствие (или «неполноценность» ООП)
3) сложности и «магию» асинхронности, а особенно обработки ошибок
4) приколы с конверсией типов
5) сложность поддержки (ака «плохой код коллег по цеху», или отечественный «райтонли» код)
потому что:
1) динамика — это хорошо :) это быстро и удобно
1.1) недостатки у динамики (вообще, а не только js) есть, но они значимо меньше ее преимуществ
1.2) как пример ответа на частое нытье, которое можно слышать от любителей строгой типизации: проверки соответствия сущностей интерфейсам в «оченно критических» местах (проще — в пограничных слоях системы, там, где можно ожидать чего угодно) никто не запрещает делать, благо с интроспекцией все ок. ну и для начала eslint неплохо бы поставить, чтобы не жаловаться на большинство глупых «undefined is not a function»
2) не хочется даже апеллировать к таким возражениям. пожалуйста, сначала вспомните, что такое ООП, а потом прикиньте что реально из этого определения вам нужно, и окажется, что все с этим ок в js
3) промисы, промисы и еще раз промисы, никакой магии — все просто
3.1) вызывайте синхронно-асинхронно (имеется ввиду без заморочек о типе результата функции), бросайте исключения на здоровье (да-да, с on(’error’) тоже все хорошо — ведь эмиттер бросит исключение, если нет подписчиков и у вас есть весь контроль за всем, чем не уследили),
3.2) и в конце цепочки действий ловите все, или на полпути ловите часть — в общем делайте так же как делают все хорошие парни из .NET/Java/etc
3.3) и о да! получайте «реальный» стек вызовов, без потерь цепочки из-за асинхронности (этого не может быть! все знают как тяжело понять асинхронный код! а ошибки — вообще нереально обработать),
4) Number(), String(), Date() - да, да, если сделать Number(’10′) + Number(’10′) у вас будет 20, а не 1010, и не надо про «что же мне везде это делать?» не везде — в пограничных слоях системы (который чаще всего 1: web API вашего приложения)
5) самый классный пункт. ибо криворукость и "writeonly«-сть слабо зависит от спецификации js, но хорошо зависит от аналитических способностей членов команды. никто вам не мешает 1) выбирать, с кем работать, 2) применять паттерны и заботиться о дизайне вашей системы. ну и еще, если у вас реально рокет сайнс — никто вам не мешает один из «реально крутых, считающих модель этого мира ради извлечения всего профита» узлов написать на чем-то специфическом, и общаться с ним по сети (очереди уже сообщений, либо хттп, а может свой протокол поверх тсп — не важно), или «безсетевыми» средствами межпроцессного взаимодействия, а может и маппинг для него написать
---
p. s. если кратко, для «уже взрослых в этой теме» — для веб фулл-стека — самое то. единственная реальная проблема, с которой вы можете столкнуться — это «шальные (неоднозначные) сетевые (не обязательно, но часто) исключения» из модулей, авторы которых плохо позаботились о вас, как о своих пользователях, но от подобных неоднозначных ошибок вы не застрахованы нигде, в том числе работая в строго типизированной интерпрайз среде (о, боги, эта стремная работа с разными версиями разных провайдеров оракл в дотнете, заваленных тоннами как левых так и собственных г*вно-абстракций, как пример. сомневаюсь что за несколько лет там что-то поменялось), только в ноде у вас будет зависимость с открытым кодом, который вы можете понять и пофиксить (часто — потратив не больше 10 минут), а вот с интепрайзом даже за хорошие деньги — все не так уж просто
p. p. s. всегда раздражала многослойность, неповоротливость и отвратительность ложных абстракций, избыточность «слоения». и вот переписанное (по причине критического снижения поддерживаемости ака maintanability) с интерпрайз-стека распределенное приложение (oltp местами с olap) кушает не под 4GB, а под 200MB памяти, 0.05 (а не 0.70) процессора, отклик на порядок ниже (в
Хех=) Ну и опять пхпшники, с которых 95% думают «я знаю джабу скрипт- да все знают его, все же кнопочки на JQ клеили», будут примерять архитектурные паттерны и иные идеологии LAMP на node.js и рассуждать о ее перспективности и «ущербности» JS как такового- начиная с того что там не 100500 функций ядра на каждый чих.
Node.js просто другой, другой язык, другая идеология, другая архитектура и спроектирован не с целью выплевывать куски html в клиент, как php и его братья. Все эти споры не имеют смысла, без опыта в обеих средах и решения практических задач кроме как вывода hello world.
Ну а те разрабы, которые кроме технологии X вообщем то ничего не знают, тяжко переходят между языками, просто войдут в стадию отрицания того, что возможно язык/технология Y лучше подходит, отсюда генерится большое количество Г. на вентилятор.
Действительно, стандартные решения, там где нужно отдавать готовую страницу на клиент на php заметно проще и дешевле, но с этим же и node справляется, но прицел там на отдачу чистых данных и оперированием большим количеством мелких запросов.
Если разраб не может разбить задачу и выстроить правильную архитектуру под конкретную технологию, в силу недостаточного понимания, это проблемы разраба, а не технологии.
Такие темы нагоняют на меня вселенскую печаль. Неужели столько трудов и поисков правильного языка программирования привели к javascript?
Еще одно подтверждение, что у node.js нет будущего — blog.scaledrone.com/posts/nodejs-to-go .
Сейчас набегут жаваскриптеры и напишут шо то они просто не умели программировать, неправильный инструмент подобрали(нода же не для этого!111), и вообще ну тупые))
Вам бы организовать закрытый клуб хейтеров JS :) Шутка ;)
Не просто клуб, а коалицию хейтеров JS ;)
Создайте тред в твитере jsmustdie и постите там себе
изза невменяемых гошников коалиция обречена на провал :-)
Радикалы нужны любой компании чтобы бить морды. Вот гошники будут бить их джаваскриптерам когда надо. Все продумано!
И? Мы все знаем вашу точку зрения. Зачем 100500 раз постить о переходе когото на го?
Цитата з приведеного вами ресурсу:
I recommend Node.js for those who don’t have to deal with hundreds of thousands or millions of concurrent connections and Go for those who do.Цікаво чи має у нас такі показники хоча б одна компанія в Україні. Здається це ви говорили про максимальні 50 запитів/секунду при пошуку на prom.ua...
На скільки я собі уявляю, то одні з найпопулярніших сайтів (не враховуючи гугл, фейсбук, ВК...), це сайти з оголошеннями, та сайти пошуку роботи.
Читав що work.ua та rabota.ua дотягують до 5 млн. запитів за сутки. Якщо взяти цю цифру й припустити, що їхні користувачі роблять дану статистику за чотири години-пік, то виходить що у них йде по 5000000 / (3600*4) = 347 запитів/секунду.
Велике питання чи про такі сайти можна б було написати що у них «hundreds of thousands or millions of concurrent connections», якщо б вони теж використовували websockets...
На скільки я собі уявляю, то одні з найпопулярніших сайтів (не враховуючи гугл, фейсбук, ВК...), це сайти з оголошеннями, та сайти пошуку роботи.Неправильно представляете. Полистайте топ на alexa.com чтоб убедиться
Цікаво чи має у нас такі показники хоча б одна компанія в Україні.
В сфере интернет-рекламы это обычные показатели — реклама же размещается на десятка тысяч сайтов. Например, у нас в Vertamedia на один из сервисов сбора статистики сейчас приходит пару сотен тысяч запросов в секунду от двух миллионов одновременных подключений.
Статья как раз для вашего мммм.... спора
ebanoe.it/...
Этот комментарий там лайков наловил да и мне понравился. Предупреждение, у многих вседевелоперов может забомбить.
Скорее всего «менеджер» тут является представителем традиционной гомно-конторке, которые всегда ищут «Java/.NET/Python/LISP/RoR девелопера, будет плюсом умение разрабатывать UI/UX для iOS/Android/Blackberry, IoT ,работа с Microsoft SQL Server/MondoDB/Redis и автоматизация тестирования на Selenium/Cucumber/Appium, а так же будет обладать всеми скилзами необходимыми для работы BI/BA/PM-а и CTO» чтобы сэкономить и максимизировать свой гешефт.
Я не против специализации, я против отстаивания точки зрения, что моя специализация — круче всех.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Скорее всего Node.js в ближайшем будущем ждет судьба PHP.
Написать что-то просто можно относительно легко и быстро, но чем больше будет развиваться проект, тем больше подводных камней будет всплывать.
В принципе, сама идея тащить на сервер язык изначально созданный для клиентской разработки (и так толком не доведенный до ума) — изначально порочна.
Увы, ноду успех пхп и не снился.
Чому б і ні? Хіба ми усі не знаємо про проблеми новачків особливо у «серйозних» мовах із високом порогом входження, типу C, C++, Java, Go і т.д. ?
Добре що є такий вибір. Програмісту простіше дорослішати починаючи із PHP, JavaScript, тим часом готуючи себе до більш серйозних мов.
Программист после джавасркиптов и пхп повзрослеть может, а вот заказчики скорее всего нет. В итоге все так и останется на этих легких языках, ибо дешевле.
Кому від того гірше? Замовнику? Програмісту?
Що один, що інший мають вибір і вони його зроблять, коли захочуть. Подібні проблеми не серйозні.
О да, просто огромный выбор, к примеру:
писать веб фронт енд на javascript или на javascript
писать веб бек енд на php или на php(и так повторить 10 раз) или в редких случаях на чем то другом.
Нет особого выбора. Особенно в фрилансе. Малой части везет не общаться вот с этим.
Ну звиняйте, значить та частина, яка не може перейти на більш серйозні мови, має не достатньо знань чи можливостей.
На фрілансі одне сміття? Змініть фріланс, або переходьте в офіс...
та частинакаждая область имеет потолок мест. К джава к примеру мест для джунов практически нет. К питону тоже единицы на всю страну. А стать мидлом сразу невозможно.
Вы, если я не ошибаюсь, ведроид-джуном хотели стать. Вроде же область довольно легкая для вкатывания?
И да, откуда такой хейт JS?
После просмотра как на каждую заявку андроид проекта на апворке за
откуда такой хейт JS?оттуда что стремный язык, похуже пхп даже.
Вы я смотрю експерт в языках программирования... попробуйте для начала разобратся с одним
Проблема в том, что большинству программистов, которые начинали с PHP потом трудно вписаться в команду, где используются более зрелые технологии.
Они на любом языке продолжают писать на PHP.
от конкретной особи зависит, это стереотип из
Есть и на пхп пишут, используя UML, ООП, TDD ,Solid и пр.
Ну у заказчиков стереотип что пхпсты дешевые так и остался, потому UML я еще нигде не видел, даже комментирования кода нормального. ООП есть из за того что фреймворки заставляют их писать в этом стиле.
UML я еще нигде не видел, даже комментирования кода нормального.не видели -это не значит, что его не существует?
Ну и кто вам самому мешает писать в TDD с комментариями, аккуратно -стиле проф. разработки?разве это не очевидно? Бюджет заказчика мешает.
попробуйте устроиться в какую-нибудь серьезную компанию удаленно работать тогда..
Ну я думаю можно и адекватного найти. Эти просто на грантах вроде сидят, не бизнес проект. Ладно, то такое. Еще бы нравилось программировать веб с жейкверями и пхпшками так вообще бы сказка была.
Возможно в 2016 году стоило бы попробовать писать без
жейкверями
потому UML я еще нигде не видел, даже комментирования кода нормального.я за 10 лет тоже его не видел. вообще нигде, ниточто а пхп.
Исключения конечно же есть, но в массе своей PHP откладывает таки довольно сильны след на человеке, который начинал изучение программирования именно с этого языка.
Как и любой другой язык с динамической типизацией..и слабым ООП
Чем Джаваскрипт в этом плане лучше?
Ничем не лучше. Еще хуже.
Просто он ломает ваши представления про ООП прототипами)))
Да нет, этот как раз таки не самая большая беда JS. Хотя и этот пережиток прошлого тоже JS красоты и изящности не добавляет.
этот пережиток прошлого— почему пережиток, прототипы все также с нами)
Тонко)
А чего никто не говорит про Elixir — считаю что это будущее, такой себе попсовый Erlang:)
Javascript нынче настолько популярен, что уже даже десктоп приложения на нем пишут. Я вот поставил был айдишку на джаваскрипте — Atom. На убунту 14 не запустилась. Но это не важно, главное что пишут же! И скоро всем языкам настанет трындец, ынтерпрайз на джысы перепишут весь, роботы для отправки на Марс начнут на нем писать. Осталось совсем чуть чуть. Трепещите!
А сколько зависимостей тянет эта ide’шка? Слышал, что hello world application на nodejs тянет 20К зависимостей, состоящих из 40К файлов и папок.
Не знаю. Я изначально скептически ставился к ней. Она не подвела моих ожиданий. Я деб пакет с оф сайта скачал, установил, нажимаю на иконку — 0 реакции. Копаться почему оно не работает желания не было.
Я вот поставил был айдишку на джаваскрипте — Atom
А сколько зависимостей тянет эта ide’шка?1. вообще-то это не IDEшка, а редактор (по крайцней мере разрабы так его позиционируют), который, насколько я понимаю позиционируется, как альтернатива саблайму)
2. есть portable версия для винды вроде (та, которая в зип-архиве), т.е. типа разархивировал и вперед) т.е. нода с электроном входит в сам дистрибютив атома.
Слышал, что hello world application на nodejs тянет 20К зависимостей, состоящих из 40К файлов и папок.это смотря какой хэллоу-ворлд аппликэйшн)
можно ж просто файлик типа hello.js с console.log('Hello, World!');
написать и запускать это в консоле через
$ node hello.js . Насколько помню)
Другое дело, если веб-аппликуху на каком-нибудь koa.js или sails.js ваять, то тогда да — зависимостей дохрена наверное потянет)
Hello world на джс (имеется в виду веб сервер) 7 строк без зависимостей
Саме цікаве, що я порівнював «Hello world» на Restify, Express із веб-сервером вбудованим у PHP. Так PHP взуває цих лідерів аж бігом — у 2.5 рази швидший.
Хоча я розумію, що вбудований вебсервер PHP без системи маршрутизації, але у 2.5 рази... причому на PHP 5, а я ще із сьомою версією не пробував...
А в других языках принято писать все велосипеды самостаятельно и не использовать либы\фрейворки?
ну есть два пути — напедалить велосипед либо использовать готовые либы/фреймворки. Каждый выбирает для себя) я больше привык использовать готовые либы/фреймворки, если считаю их подходящими для данной задачи.
А вот в каком языке какой из этих двух подходов общепринятый как то не в курсе.
Ну собственно поетому приводить кол-во\размер либ как не то глупо)
просто я больше поклонник так сказать минималистичности (небольшой размер, легковесность, мало зависимостей и т.п.). Например, мне нравится питоновский микро-фреймворк Bottlepy и пхп-шный Flight ( flightphp.com ). Для ноды был xepler.js (да что был, вроде и счас есть), но к нему документации практически нет и боюсь его автор не развивает больше.
Все нормальные разработчики переходят с node.js на Go — medium.com/...
Даже вконтакте перешел с node.js на go — twitter.com/...
Готов ли Go для продакшена? VK переписали push уведомления c nodejs на Go и вместо 60 упоротых стало 24 ненагруженных сервера
вы же понимаете что через год-два все будут постить статьи о том что Го полное уге?
а еще через год-два он устаканется в своей нише полностью
вы же понимаете что через год-два все будут постить статьи о том что Го полное уге?Не совсем понимаю. Объясните, пожалуйста.
Пару лет назад все писали как куто перешли на ноду, и все остальное лажа.
Еще был хайп какая крутая монго, а потом как с нее сползали на постгрес.
Сейчас начался хайп на го, но удивляет че его не было раньше, ибо го не первый день. Пройдет хайп люди поймут что юзали его там где не надо, и будут постить что это уг, в итоге у го останется своя ниша, правда меньше чем во время хайпа.
Это 100500 раз было уже
Согласен. Только после хайпа гоу полностью вытеснит из хайлоада все остальные решения. А про ноджс будут вспоминать только в страшных снах.
Статьи о том, какой гоу уг, будут писать те же люди, что сейчас пишут, какой ноджс крутой. Т.е. люди, совершенно не разбирающиеся в инструментах, которые они используют, и использующие их не по назначению.
node.js вроде никогда не позиционировался как хай перфоменс решение, а как решение достаточно быстрого джса который может использоватся на сервере (а это разные вещи), в основном потому что нормальная асинхронность.
потом, go уж никак не повлияет на рынок nodejs, это настолько кардинально разные технологии (что ведет нас к тому что и ниши разные), и они практически не пересекаются (лично я себе не представляю апликухи где бы расматривал nodejs и go как альтернативы, ибо шо то, шо то весьма нишевые продукты)
Статьи о том, какой гоу уг, будут писать те же люди, что сейчас пишут, какой ноджс крутой.именно, но эти люди делают не плохое дело, они как рекламщики в мире технологий, двигатели прогреса так сказать
потом, go уж никак не повлияет на рынок nodejs, это настолько кардинально разные технологии (что ведет нас к тому что и ниши разные), и они практически не пересекаются (лично я себе не представляю апликухи где бы расматривал nodejs и go как альтернативы, ибо шо то, шо то весьма нишевые продукты)
Да ладно. Что вы скажете про следующие переходы с node.js на go?
— Uber переводит сервисы с node.js на Go — eng.uber.com/go-geofence
— Digg переходит с node.js на Go — medium.com/...
— Вконтакте переходит с node.js на go — twitter.com/...
— Bower переводит инфраструктуру с node.js на go — twitter.com/...
— разработчик популярных node.js пакетов переходит на Go — medium.com/...
— Over9000 других переходов с node.js на go — lmgtfy.com/...
Uber переводит сервисы с node.js на Goя вообще не понимаю чем они думали когда лепили ноду для тех целей
Digg переходит с node.js на Go — medium.com/...f-the-gopher-6693db15ae1f
Bower переводит инфраструктуру с node.js на go — twitter.com/...status/717426243730345986инфраструктура, тут го действительно намного лучше
— Вконтакте переходит с node.js на go — twitter.com/...status/638132331295952896они пыху в си компилируют, что как бы наталкивает на мысли, но опять таки, инфраструктура
— разработчик популярных node.js пакетов переходит на Go — medium.com/...well-node-js-4ba9e7f3e52b .чувак написал о своем взрослении на пути разработчика, и принятии что под разные решения свои тулы, и о смене предпочтения, как бы ни о чем, я сейчас вот нахожусь сам на распутье, и думаю о смене языка
— Over9000 других переходов с node.js на go — lmgtfy.com/...switching from node to go .что-то меня наталкивает на мысль что там либо хипстеры, либо начали головой думать
они пыху в си компилируют, что как бы наталкивает на мысли
на мысли что тогда они сделали глупость начав проект на пыхе, а теперь вовремя соскочили с ноды на норм язык/технологию как го?
нет
я сейчас вот нахожусь сам на распутье, и думаю о смене языка
на какой если не секрет?
судя из его топиков на кровавую джаву:)
возможно, возможно скала, но посмотрим
Я сам JS-ик, интересно почему хотите перейти? И разве чтоб стартануть с Scala, не нужно знать Java?
Javaее я давно знаю, просто она не мой основной язык, так от случая к случаю ее юзаю, правда последнее время, она у меня как то в основной язык переходит.
JS как то поднадоел, хочется чего-то нового.
ФП мне очень даже нравится, из субъективных представлений я бы кложур выбрал, но вот не думаю что это будет востребовано, потому и смотрю в сторону скалы
ФП мне очень даже нравится— та да ))
из субъективных представлений я бы кложур выбрал— ага, там еще есть ClojureScript для фронта.
ClojureScript для фронтав итоге вечный поиск новых подарков от производителей браузеров, не, надоело
Ну порог входа в Scala будет повыше Clojure как мне кажетсяпороги входа меня не пугают.
все зависит от того насколько получится на рынке реализоваться. плюс у меня ситуация что работу не очень удобно менять, но думаю в рамках компании на скалу перейти.
и есть один закачик на фрилансе, может там тоже получится, но тут слишком много «если» )))
посмотрим как оно пойдет.
С каждым вашим комментом в этой теме и твитами/статьями от некоторых других гоферов у меня остается все меньше и меньше желания изучать этот язык.
Я честно боюсь превратиться в такого зануду.
Го, специально заточенный под этот сценарий, оказался в 2 с лишним раза быстрее, чем нода, которую кто-то написал по накурке вместо курсового проекта? Это победа я щетаю.
нода, которую кто-то написал по накурке вместо курсового проектазолотые слова! Вы только что официально признали, что node.js — для упоротых наркоманов.
упоротых наркомановВы так говорите будто это что-то плохое?
к стати как дела- кто то с NPM насосался днями или миновала вас чаша сия?
Неужели PHP уже не имеет будущего?чё вы прицепились к этому несчастному пихапэ ?
Node.js это не будущее, а самое ни на есть настоящее.
печальное настоящее (
Насколько JavaScript перспективен как серверный язык программирования?Перспективен. К сожалению. Тут четкая зависимость: чем более убогая технология, тем она перспективнее в web. Сначала был PHP, теперь это, завтра еще какой-нибудь треш из пальца высосут.
У вебовцев какая-то патологическая непереносимость нормальных языков и технологий. Еще несколько лет назад казалось, что у web есть шанс вырваться из болота. Java и C# с чем-то похожим на нормальные фреймворки по-маленьку отвоевывали жизненное пространство у недоязыков... Но теперь все, снова назад в темные века глюков, тормозов и запредельного потребления ресурсов.
Java и C# с чем-то похожим на нормальные фреймворкикак вы странно назвали Erlang и Scala
Я знаю 10 программистов которые перешли с PHP на N2O.
А с node.js не знаю ни одного, кто бы перешел.
скорость разработки как критерий из топ-3 для выбора инструментария, подходов никто не отменял.
напомню топ-3
— быстро
— дешево
— качественно
какова скорость разработки, внесения изменений скажем в электронный магазин:
на PHP
на Java
...
напомню топ-3Напомню-ка я вам, что выбирать приходится только два из перечисленных критериев.
— быстро
— дешево
— качественно
Это утопия, реальный мир сложен и многогранен, и соотвественно критериев в разы больше
только почему-то это многообразие вполне вписывается в кривую Гаусса, правило Парето, и т.п. статистические наблюдения.
спасибо. на что вы еще решили мне «раскрыть очи» ;D
Хомякам нужно делать подешевле, вот норм языки и не приживаются.
Резюмируя всё понаписанное — нода и js являются замечательным решением, чтобы быстро склепать велосипед, который умеет взять данные из базы и показать их в браузере.
А вам не кажется, что этого маловато в современном мире? Вычисления где будут происходить?
Вычисления где будут происходить?Дык в браузере же ж уже сегодня веб единственное приложение что может загрузить на
ЗЫ: какие вообще вычисления?
да ладно, а игрушка типа
У мну видеокарты нет со времён HD4670. ((
т.е. о валидации данных от клиента на стороне сервера можно забыть? :)
Так фуллстэк же ж по ту сторону точно такой же ж JS программер сидит а то и один и тот же ж они сами с собой невалидны что ли?
а что мешает юзеру приделать пару-тройку лишних ноликов к отправляемому значению?
захерячить рест быстро можна на чем угодно зная инструмент.
На тойже жаве времена где нужно три дня писать иксемель дескриптор приложения и потом еще три дня паковать антом в еарник — давно прошли; жпа + жаксрс + аппсервер поднимаеться за 15 минут с юнит тестами. Уверен что во всех остальных веб языках ситуация аналогичная.
Другое дело что фронтендер, который токо с джаваскриптом и работал — по надобности разернуть ноду, займет значительно быстрее времени чем джаву выучить.
Nodejs в который раз доказывает свою несостоятельность — www.haneycodes.net/...
Причем тут node? Это проблема копи паст программирования которая во всех языках существует. Просто многие юзают вместо копи паста модули в npm
Бггг нэтъ. Наоборот. Нужно было скопипастить, но мы ж не копипастим, правда? И велосипеды не изобретаем, ни-ни. Мы юзаем готовые решения™ и не задумываемся, что у импорта есть цена. Иногда выше, чем у копипаста и велосипедизма.
Всему есть свой предел, в babel могли бы и сами написать leftPad, но наличие такого низкоуровневого кода по манипуляциям со строками в веб-приложении, которое не является библиотекой всегда говорит о плохих стандартах разработки и ревью на этом проекте.
тащить third-party модуль на 10 строк потому что в одном/двух местах надо дорисовать в строку пробелов, или third-party модуль на 3 строки, потому что надо выяснить лежит ли в переменной массив — это конечно офигенные стандарты разработки. высшего качества. повесить на доску почета и любоваться пять лет.
смотря где, для библиотек в npm — можно свои было бы реализации написать. на пользовательском проекте реализовавывать padding — это ребячество
В данном случае копи паст через npm
Какой же это копи паст? Копи паст — это когда 2 копии кода, которые невозможно поменять из одного места. А тут — и поменять можно, и удалить. Причем не из одного проекта, а из десятков тысяч! Почувствуй мощь!
Проблема копи паста стала в разы больше, в сегодняшние дни. Частично тот же стек офервлоу это очень сильно стимулирует.
На самом деле далеко не всякий копипаст зло. Есть куча кейсов где копипаст лучше чем обобщать код в функции. Пример такого кейса когда есть два процесса очень похожи, в итоге пытаются объеденить но из за мелких отличий пихают кучу ифов, в итоге код более сложно поддержуем чем в случае копипаста.
Проблема копипаста это проблема бездумного заимствывования сторонего кода (причем не всегда работающего верно).
Отличающиеся части довольно просто инжектятся и без ифов. Это лишь вопрос навыков.
Заимствование — не копипаст. Вполне можно жить и не вдумываясь как работает та или иная деталь. До тех пор пока она не перестанет работать, конечно.
В результате инжектов обычно создаются дырки во флоу которые вынесены, и точно так же поддерживать сложно, на этот счет давно пришел к тому что ифы и форы зло, и чем проще флоу, тем лучше.
Копипастит убирать надо только тот, который копипаст логики.
А когда логика просто похожая, то такое объединение это попытка назвать носорога зеброй, ведь оба имеют четыре ноги.
Есть одна проблемка в этом: если получается несколько идентичных блоков из 6 и более строк в разных местах программы — есть шанс, что контекстный патч (в любой VCS) ляжет не туда. Ловить такие ситуации, если merge прошло молча, очень сложно, только по тестам или случайному обнаружению.
ну это уже весьма специфический момент.
кстати, после того как перешел на гит — забыл слово патч.
«Патч» это в общем смысле. Я видел эту ситуацию на мерже под CVS, но под git воспроизвёл без проблем.
А в общем этот аргумент против копипастинга сильнее, чем ещё не установленная необходимость синхронно менять несколько мест, из которых часть уже забыта.
но под git воспроизвёл без проблемвот тут меня разрывает любопытство, можете описать степы?
у меня было. офигел.
но, ясен пень, никуда не сохранял, чтоб позже развекаться.
Было так. Создаём файл из двух функций вида
ПЖ — 11 років! 🎂
Andrii Hrachov
Constantin Titarenko
Dmitriy Mozgovoy
Ihor Lazarenko
Aliaksandr Valialkin
Olexandr Vovchok
Костя Третяк
Dmitry Zozulya
Olexandr Vovchok
Oleksandr Tkalenko
Андрей Губский
Vitalii Bobrov
Sergey Sheshenya
Inoketiy Mogilyov
NewOne NewOne
Alexander
Нестор Иванович
Maxim Bielov
anonymous
Борис Махно
undefined pointer
Sergio Gonzales
Alex Fogol
Jorzchyk Pushysty
Дмитро
Vasyl Lytovchenko
Vanya Yani
void f1() {
foo1();
foo2();
foo3();
bar1();
bar2();
bar3();
printf("f1\n");
}
Далее делаем две ветки, в одной дописываем что-то в конец, во второй — в начало, и между foo3() и bar1() внутри f1() вставляем ещё одну строку (например, f1x()).
Мержим. И тут отсчёт по позициям для поиска ближайшего контекста, где foo1()...foo3() и bar1()...bar3(), находит не f1(), а f2() с идентичным контекстом — отличить он их не может, а номера строк в случае f2() ближе к тому, что показывает вторая ветка, чем в f1() первой ветки. В результате новая правка — добавление f1x() в f1() - попадает вместо этого в f2().
На современном git воспроизвести не могу — видимо, он лучше ловит контекст. Тот странный результат был в районе 2010. Наверно, логика мержа ещё не сильно отличалась от той, что делает внешняя команда patch.
я понимаю как это сделать с патчем, но вот гит... он по идее такое должен хавать
Ну так это ж давно было. Мерж — самая критичная для linux часть, и её активно лечат...
к чему этот поток сарказма вёл-то?
Если бы авторы npm именно скопипастили те 11 строк в свой код, проблемы не было бы.
Но такое решение зарубят на code review Anton Kononenko, Dmitriy Onykyyenko, и большая часть комьюнити. Обратно, код, который привёл к факапу выше, скорее всего пройдёт ревью без вопросов. В том числе без вопроса из заголовка, и его прийдётся задавать пост-фактум, когда всё уже упало.
Принятые в коммьюнити критерии оценки кода отдают предпочтение менее надёжному решению.
Проблем с кодом не было. Были проблемы с инфраструктурой, о которой программисты почти никогда не думают (привет, DevOps). В security-aware компаниях давно настроили зеркалирование всех внешних зависимостей. В open source проектах денег на зеркалирование обычно нет. И даже если есть, то оно настроено неверно (привет, KDE).
Нет проблем с инфраструктурой. Место на гитхабе бесплатно, форки тоже. Практически весь опенсорс работает через зеркала (своих дистрибутов), часто с хорошей избыточностью.
Проблема исключительно в майндсете разработчиков.
И девопсы не решение. Ревью кода внешних зависимостей тоже им делать?
DevOps — это не люди. Крайне мало опенсорс проектов зеркалируют свои зависимости. Практически всегда это центральный репозиторий, будь то github, npm, rubygems, pypi, maven central, docker hub, или что-либо иное. Форк сделать, конечно, можно, но только в ручном режиме.
Веб-девелоперы способны удивлять даже без node.js.
Форк сделать, конечно, можно, но только в ручном режиме.
developer.github.com/...
developer.github.com/v3/repos/#create
см. тж. значение буквы D в DVCS.
Крайне мало опенсорс проектов зеркалируют свои зависимости.
Перечитайте внимательно мой пост выше.
Веб-девелоперы способны удивлять даже без node.js.Переход на личности? Я тоже могу, человек, у которого всего лишь 2 публичных GitHub-репозитория.
developer.github.com/v3/repos/#createИ что? package.json все равно править придется.
Перечитайте внимательно мой пост выше.Перечитайте мой.
Как часто твои проекты не собираються по причине того что обиженные администрацией пакетного менеджера разработчики удаляют свои пакеты?
Реже, чем
1) пакеты удаляются по любым другим причинам
2) пакеты переезжают, сливаются или разделяются
3) в зависимости стоит master вместо конкретной версии, а авторы решают всё непоправимо улучшить
Ок, полагаю у Питонщика это частая праблема ,когда он не может найти свой пакет в npm. давай конкретно с примерами за последний год имена пакетов в npm из-за, которых у тебя были эти проблемы.
Ок, полагаю у Питонщика это частая праблема ,когда он не может найти свой пакет в npm.
Естественно. Смотрю пятый раз и не вижу. Хотя чего это я, я ж не писал leftpad.
давай конкретно с примерами за последний год имена пакетов в npm из-за, которых у тебя были эти проблемы.
Кстати, а что такое npm? А то я rebar’ом пользуюсь.
ок, тогда откуда у тебя информация о том c какой частотой ломается обратная совместимость в пакетном менеджере, о котором ты в первый раз слышишь?
То есть, потратить хоть 5 секунд понять, о чём я говорю, вы не захотели.
Что ж, считайте, что тут висит табличка «сарказм» размером 3*2 метра, и на этом можете успокоиться.
Спасибо за внимание.
В следующий раз будешь думать стоит ли писать реплику на вопрос в котором не смыслишь, что бы не сливаться так быстро.
И за повторное подтверждение. Спите дальше.
чувак, это легендарный netch, ты хоть вчитайся в то, что он пишет
разговор ушел в неконструктивное русло по его вине.
Я не получил какой либо аргументации в ответ задав уточняющие вопросы.
в приведенных пункта как по мне говориться о достаточно надуманных гипотетических проблемах, которые возникают как исключения скорее и крайне редко. npm закрыл вопрос с ними после прецедента запретив удалять пакеты.
не совсем.
потребность в микромодулях вызвана отсутствием возможности запуска отдельных функций.
в сравнении скажем с Java — либа может быть сотни мегабайт. подключают ее ради одного классика.
в рантайме JVM поднимет в память только его. остальные сотни мегабайт будут себе тихонько лежать на диске.
Как в JS подключить библиотеку ради использования одной функции, и чтобы в рантайме загружалась только эта функция?
Проблема с запуском есть. Возможно с ес6 поддержкой это будет решено.
Но тут больше беда что стандартная либа джс, очень очень мала, есть лодаш и андерскор, которые в основном решают проблемы работы с коллекциями, есть момент для работы с датой временем, а вот для строк не всегда есть.
Да многие бы с большим удовольствием, юзали либу типа лодаш для строк и не парились. Но ее попросту нет. Хотя не так часто есть потребности преобразовывать както хитро строки
В таком случае говнокодеры на любом языке/платформе доказывают несостоятельность своего языка/платформы. «Аргумент» ни о чем.
Вообще так и есть. Мнение про языки программирования складывается на основе сообщества, а не на основе особенностей языка/платформы: modelviewculture.com/...
В свое время был прикол на фронтенд джс, что всегда надо юзать джквери плагин, потом таких людей называли джквери программисты
Никогда не сталкивались с удалением пакетов из pip репозитория? Или вы коммитите все зависимости в гит?
Или вы коммитите все зависимости в гит?btw встречал и схожий вариант: добавлять зависимости в bundle при publish’e. нечто среднее между «слепо полагаться на неизменность» и «даже в коммитах коммитить зависимости»
Просто оставлю это здесь:
Node.js is one of the worst things to happen to the software industry in recent times, a whole generation of programmers are being taught the worst of all ways of doing concurrency, in a system that doesn’t scale either in performance or project size and with one of the languages most plagued by pitfalls ever created.JavaScript was already painful enough in the browser, why on earth anyone ever thought it was a good idea to use it on the server boggles the mind.
We will be paying the price of this misguided hyped fad for decades to come.
Of all the ways of doing concurrency, callbacks are by far the worst.
And the sad thing is that there are much better alternatives around with much more sound models and environments, Erlang and Go are the two obvious examples, and that is for the highly specialized situations where you have great concurrency needs, for any other problem anything else will be much better than Node.js, even PHP.
Взято отсюда — harmful.cat-v.org/software/node.js .
да, вполне может быть, что Node.js оказался востребован и популярен, потому что появился класс задач («микросервисы») для которых использование классики JVM, .NET, C/C++ оказалось тяжеловестным.
примерно как со взлетом PHP/FI. но если дальнейшую судьбу PHP мы знаем, то вот что будет с Node.js на фоне GoLang...
а то и Elixir’а на ErlangVM...
сколько раз слышал о том что JS вообще недоязык, там нет никакого ООП, это худшее, что можеть быть, что ожидать от языка написаного за 10 дней.
но как ни странно его популярность ростет семимильными шагами. Node.js крайне полезная штука, а те кто кричат о том что его асинхроность ужас, видно не учили историю. была уйма серверных JS, но Node.js первый который использовал асинхроность нормально (да-да, не в V8 дело).
JS не везде применим, и не должен быть таким. все это поливание грязью идет от невежества. люди приходят из других экосистем, ожидают увидеть то к чему они привыкли, а тут облом. JS сильно отличается от всех мейнстримовых языков, и начинается попытка натянуть шапку на жопу.
классический пример, проект на я JS — тысячи файлов, хренова туча фабрик, адаптеров, «классов» реализующие паттерн стратегия (это для меня было всегда самое непонятное, ибо нет причин использовать класс в JS для реализации стратегии) и хренова туча других. вот смотрю я на это и пониманию, наверное джависты писали... по нормальному весь проект можно порезать раз в 10, если не больше. а потом эти ребята рассказывают какой JS плохой.
к примеру, я не работал с Го, но бегло читал его доку, и понимаю что он очень хороший инструмент для своего класса задач, как и Скала, Джава, ПХП, С, С++ для своих. но скорее всего, даже если область применения будет пересикатся, в каждом языке вы будете реализовать решение по разному, и это нормально. нет универсального подхода для решения задач. всеобщее разнообразие языков только лишь помогает совершенствовать каждый из них, ведь очень часто имеет место заимствованию.
итог сего эпоса — JS не умрет, как бы вам не хотелось, по крайне мере следующие лет 10, а там видно будет
бггг
сколько боли на единицу текста
Если человек не в курсе, что вместо callbacks в JavaScript уже давно Promises и async / await, это говорит о его уровне знания JavaScript. Те же кто, репостит таких людей, показывают уже свою несостоятельность.
Если человек не в курсе, что вместо callbacks в JavaScript уже давно Promises и async / await, это говорит о его уровне знания JavaScript. Те же кто, репостит таких людей, показывают уже свою несостоятельность.
Если человек не в курсе, что вместо callbacks в JavaScript уже давно Promises и async / await, это говорит о его уровне знания JavaScript
В 2013 году, когда было написано это пророческое высказывание, не было никаких promises, а тем более async / await — см. news.ycombinator.com/item?id=4495101 . Да они и сейчас как бы не mainstream — все в основном по-старинке на callback’ах костылят. Достаточно сравнить количество популярных npm пакетов с калбэками против пакетов с асинками.
Не знаю кто его назвал пророческим, но рост популярности Node.js за эти 3 года очевиден. Старые библиотеки с callback, конечно, никто не будет переписовать. Они и так нормально работают.
Старые библиотеки с callback, конечно, никто не будет переписовать. Они и так нормально работают.... с callback hell’ом.
Начнем с того, что
callback hellв стабильно работающих библиотеках никого не интересует. Но если у вас другая ситуация, я хотел бы услышать с какими конкретно популярными Node.js библиотеками у вас проблемы. Очень интересно.
На то они и старые, что стабильные и никакой callback hell никого там не волнует. Если у вас по-другому, я с интересом послушаю с какими популярными Node.js библиотеками у вас проблемы. Приведете список?
пророческое высказываниену-ну...
В 2013 годуНу так и зачем вбрасывать инфу трехлетней давности? Когда-то и «640 килобайт хватало всем» ©
Пророческое оно вот в этом:
We will be paying the price of this misguided hyped fad for decades to come.
1) Не вместо, а в дополнение. 2) Promise ещё подключить надо.
1) Да, в языке в дополнение, но по факту вместо 2) У любого серьезного JS программста, проект начинается с настройки Babel, ESLint и JSCS. Так что сразу есть поддержка async / await. А Promises поддерживаются Node.js без Babel с версии 4.x
node js — сильная тема. Много библиотек с готовыми решениями, хорошая производительность, малое время разработки. О чем еще мечтать?) Конечно есть и недостатки... но в целом нормальный язык
О чем еще мечтать?O’reilly как бы намекает engineering.wix.com/...5/04/mIuuwgx-1024×576.jpg :)
www.youtube.com/...fI&feature=youtu.be&t=850
Весь доклад тоже полезно посмотреть.
читаю и вот: а-ха-ха-ха-ха, сарказм по поводу js — это хорошо. только:
1) один язык для фулл-стек разработки, никаких маппингов-конверсий начиная с фронтенда, заканчивая вашей любимой БД (sql/nosql)
2) отличная экосистема
3) быстро создавать быстрые решения
3.1) да-да, веб и сети — это ввод-вывод, а не вычисления
3.2) да-да, писать на js продуктивно можно, юзернейм же не быдокодер, синтаксическо-инфраструктурных ограничений уж точно нет
и не надо про:
1) недостатки динамики
2) о боги, отсутствие (или «неполноценность» ООП)
3) сложности и «магию» асинхронности, а особенно обработки ошибок
4) приколы с конверсией типов
5) сложность поддержки (ака «плохой код коллег по цеху», или отечественный «райтонли» код)
потому что:
1) динамика — это хорошо :) это быстро и удобно
1.1) недостатки у динамики (вообще, а не только js) есть, но они значимо меньше ее преимуществ
1.2) как пример ответа на частое нытье, которое можно слышать от любителей строгой типизации: проверки соответствия сущностей интерфейсам в «оченно критических» местах (проще — в пограничных слоях системы, там, где можно ожидать чего угодно) никто не запрещает делать, благо с интроспекцией все ок. ну и для начала eslint неплохо бы поставить, чтобы не жаловаться на большинство глупых «undefined is not a function»
2) не хочется даже апеллировать к таким возражениям. пожалуйста, сначала вспомните, что такое ООП, а потом прикиньте что реально из этого определения вам нужно, и окажется, что все с этим ок в js
3) промисы, промисы и еще раз промисы, никакой магии — все просто
3.1) вызывайте синхронно-асинхронно (имеется ввиду без заморочек о типе результата функции), бросайте исключения на здоровье (да-да, с on(’error’) тоже все хорошо — ведь эмиттер бросит исключение, если нет подписчиков и у вас есть весь контроль за всем, чем не уследили),
3.2) и в конце цепочки действий ловите все, или на полпути ловите часть — в общем делайте так же как делают все хорошие парни из .NET/Java/etc
3.3) и о да! получайте «реальный» стек вызовов, без потерь цепочки из-за асинхронности (этого не может быть! все знают как тяжело понять асинхронный код! а ошибки — вообще нереально обработать),
4) Number(), String(), Date() - да, да, если сделать Number(’10′) + Number(’10′) у вас будет 20, а не 1010, и не надо про «что же мне везде это делать?» не везде — в пограничных слоях системы (который чаще всего 1: web API вашего приложения)
5) самый классный пункт. ибо криворукость и "writeonly«-сть слабо зависит от спецификации js, но хорошо зависит от аналитических способностей членов команды. никто вам не мешает 1) выбирать, с кем работать, 2) применять паттерны и заботиться о дизайне вашей системы. ну и еще, если у вас реально рокет сайнс — никто вам не мешает один из «реально крутых, считающих модель этого мира ради извлечения всего профита» узлов написать на чем-то специфическом, и общаться с ним по сети (очереди уже сообщений, либо хттп, а может свой протокол поверх тсп — не важно), или «безсетевыми» средствами межпроцессного взаимодействия, а может и маппинг для него написать
---
p. s. если кратко, для «уже взрослых в этой теме» — для веб фулл-стека — самое то. единственная реальная проблема, с которой вы можете столкнуться — это «шальные (неоднозначные) сетевые (не обязательно, но часто) исключения» из модулей, авторы которых плохо позаботились о вас, как о своих пользователях, но от подобных неоднозначных ошибок вы не застрахованы нигде, в том числе работая в строго типизированной интерпрайз среде (о, боги, эта стремная работа с разными версиями разных провайдеров оракл в дотнете, заваленных тоннами как левых так и собственных г*вно-абстракций, как пример. сомневаюсь что за несколько лет там что-то поменялось), только в ноде у вас будет зависимость с открытым кодом, который вы можете понять и пофиксить (часто — потратив не больше 10 минут), а вот с интепрайзом даже за хорошие деньги — все не так уж просто
p. p. s. всегда раздражала многослойность, неповоротливость и отвратительность ложных абстракций, избыточность «слоения». и вот переписанное (по причине критического снижения поддерживаемости ака maintanability) с интерпрайз-стека распределенное приложение (oltp местами с olap) кушает не под 4GB, а под 200MB памяти, 0.05 (а не 0.70) процессора, отклик на порядок ниже (в
Я в предчувствии, когда «успешные» проекты на ноде погрязшие в event hell, будут приходить к пхпшникам или питонистом чтобы переписали на «нормальный» язык.
на «нормальный» язык.хорошо что взяли в кавычки, а то шутку не поняли бы
А подскажите такое. У меня в проекте на бекенде часть кода на С который использует сторонние сишные библиотеки. При переходе на Node можно будет сохранить подобную архитектуру.
какое будущее?Яркое будущее. Вон уже модули антивирусов на node.js пишут
Сам-то ходил по своей же ссылке? Во первых, не модуль антивируса, а всего-навсего менеджер паролей с веб-интерфейсом, идущий в комплекте с антивирусом. Во вторых, открывающий такую дырищу в безопасности, что я бы постеснялся ставить его в пример.
все так. особенно с «Найти толкового пыхаря — та еще задачка». я честно говоря не ожидал.
Почему не имеет? Никуда он не денется. Пока мы тут паримся на тему «чем интересным заняться», плагины на вордпресс тоже кто-то должен пилить.добавлю, и под Magento тоже. и бандлы для собранного на symfony и т.д.
потому я его причисляю к бессмертным ЯП. если еще и бестолковый пыхарь может зарабатывать себе на хлеб и на радость клиенту, то убить его невозможно :)
Вот уж уровень front-end которые ушли от верстки такой зашкаливающий, что они могут спокойно рассуждать про пхпшников. Дожили.
Видимо о людях, которые видят принципиальную разницу в уровне между PHP и фронтендом.
Уровень задач сами понимаете какой
Уровень задач один и тот же.
Одна мысль правильная, у php очень плохая репутация, и посредством зп это определяющий фактор.
Куда с php уйдут, в ноду или не в ноду, это другой вопрос.
Оптимист во мне надеется, что не в ноду, но реалист помнит про Atwood’s law.
Вообще фронтенд повторяет родную нишу php N лет назад.
Интересно, как скоро на js будут смотреть так же, как на php смотрят сейчас.
еще бы, если писать на таких ущербных языках как JS. надеюсь он все таки помрет
JS. надеюсь он все таки помреттолько в ваших фантазиях. рынок он пока удовлетворяет, может со временем сделают что-то получше, но для своей ниши язык очень хорошо подходит
понятно что удовлетворяет, алтернативы особой нет. Просто 20 лет наблюдаю эволюцию вэба. досих пор не смогли сделать вед приложение, которое бы сравнилось по разработке и отзыачивости с дельфи 1.0, 95 года рождения
что вы под этим имеете ввиду?
в этом нет проблемы джс, наибольшая беда веба — это браузеры и html
в том-то и дело, сделали броузер и всунули туда жс и 20 лет пытаются его улучшить, улучшить то, что не рождено летать.
вообще-то сам джс прекрасно работает. все перфоменс проблемы — операция с домом. а так, очень легко и быстро пишутся приложения
и ещё HTTP
алтернативы особой нет
самопохвала?)
Сложные распределенные высоконагруженные проекты на PHP типа TED, Badoo, Wiki, или Youporn) , Photobucket написанные на PHP не думаю, что проще фронтенда..:)
я когда-то писал на PHP — и он проще простого, точнее там не существует сложных задач
вся пыха сводится сделать запрос — вернуть результат, никакой сложной логики на нем не реализуют, а если чтото серьезное то тогда пишут бекенд на джава/плюсы/шарп — а пыха просто выступает фронтом.
я когда-то писал на PHPблин, ну, достойно ж держишься в js-related срачах.
PHP не так плох как его малюют, по крайне мере с версии 5 он более чем норм, как язык.
НО — сложных задач на нем не бывает, ибо если что-то сложное то начинаю плюсы и джаву тулить
Да ладно, Фейсбуки и вконтактики- легкие задачи? Миллиарды транзакций .
эмм... а что в них сложного? миллиарды транзакций это проблема БД, а не ПХП
что значит — сложная задача?
алгоритмически сложная? архитектурно? или как?
отличный вопрос!
по большому счету любые задачи простые, сложности в основном возникают когда не описаны требования, из-за этого и проблемы.
так же могут быть сложные задачи связанные с производительностью, ибо оптимизируя одно, обычно жертвуешь другим, но в определенных случаях очень сложно достигнуть желаемого результата.
но это все лирика. сложные задачи, это те задачи которые требуют чего-то больше чем использование готовых решений, простых подходов, шаблонов. иными словами это когда на решение задачи тратишь более часа (имплементация можеть занять пару месяцев)
под такое определение подходит почти любой проект(вне зависимости от ЯП) — ибо если уже есть готовое решение, не было бы смысла начинать разработку чего-то нового.
вы не совсем уловили мою мысль. к примеру вы делаете проект аля инстаграм, и хотите распознавать образы чтобы им потом делать визуальные наклейки/подписи. вы будете использовать готовое решение для распознавание, БД для хранение самих подписей (тоже готовое решение), фреймворк для взаимодействия, тоже готовое решение, то все ваша работа будет обработать ввод данных, сохранить в БД, вывод данных — это же просто как 5 копеек, а вот если бы вы не имели вышеприведенных готовых решений — задача бы усложнилась
какая красивая теория.
на практике: готовое решение для роспазнавания найди и научись пользоваться, и решай все проблемы по мере поступления.
Какую бд для хранения, скл? ноСкл ? как много запросов ? масштабируем не масштабируем ? какие запросы? какие таблицы ? как индексы строим? итд итп.
фреймворк для взаимодействия,тоже найди и настрой.
Не компьютер сцаинс но и нифига не
просто как 5 копеек
готовое решение для роспазнавания найди и научись пользоватьсячитайте доку (знаю что это не модно, модно туториал от непонятного блогера), и чудеса вам откроются
Какую бд для хранения, скл? ноСкл ?какая нагрузка будет — неизвестно, пока предполагаем что смешанная, лучше выбрать скл, так как его больше знают (и накосячить там тяжелее)
как много запросов ?время покажет
масштабируем не масштабируем ?то же самое, время покажет
какие запросы? какие таблицы ? как индексы строим?это очень простые вопросы, и скорее всего вы это уже делали 100 раз
на самом деле нет ничего сложного, но может это мое субъективное восприятие.
для большинства сложные задачи, это те которых бояться.
читайте доку и чудеса вам откроютсяСразу видно вы с любыми системами дело не имели. Нет серйезно, времени между тем когда вы начали доку читать и когда чтото там откроеться может пройти месяцы. А доки часто много чего не покрывают. Плюс куча багов и странностей в самом компоненте может быть.
какая нагрузка будет — неизвестно, пока предполагаем что смешанная, лучше выбрать скл, так как его больше знают (и накосячить там тяжелее)Это кем предлагаеться? Заказчиком указкой сверху ? Или это вы пальцем в небо тыкнули?
это очень простые вопросы, и скорее всего вы это уже делали 100 разМатематики и компьютер сцаинса, да — нет, но работы немерянно, нужно много чего знать, и желательно иметь опыт.
на самом деле нет ничего сложного, но может это мое субъективное восприятие.для большинства сложные задачи, это те которых бояться.
Сразу видно вы с любыми системами дело не имели. Нет серйезно, времени между тем когда вы начали доку читать и когда чтото там откроеться может пройти месяцы.я прекасно знаю что такое отсутствующая или не актуальная документация. и для меня это часто является блокером при выборе либы. но в целом такие проблемы не столько сложные сколько времязатратные
Это кем предлагаеться? Заказчиком указкой сверху ? Или это вы пальцем в небо тыкнули?это мое решение которые следует из условий задачи, ясен пень что иногда заказчик вмешуется со своим мнением
работы немерянно, нужно много чего знать, и желательно иметь опыт.понятное дело, я с этим и не спорю. я о сложности говорил
я о сложности говорил
там сильно много неизвестных, собственно что и делает задачи сложнее чем положить в базу и достать из нее.
если бы был один браузер со скоупингом цссов то все было бы так же просто как и в пыхе
там сильно много неизвестных,Каких таких неизвестных ? ЧИсто любопытно.
задачи сложнее чем положить в базу и достать из нее.
Куча браузеров с кучей особенностей, и везде все должно работать.
Я понимаю что иногда даже работа с базой может быть достаточно не тривиальной, но и в таких случаях пхп просто промежуточный слой.
Поймите, я не считаю пхп недоязыком, просто те задачи для которых он в основном используется для меня скучны, и я считаю их простыми
Куча браузеров с кучей особенностей, и везде все должно работать.Это точно также из разряда
это очень простые вопросы, и скорее всего вы это уже делали 100 раз
на самом деле нет ничего сложного
Поймите, я не считаю пхп недоязыком, просто те задачи для которых он в основном используется для меня скучны, и я считаю их простыми
Пых предсказуемей питона. Его недостатки отлично изучены. А фреймворков и готовых продуктов — не меряно.
С точки зрения бизнеса — не очень понятно зачем питоном заменять пых. Руби вместо пыха — вижу смысл.
Насчёт серьёзности, тоже не очень понятно. Конечно для продукта типа Касандры пых не годится.
Но глядя на типичные CRUD на джаве... Особенно когда бизнес-логику пишут на Pl или T SQL — на джаве пишут всего лишь прослойку.
Я недавно столкнулся с пыхом. И отчётливо вижу что их вообще то два. И вся массовая критика это про первый пых. От одного вида кода начинает тянуть на рвоту.
Про второй же рассуждающие о пыхе ничего не знают. Хотя ему не один год. Как и проектам на нём.
Ну это как примерно смеяться над джс — а что на нём написано то, снежинки? Ах да, великая библиотека jQuery.
Пых предсказуемей питона.
Тут бы подробностей, а то выглядит крайне странно.
не очень понятно зачем питоном заменять пых. Руби вместо пыха — вижу смысл.как это — питон вместо пыха «нет смысла», а руби вместо пыха — внезапно «есть смысл»?
Ведь по сути руби и питон почти одно и тоже) питон разве что в большем количестве областей используется почаще, чем руби.
если же имеются ввиду рельсы, то у питонистов есть контраргумент в виде джанги и фласка)
Ну большинство идей современных веб -фреймворков были содраны с ruby-on-rails в свое время, ну и типа фласка- в руби есть капистрано..
оно то так, но это не отменяет того. что питон не менее достойный кандидат на замену пыха)
да и у меня почему-то есть подозрение, что на питоне веб-фреймворков все-таки больше, чем в рубях. Хотя возможно я ошибаюсь, ибо питон мне более интересен, чем руби (так исторически сложилось) и поэтому я не в курсе, сколько веб-фреймворков на руби написано.
возможно я ошибаюсь, ибо питон мне более интересенне «возможно» — а вообще и напрочь :)
когда вам станет все равно, когда у вас не будет ЯП любимчика, тогда мнение и изменится.
а пока напоминайте себе:
поэтому я не в курсе
просто наввскидку я могу перечислить минимум 10 штук питоновских веб-фреймворков в отличие от руби. Да я знаю названия самых пары наиболее известных. но не более — я ж не руби-девелопер :) . Не сомневаюсь. что спецы по руби назовут больше фреймворков для руби. чем я для питона)
хотя по большому счету, что это меняет? на пхп пилят сайты? пилят. На питоне и руби пилят? — пилят. на ноде пилят — пилят? так что думаю любители любого из перечисленных языков могут быть довольны, что их язык/фреймворк востребован в данной области)
просто наввскидку я могу перечислить минимум 10 штук питоновских веб-фреймворков в отличие от руби.
кстати, надо было бы с пяток, раз навскидку перечислить.
но суть не в том — да хоть стопицот их будет.
каков процент команд их использует? в каком проценте законченных проектов?
на пхп пилят сайты? пилят. На питоне и руби пилят? — пилят. на ноде пилят — пилят?не поверите, и на Haskell и на Smalltalk (Pharo) пилят!
хотя по большому счету, что это меняет?аргумент блондинки — «а вот я знаю случай» я не обсуждаю.
аргумент блондинки — «а вот я знаю случай» я не обсуждаю.
не поверите, и на Haskell и на Smalltalk (Pharo) пилят!ну вот как раз эти «аргументы блондинки» действительно можно и не обсуждать)
кстати, надо было бы с пяток, раз навскидку перечислить.хорошо. помимо джанги и фласка: Bottlepy, Webpy, web2py, Tornado, Cherrypy, Twisted, Zope, TurboGears и всякие менее известные. Конечно понимаю, что их меньше, чем у пхп, и больше всего используются джанга с фласком, но ведь и в рубях св основном используются рельсы, ну может быть еще синатра или упомянутый уже кем-то падрино.
каков процент команд их использует? в каком проценте законченных проектов?это уже вопросы не ко мне. а к профессиональным питонистам — они лучше такую статистику знают)
Эту статистику можно получить на сайтах типа builthwith.com
Конечно не забывая об интранет проектах, которые пишутся обычно на джаве или сишарпе.
А есть еще слух что мир девопса, где питон был лидером переходит на голэнг.
В общем ищите инфу более адекватную чем личные вкусы
Эту статистику можно получить на сайтах типа builthwith.comну есть еще плагин для огнелиса и хрома под названием Wappalayzer)
А есть еще слух что мир девопса, где питон был лидером переходит на голэнг.так пожалуйста, пусть переходит — я ж не против) как по мне Go вполне годный язык (в т.ч. и для девопса).
В общем ищите инфу более адекватную чем личные вкусытак вы ж не знаете, какие у меня личные вкусы, и какую инфу я обычно ищу)
Я вот знаю вокруг себя нескольких программистов на Django и живые проекты, но ни одного не знаю с RoR.
Это личный перекос, или в наших краях кто-то дискриминирует Ruby?
Каков процент вашего круга от всех программистов?
Каков процент этих нескольких, от «вокруг себя»?
Немного. Но важно не это, а что их >0, а для RoR ==0.
Кому важно, вам? А кто вы, что ваше мнение на основе десятка ваших знакомых считаете значимым?
Понятно. Возвращайтесь в школу, учиться читать и понимать прочитанное.
В наших краях типичные Rails проекты:
Тогда понятно, спасибо.
раздел вакансии на ДОУ говорит о примерном паритете кол-ву вакансий Python и Ruby(~50+).. Кол-во вакансий по PHP смотрит на них вместе взятые и смеётся :)
Зато в среднем PHPʼшник получает на 500 меньше. (Статистика этого сайта)
Но речь что была про Python\Django vs Ruby\Rails в кругу Вашего общения? не? как бы число вакансий в открытом источнике это нечто исчисляемое в отличии от Вашего круга знакомых :)
А теперь уберите вакансии овнокомпаний где цмски копают, отфильтруйте так сказать на нормальные, с фреймворками, и потом поглядите можно ли смеяться.
И шо там? в Киеве больше 90 вакансий.. с CMS-ками насчитал аж 5 вакансий + 2 вакансии тренер PHP + 1 битрикс(мне кажется даже Wordpress будет чем то приличным в сравнении с этим :))... в половине вакансий явно указан фреймворк Symfony2, Laravel или Yii2 + e-commerce плафторма Magento.. продолжаем улыбаться и махать :)
Ну большинство идей современных веб -фреймворков были содраны с ruby-on-rails в свое время
Это неверно. RoR сам начался как передирание основных принципов питоновского Zope и ближайших последников.
«„„Zope stands for „Z Object Publishing Environment“, and was the first system using the now common object publishing methodology for the Web. Zope has been recognized as a Python killer app, an application that helped put Python in the spotlight.““» ([википедия])
Выделение про «the first» моё.
Сейчас Zope мало известен, особенно при наличии Django и тому подобных, но местами используется до сих пор.
Одна из главных «фишек» которую принес RoR была «Convention over configuration», что в свою очередь позволили реализовать известный Perl’овый завет «делать простые вещи просто, и делать сложные вещи возможными». Что в свою очередь запустило цепную реакцию из фреймворков «таких же как RoR» или «проще чем RoR». Не совсем понятна отсылка к Zope — это точно не был первый веб фреймворк, и помнится это достаточно мудренная штука.
Между делом, так получилось, Rails-сообщество внесло большой вклад в популяризацию концептов существовавших задолго до, типа того же Active Record паттерна, MVC, тестирования вообще и TDD в частности. Это не их изобретения, но они и не из мира Python пришли.
Не совсем понятна отсылка к Zope — это точно не был первый веб фреймворк,
Как объектный — пишут, что первый, и у меня нет причин не верить.
и помнится этion о достаточно мудренная штука.
Да. И это отличная иллюстрация к тезису, что «помнят вторых, а не первых». RoR пришло на поле, где уже прошли первые испытания концепций и отобрано лучшее за этот круг.
То же convention over configuration — банальность, изобретавшаяся тысячи раз заново. В RoR оно просто было явно введено там, где это могли шумно заметить.
Rails-сообщество внесло большой вклад в популяризацию концептов существовавших задолго до
Про это ничего не скажу, не видел, но вы сами говорите, что всего лишь популяризовали :)
А вообще по этому вопросу
как это — питон вместо пыха «нет смысла», а руби вместо пыха — внезапно «есть смысл»?я бы послушал Елену Моргун)
Насчет изученности особенности браузеров — я их столько видел что голова кругом. И джквери ни разу не спасает, только на простых различиях
А ви точно Senior JavaScript Developer ?
Ну раньше был тех лидом, а теперь задаунгрейдился. А что вас смущает?
вся пыха сводится сделать запрос — вернуть результат, никакой сложной логики на нем не реализуют, а если чтото серьезное то тогда пишут бекенд на джава/плюсы/шарп — а пыха просто выступает фронтомРасскажите это разработчикам фейсбука, вконтакте, вордпресса и остальных 90% наиболее посещаемых сайтов, написанных на пхп.
фейсбукапоимели геморроя от выбора пыха
вконтактепоимели геморроя от выбора пыха
вордпрессаовнокод и еще оно тормозное говорят. Но типичным клиентам хватит
и остальных 90%легко быть везде коль конкуренции нет, именно на этом он и взлетел. А вообще как говорилось в вебе всем забить на качество языка, главное подешевле чтоб было.
Фейсбук/контакт — пхп своего рода интерфейс к БД, и с ней у них куда больше беда, плюс оба ушли с оригинальной пыхи
вордпрес — дешево и сердито, бложик чем то серьезным считаться не может
вордпрес — дешево и сердито, бложик чем то серьезным считаться не можетВ основном да, но и на вордпрессе есть не только бложики ,а порталы мировых брендов с огромной посещаемостью тоже)
time.com
www.nasa.gov
www.bbcamerica.com
www.sonymusic.com
www.forbes.com
www.nytco.com
www.nasa.gov
www.mercedes-benz.com/en
Интернет магазины:
vanheusen.com
www.champagnewarehouse.com
в ит-тусовке сложилось не просто плохое отношение к PHP.
а — гробовое табу на хоть что-то о нем хорошее. вот о любом ЯП можно, а о PHP все, категорически низя. это даже не моветон, это как... сказать что хорошего было в идеях мягкого («средиземноморского») фашизма.
из-за этого табу юные начинают уверенно утверждать нечто вроде
вся пыха сводится сделать запрос — вернуть результат, никакой сложной логики на нем не реализуют
и убедить в обратном не получится. это уже вопрос Веры. а она тем прочней тем невежественней верующий. обычно он еще и в гугле забанен.
Простите, пхпшник это что-то сложное? Фронтенд современный в разы тяжелее, чем выполнить запрос к БД
Задача фротенда — принять запрос от юзера и отрисовать результат. На этом всё. С помощью каких бубнов это делается — вопрос второй.
Я не оспариваю простоту пыхпыха. Просто надо снять корону и перестать тут рассказывать о том, что фронтенд является чем-то тяжёлым для освоения и там нужно для каждого чиха считать О.
О во фронте считается крайне редко. Короны нет. Основная проблема фронта не джс, а цсс, хтмл и то как их браузеры поддерживают.
Сложность фронта что вам надо добится однородного поведения при куче разных окружений.
Если бы фронт зависел только от джс, он был проще паренной репы
Фронтенд современный в разы тяжелее, чем выполнить запрос к БДох.
бекенд — не только CRUD.А на чистом пыхе бывает чтото кроме ? (:
понятное дело что не только. но как появляется ресурсоемкая задача (что-то тяжелее получить данные, отправить данные) ее начинают пилить на чем-то другом, а пыха просто проксирует туда запросы
так может дело не в самом пыхе, а в интерпретаторе пыха? Пока движок V8 не придумали — js тоже годился только рожицы рисовать в браузере..
а я тут где-то писал, что как язык ПХП сам по себе даже очень ничего. не хватает возможно потоков, но их отсутствие в основном обусловлено его интерпритатором
но как появляется ресурсоемкая задачаможно конкретики чуток?
сама реализации БД является ресурсоемкой задачей. по сути это вам и ответ.
ресурсоемкая задача, эта задача решение которой требует больше ресурсов чем те которые можно покрыть простым вертикальным масштабировании, при удовлетворении текущих требований и без изменения реализации.
как-то так
сама реализации БД является ресурсоемкой задачей. по сути это вам и ответ.я понял. то есть, это тогда ко всем языкам относится, кроме С++
нееее =)
к языку это не привязано, можно ресурсоемкую задачу и на пыхи решать, просто обычно в виду ее производительности это не выгодно. кстати наличие HHVM говорит что даже фейсбучек до этого дошел
Пользуясь случаем хочу спросить. Пишу свой первый проект на node, на sails фреймворке. И меня очень печалит обработка ошибок. Предположим мне нужно сделать запрос к базе данных и работать с результатом.
В php все просто — одна строчка кода — получили результат, и начинаем с ним работать.
Если произошла ошибка в процессе выполнения запроса — мне не нужно писать никакой дополнительный код. Ошибка или выведется на экран, или в логи.
Если вернулся пустой результат, а мы в коде ожидаем что прийдет объект, с которым мы дальше работаем — тоже ничего страшного. На экран/в логи вывалится ошибка при первом же обращении к result.какое_то_свойство. Опять же дополнительный код писать не нужно. Ибо мы предполагаем что результат будет не пустой, а если он по каким то причинам пустой — значит что-то пошло не так, дальше все равно ничего работать не будет, и вывести ошибку вполне ок.
Здесь же я делаю запрос в базу, и пишу коллбек, в который приходит 2 параметра: error и result.
Сначала мне нужно написать что-то типа:if (err) { return res.serverError(err); }
Для каждого асинхронного действия. Иначе ошибка молча проглатывается и поведение приложения дальше непредсказуемо.
Далее мне нужно написать что-то типа:if (!result) {return res.send("Nothing found"); }
опять же для каждого асинхронного запроса. Иначе если result пустой, а дальше код начинает работать с объектом result, то вебсервер пишет ошибку что result.какое_то_свойство не существует, падает, а пользователь видит что сервер ничего не ответил. Веб сервер нужно запускать заново.
В результате для каждого асинхронного действия, то есть практически для каждого, код переполнен проверками, что асинхронное действие произошло без ошибок, и действительно вернуло результат. Это начинает напрягать. Это я чего-то не понимаю в архитектуре ? Или все так и пишут ?
люди пишут через промисы, коллбеки уже никто не использует. но вообще в любом языке должна быть обработка ошибок — это нормально
Я скорее о том писал, что в синхронных языках ошибка нормально всплывает наверх из любого участка кода. И мы вполне можем уже на самом верху посмотреть что это за ошибка. И можем даже вообще не писать никакой код для ее обработки — она просто выведется на экран или в логи.
Здесь же постоянно приходится или разбирать ошибки после каждого действия, или самостоятельно пропихивать ее дальше наверх. А если вдруг ошибся и не написал очередной if (err) next(err);
то приложение может запросто дальше работать. И потом мучительная отладка где же все таки мы не проверили результат на ошибку.
Информативность ошибок меня тоже огорчает. Иногда совсем непонятно — что случилось, где случилось. А если что-то случилось в недрах 3rd party библиотеки — то стектрейс вообще бесполезен.
Ну и самое последнее — я думаю проблема как-то решается, но на данном этапе если в приложении произошла ошибка и мы ее не обработали — падает веб сервер. Для меня это в новинку. Эта ситуация вообще исправляется ?
никакой код для ее обработки — она просто выведется на экран или в логи.
Список, тамщемта, можно продолжать бесконечно.
А если что-то случилось в недрах 3rd party библиотеки — то стектрейс вообще бесполезен.стектрейс бесполезен не в этом случае, а когда асинхронность.
А если что-то случилось в недрах 3rd party библиотеки — то стектрейс вообще бесполезен.
Обработка ошибок в асинхронном коде — колдовство, которое мало кому удастся постичь, и даже промисы только частично решают эту проблему.
Тот факт, что в 99% примерах использования ноды обработка ошибок отсутствует это подтверждает.
Помимо того, что промисы делают реджект, колбеки содержат коды ошибок, нужно еще подписываться на кучу on("error", ...), иначе асинхронные ошибки в непонятных местах будут просто валить все приложение с абсолютно неинформативными сообщениями об ошибках, причем не всегдя понятно, это ваш код или что-то упало в одной из миллиона библиотек, подтянутых npm-ом.
все так.
и если очень утрировать, то
в системе построенной на событиях не бывает ошибок. в ней все есть — событие.
в системе построенной на событиях все функции, объекты, и прочие «черные ящики» всегда возвращают — результат своей работы. «ошибка» — это всего лишь вид этого результата, названный так в силу бытовой привычки называть неприятный, неожиданный результат ошибкой.
таким образом в системе построенной на событиях для обработки «ошибок» неправильно, нелогично использовать какой-то особый механизм или convention. так как ошибка это такой же, равноправный с остальными, результат действия, то и обрабатываться она должна так же, наравне с другими. темы же способами.
нужно еще подписываться на кучу on("error«, ...),да. и все ожидающие результата — должны содержать реакцию и на этот вид результата — ошибку.
потому в системе построенной на событиях вообще-то нет никакой «вертикали власти», нет иерархии подчинения.
некому пожаловаться наверх — а мне вот вернули фигню какую-то под названием «ошибка» вместо среза котировок акций. некому передать наверх — я а не знаю что мне с этим делать делать, все, я закончил свою работу.
нет радной, раз ты впрягся в работу, то ты обязан не хныкать, а четко отреагировать как и во всех остальных случаях. или — делегируй обработку этого события явным, обычным способом — расскажи что ты хотел получить, покажи что получил, и сообщи соседям что ты пока ничего не можешь сделать с таким результатом и — жди их ответной реакции. причем — не от начальника, его нет, а незнамо от кого, кто окажется самым знающим, и пришлет ответ — что тебе дальше делать. наверное это будет — «да забей». но решать это не тебе.
конечно, можно присобачить паттерны привычные для кода с явным, четким потоком выполнения.
в конце концов код на ООП языках частенько вовсе не оопшный, а процедурный.
но чем больше размер системы, тем этот гибрид будет выворачивать мозги программисту все сильнее, чем
либо ты переходи на идеологически правильный дизайн «системы основанной на событиях»
либо — отказывайся от него вообще
никаких коллбэков, пиши через try catch и будет тебе счастье
от устаревший — там нет данных за 2015 год.
Такие темы нагоняют на меня вселенскую печаль. Неужели столько трудов и поисков правильного языка программирования привели к javascript?
Правильный язык для каждой ниши свой. Универсального пока нет )
прям вспомнил этот известный твит twitter.com/...status/476934214579810304
У современного PHP нет конкурентов.
И это при том что ещё в обещаниях асинхронный ввод-вывод.
А вот у ноды такой конкурент появился GoLang. То есть в той же нише где нода крута.
Итого, в ближайшие годы станет ясно, кто кого. И зависеть это будет как обычно — от скорости разработки.
У современного PHP нет конкурентов.В какой нише? Почему в этой нише питон, руби (и та же нода) для него не являются конкурентами?
Ну если речь о нишах, то да, там в нишах много чего есть.
Что же до намека что времена ЛАМП прошли, и что всем выделенные сервера, и т.д.
То читая такие заявляния одно на ум приходит, а слона то я и не приметил, зато муху в нише разглядел.
зависеть это будет как обычно — от скорости разработки.По скорости разработки Ruby и Python всех рвут. Да и код на них легко читаемый и легко тестируемый..
Если бы рвали — то эт было видно по числу и размеру проектов. А так как не рвут, то php и не подвинули.
Конечно, если б пых остался на уровне 4ой версии...
Но почему-то они не смогли кардинально подвинуть PHP....Свежий рейтинг Tiobe с Вами не согласен www.tiobe.com/...paperinfo/tpci/index.html
Хех, бейсик и делфя живее всех живых
вы о Python? а то что его несколько лет как сделали основным ЯП в западных колледжах — учитываете?
и то что он для многих стал заменой матлабов с статграфами — тоже не забывайте.
то есть у меня большие сомнения что популярность Python’у сделали профессиональные программисты. профессиональные — это те кто зарабатывают деньги тем что пишут программный код. непрофессиональные — это для кого написание кода побочное действие, неосновная деятельность.
там еще Visual Basic .NET наверное такой же — удобный язык для непрофессионалов. хотя думаю профессионально и на нем пишут, как и на Python
вопрос же был о скорости разработки, то — есть об оценке ее профессионалами на практике и особенно — компаниями которые продают услуги по созданию ПО. а в бизнесе продажи услуг разработки — скорость разработки если не первый, то в тройке основных факторов успеха.
Замена матлаба — это R.
а там где преподают статистику — преподают Python а не R. обычно.
и думаю большинство экономистов, социологов, и т,д. начав работать будут переучиваться с Python на R.
нафига? Если 95% заданий экономистов и социологов- можно сделать макросами VBA в Екселе.
Или вы имеете виду -математиков -программистов, работающий в сфере экономики или статистики?
Если 95% заданий экономистов и социологов- можно сделать макросами VBA в Екселе.так и делалось, и будет делаться. только не знаю про 95%. SPSS и STATGRAF видел вживую, как и мнение тех кто ими пользуется и Екселем.
Или вы имеете виду -математиков -программистовнет, ни математиков, ни программистов ввиду не имел.
где-то даже на доу пробегало, в темах технари vs гуманитарии что на социологии в Могилянке изучают Python. для будущей работы пригодится, наравне с Екселем, SPSS и т.п.
попытки сделать программирование — частью общей компьютерной грамотности со школы (в США и Великобритании) думаю добавят популярности Python. Наверняка он будет выбран в качестве основного в рамках школьных курсов.
Наверняка он будет выбран в качестве основного в рамках школьных курсов.Жаль..мне больше Руби нравится из подобных языков, например, ничего личного, просто Питон, как и C # излучают флюиды академичности, с одной стороны- это хорошо, с другой с опаской отношусь к образовательным языкам.
пайтон подбешивает чуток индентами, но это так, некритично
На текущий момент, наверно все таки нет, что будет дальше сложно сказать, как и в любой другой нише. Хотя благодаря своей(PHP) простоте тенденции наверно сохранятся.
конечно и я не пророк.
но появление GoLang вообще-то можно было спрогнозировать.
По признакам появления и свойств Node.js — в основе ЯП который никогда не задумывался как ЯП для сложных приложений. Само появление Node.js — «народное творчество».
то есть утрировано Node.js не занял нишу, а он ее высветил, создал. Это примерно как классическое
До Сони Уокмен — нишы носимых плееров не было. До Ксерокса — не было нишы копировальных аппаратов.
а вот после того как она появилась, стала известна, — будут появляться более специализированные устройства для нее.
благодаря своей(PHP) простотеэто массовое заблуждение из-за — прошлого PHP, и низкого порога входа, потому что PHP сохранил совместимость. Не сохранил ссылки, интересной попытки рассчитать в цифрах семантическую сложность ЯП. PHP немногим проще С++ оказался.
Node.js не занял нишускорее просто дополнил, или добавил ветвистости )
Проста — Javaсам по себе синтаксис да, но она же без кучи фреймфорков как таковая никому не интересна(Android отдельная тема), поэтому если говорить комплексно, то лес еще тот.
Работаю с нодой 3 года, с версии 0.8. Много букв
Плюсы:
1.Способность держать овермного «сквозных» реквестов. В самом распространённом случае, сервак не ждёт, когда БД ответит, а обрабатывает ещё остальные реквесты, то же самое с I/O, сообщениями/реквестами, заливкой файлов на S3 и так далее и тому подобное (Вы скажете твистед и прочее event loop based, но совсем не торт, асинхронная модель пайтона и иже с ними до ноды не дотягивает)
2. Streams Streams Streams! Нет, серьёзно, это круто, как с точки зрения архитектуры, так и memory efficiency
3. Масштабируемость заложена в дизайне. Вы никогда не будете запускать 1 процесс ноды. 10, 20 (Наш потолок — 24 на одном сервере с 24 ядрами)
4. npm. Самый вменяемый пакетный менеджер, из тех, что я видел
5.Возможность писать изоморфные универсальные приложения, работающие на клиенте и на сервере, что абстрагирует фронтендщиков от бекенда — профит очевиден, бэки не занимаются ерундой и написанием темплейтов, и сконцентрированы на АПИ
6.Легковесность. Как упомянуто выше, очень помогает в разворачивании банды микросервисов
7. Javascript же! Он и был приятен(ну лично мне, по крайней мере), а с выходом ES6 и генераторов избавился от детских болячек с контролем асинхронности, так что сейчас как никогда приятно на нём писать
Минусы
Их тоже хватает.
1.Самый главный, на мой взгляд — Порог входа. Манки кодить на ASP.NET MVC, к примеру, зажатым конвеншенами, фреймворком и строго типизированным языком, куда проще. Как следствие — поиск специалистов — нетривиальная задача. Но есть и плюс, если человек пишет на ноде, то он в большинстве случаев знает, что он делает
2.Без тестов в ноде делать нечего. Снова серьёзно. Если писать ноду без тестов — лучше возьмите что-нибудь другое.
3.Совершенно не подходит для математических операций, тяжёлого рендеринга(Да и для лёгкого, в силу синхронности этого дела, не очень), и вообще любых «не сквозных» операций. Перебрать массив на 2000 айтемов — нет. Держать в памяти KD-tree с индексами или хэштаблицу — нет.
4. Как дополнение к пунктам 1 и 2, необходимость очень тщательно следить за кодом и обрабатывать ошибки.
З.Ы. Golang тоже пишем, но там всё довольно печально с менеджментом зависимостей и вообще читабельностью кода. Возвращать по 2 объекта из функций — ВЦ. Надо привыкать. Пока, ИМХО, писать на нём что-то больше микросервиса на 3 файла — самоубийство.
В самом распространённом случае, сервак не ждёт, когда БД ответит, а обрабатывает ещё остальные реквесты
Это надо понимать так, что у всех остальных сервак останавливается и ждёт? Прямо весь сервак?
Не, я догадываюсь, что имелось в виду, но вы хоть слова выбирайте как-то.
хм, ну грамотному человеку и так ясно. Насколько я помню по .net, поправьте меня, если я ошибаюсь, поток, выделенный из пула IIS ждал пока отработает поток, взятый из пула CLR, а тот в свою очередь ждал ответа от БД. Даже после async подхода и возвращения потока IIS в пул, поток взятый из CLR всё равно ждёт и занят.
Ну если цепляться к словам, то да. Не сервер, поток. Вы совершенно правы :) Я как-то привык считать уже 1 поток — 1 процесс ноды — 1 «сервер»
поток взятый из CLR всё равно ждёт и занят
У ноды точно так же «ждёт» состояние с callback’ом. У forking server’а ждёт процесс.
И пока один ждёт, другой чего-то делает, где-то идёт I/O и т.д.
Принципиальной разницы нет. Есть тонкие детали переключения между контекстами.
Оттенки зелёного в фразе green threads.
Нода немного зеленее среднего по больнице, но не более того.
У ноды точно так же «ждёт» состояние с callback’ом.Насколько я помню, libuv подписывается на события I/O ОС. и уж никак не ждёт пока что-то отработает.
Или я чего-то не понимаю?
В дотнете тоже ничего не блокируется msdn.microsoft.com/...us/magazine/dn802603.aspx
ага, один хрен, впринципе, если не брать во внимание всё продолжающееся выделение 1 потока сервера на 1 запрос.
Вы статью, на которую вам дали ссылку, вообще прочитали?
libuv подписывается на события I/O ОС. и уж никак не ждёт пока что-то отработает
Вот примерно то же самое происходит и в .NET, если правильно пользоваться асинхронным вводом/выводом. Почитайте, если интересно, что такое I/O completion ports — эта штука была заложена на уровне самой О/С еще до появления дотнетика. Есть, кстати, смутные подозрения, что и Нода на винде пользуется теми же самыми I/O completion ports.
То о чём вы говорите называется неблокирующий I/O , и api для него есть во всех OS (epoll для Linux , completion ports для win) , Python/Php/Perl/.Net/Java/etc — у всех есть возможность работать с этим api , но в основном используют блокирующий I/O + fork/thread (imho) так как это проще в написании и понимании кода .
epoll для Linux
Спасибо, буду знать, как называется аналогичная технология в Linux.
но в основном используют блокирующий I/O + fork/thread
В .NET была и есть такая беда из-за того, что Microsoft во многих примерах кода в своей документации не делали достаточного акцента на необходимости неблокирующего ввода/вывода. Что гораздо хуже, родная Microsoft’овская ORM начала поддерживать из коробки неблокирующий I/O только в самой последней версии — и то, я не уверен, что эта версия пока еще не beta.
Вместе с тем, в последних версиях .NET пользоваться неблокирующим вводом/выводом ни разу не сложнее, чем в Ноде — по сути, те же промисы. В ES6 даже синтаксис (async/await) очень похож на C#.
libuv подписывается на события I/O ОС. и уж никак не ждёт пока что-то отработает
libuv и event loop в ноде это часть юзерспейс шедулера. «Мини-ОС». Внутри которой живут свои node-процессы. Они же green threads, контексты, треды, х.з. как оно в ноде называется.
Вся эта конструкция повторяет ядро обычной многозадачной ОС. Вместо процессора с физическими ядрами thread-pool, вместо аппаратных прерываний события libuv/epoll. Вместо процессов green threads. Принцип работы очень похожий. В обычной ОС блокируются и ждут нативные процессы, в юзерспейс ОС блокируются и ждут её внутренние процессы.
У юзерспейс ОС переключение контекстов немного быстрее, ради чего это всё и затевается.
Но принципы многозадачности те же самые. Нельзя сказать, что нативные треды блокируются и ждут, а зелёные нет. Ждут и те, и другие.
Сравнивать один нативный тред со всей юзерспейс ОС не очень корректно, они разными вещами занимаются. Сравнивать можно пачку нативных тредов с пачкой зелёных. И там всё очень похоже, пока один ждёт — другой работает.
Спасибо за отличный ответ!
Одни говорят «фе, нода однопоточная, какой же ущербный этот javascript!», другие «так ведь это хорошо, что однопоточная, не нужно задумываться о гонках, семафорах и т.п.» третьи «да нет же, вот они, потоки, просто о них разработчик о них не задумывается, в других платформах то же самое!».
В libuv самые что ни на есть нативные треды. «Внутренние процессы» — это коллбэки, вызываемые из event loop? Это ж не одно и то же.
И там всё очень похоже, пока один ждёт — другой работает.Расскажите это тем, кто семафоры и мютексы пихает.
поправьте меня, если я ошибаюсьОшибаетесь. Асинхронные операции в .NET поддерживаеются, если я првильне помню, со второй версии. Но писать асинхронный код было довольно сложно. TPL и async/await значительно упростил жизнь. И запрос не обязательноо должен обрабатываться тем же потоком. Можно сконфигурить чтобы продолжал выполнение после завершения асинхронной операции любой свободный поток из пула. Так что асинхронные операции в .NET на столько эффективны на сколько это возможно. Блокирующих операций можно полностью избежать.
Асинхронные операции в .NET поддерживаеются, если я првильне помню, со второй версииС первой
Но писать асинхронный код было довольно сложно.Ничего сложного, особенно если сравнивать с JS.
Нарешті. О це вже дискусія)
1.Способность держать овермного «сквозных» реквестов.В php це також робиться, я всі імпорти і парсери так пишу, якби чикати відповіді з бд, то можна до ранку імпортуати, для паралелізації використовую джермана.
2. Streams Streams Streams!Аналогічно.
Але для мене ще й дуже важливо, що для php я можу написати додаток(модуль) та частину його вшити в c++ розширення:
1) закриває важливу частину від копіпасту
2) можна значно покращити роботу додатку
3)можна працювати з різними бібліотеками, особливо при обробці зображень та відео
З php проблем масштабування також немає — Redis
Тут как бы не особо корректное сравнение выходит. Вот если сравнить, reactphp.org и ноду, то будет долее контекстуально.
Але для мене ще й дуже важливо, що для php я можу написати додаток(модуль) та частину його вшити в c++ розширення:Та же история и с нодомодулями.
2. Streams Streams Streams!Пусть у меня js головного мозга, но более читаемого и удобного чем
Аналогічно.
Sergiy Kyrylkov
Dmitriy Chaban
Oleg Kariakin
Evgen Petrov
Dmitriy Mozgovoy
Andrew Ivanov
Lyova Zi
Sergei Epatov
Evgen Petrov
Vitaliy Ryumshyn
Алексей Орленко
Viacheslav Demeshko
Alexander Makeev
Віталій
Kemal Smaylov
undefined pointer
Bogdan Shyiak
Volodymyr Sokolovskyi
Alex Koshterek
Andrii Hrachov
Dmytro Lapshyn
Андрей Литвинов
readableStream.pipe(transformStream).pipe(writableStream) не встречалПусть у меня js головного мозга, но более читаемого и удобного чемугу, как обычно не забываем про обработку ошибок
readableStream.pipe(transformStream).pipe(writableStream) не встречал
З.Ы. Golang тоже пишем, но там всё довольно печально с менеджментом зависимостей и вообще читабельностью кода.
Для менеджмента зависимостей идеально подходит vendoring — это когда исходники всех зависимостей кладутся в папку vendor рядом с исходниками программы. Тогда программу можно собирать сразу же после git clone прямо из исходников, не парясь про внешние зависимости. Для оппонентов — аналогичным образом организованы исходники Google chrome.
Насчет читабельность кода во Go — вы, скорее всего, слишком привыкли к callback hell’у в коде nodejs. Поэтому любой код без калбэков кажется вам непонятным. Не волнуйтесь — это должно скоро пройти. Обычно код на Go читается легче, чем код на nodejs.
Пока, ИМХО, писать на нём что-то больше микросервиса на 3 файла — самоубийство.Это заблуждение. Например, Docker написан на Go. Там явно больше трех файлов.
Обычно код на Go читается легче, чем код на nodejs.После ES6 генераторов, control flow на ноде перестал быть колбэчным — просто нет смысла.
response, err := client.Get(request.URL.String())
if err != nil {
fmt.Fprintf(writeHandler, "Error %d", err)
}
или
if _, err := w.Write(buffer.Bytes()); err != nil {
log.Println("unable to write image.")
}
Это заблуждение. Например, Docker написан на Go. Там явно больше трех файлов.
При всей моей любви к докеру, для меня это загадка века и вызывает раболепное восхищение. Видимо, действительно, привыкнуть надо.
Для менеджмента зависимостей идеально подходит vendoring — это когда исходники всех зависимостей кладутся в папку vendor рядом с исходниками программы
Спасибо за совет, надо будет попробовать :) А то все эти игры с GOPATH до добра не доведут, всё таки приятней когда оно под ногами всё лежит.
После ES6 генераторов, control flow на ноде перестал быть колбэчным — просто нет смысла.он перестал быть колбечным, но читаться от этого он ощутимо лучше не стал, так как, что генераторы заработали с промисами, код приходится вставлять в другие обертки.
самый простой способ — thunks и control flow с помощью либы co. нет в них ничего военного.
На данный момент самый простой способ — без всяких левых либ, используя коробочный компилятор и библиотеку классов C#/.NET
почему не Java?
Наверное, потому что в джаве на уровне компилятора никаких плюшек для асинхронности нету?
А, точно. Ну что имеем в итоге?
1.в ES6 нету async await. в будущем ES7 они есть. Использовать уже можно сейчас с помощью babel.
2. async await в шарпе работает через Task API, насколько я помню, и это по сути те же промисы. Зачем платить больше?
З.Ы. Golang тоже пишем, но там всё довольно печально с менеджментом зависимостей и вообще читабельностью кода. Возвращать по 2 объекта из функций — ВЦ. Надо привыкать. Пока, ИМХО, писать на нём что-то больше микросервиса на 3 файла — самоубийство
Чтобы понять, на чем проще писать и где лучше читабельность, напишите на nodejs функцию, последовательно опрашивающую переданной ей список http адресов. Это не должно составить труда для опытного ноджс разработчика. Вот соответствующий код но Go:
func PingURLs(urls []string) {
for _, url := range urls {
err := PingURL(url)
if err != nil {
DBUpdateURLError(url, err)
} else {
DBUpdateURLSuccess(url)
}
RedisIncURLPingCounter(url)
}
}
Предположим, что у вас уже реализованы все функции, использованные в PingURLs. И все они отправляют данные по сети и ждут ответа, который может прийти через несколько секунд после вызова соответствующей функции.function *pingUrls(urls) {
for(var url of urls) {
var response = yield * pingUrl(url);
if (response.statusCode <= 302) {
yield db.updateUrlSuccess(url);
} else {
yield db.updateURLError(url, response.error);
}
yield redis.incUrlPingCounterFor(url)
}
}
Но, это ещё ничего. последовательность разных асинхронных операций в golang превращается в водевиль с постоянной проверкой на err, это то, что есть с нодой если не использовать генераторы, asyncjs или промисы. Есть ли control flow и проброс ошибок наверх для го? try-catch? Я видел только panic
З.Ы.
Я бы написал эту функцию, как параллельно последовательно с минимальной задержкой отправляющую реквесты, и асинхронно их отлавливающую, чтобы не ждать пока пропингуется самый медленный сервер, в итоге время выполнения будет равно ± время самого медленного реквеста.
yield urls.map(function (url) {
return function *() {
var response = yield pingUrl(url);
//добро с записью в базу
}
})
На js этот код выглядит лучше чем го
async pingUrls(urls) {
for(let url of urls) {
let response;
try {
response = await pingUrl(url);
await db.updateUrlSuccess(url);
}
catch(err)
{
await db.updateURLError(url, response.error);
}
await redis.incUrlPingCounterFor(url)
}
}
ES7. Читим :)
Круто! Почти как в гоу. Осталось избавиться от async с await .
у гоу очень много недостатков, как статически типизированного языка без генериков или наследования при решении повседневных задач программиста высокоуровневого языка. не думаю что его стоит ставить в пример как удобная альтернатива куда более скриптовому и лаконичному js в своей нише. возможно веб-сервера на нем удобней делать, но common.js дает куда более широкое поле для действий. в остальном писать все эти гошные циклы, условное ветвление, кастование в прошлом — это неудобно читать, неудобно писать и этого кода чересчур много, именно поэтому сейчас все в большинстве делают по-другому.
в остальном писать все эти гошные циклы, условное ветвление, кастование в прошлом — это неудобно читать, неудобно писать и этого кода чересчур много, именно поэтому сейчас все в большинстве делают по-другому.
Хотелось бы взглянуть на пруфлинки с легко читаемым кодом для nodejs без циклов и условных ветвлений, которые «неудобно читать и неудбоно писать».
jsfiddle.net/odrdL6tg/1 допустим вот пример. в js это решается красиво благодаря слабой динамической типизации, удобным структурам. В большинстве высокоуровневых языков со статической типизацией есть генерики, итераторы, анонимные типы, которые избавляют от необходимости в циклах фильтровать, денормализировать, агрегировать обеспечивая при этом безопасность типов куда лучшую чем го, где нужно все кастовать, если хочешь написать нечто похожее на chainable библиотеку для работы с коллекциями.
Решает ли го такие задачи вообще? если да, то как эффективно это вы делаете с описанными выше ограничениями, мне самому интересно.
let col2 = _.chain(b)
.map((parent) => parent.nested)
.flatten().value();
let agg = _.chain(a)
.map((parent) => {
return {
name: parent.name,
aggregatedCount: _.reduce(parent.nested, (cumVal, nestObj) =>
cumVal + (_.some(col2, (nestControlVal) => nestControlVal.id === nestObj.id) ? nestObj.count : 0), 0)
};
}).value();
Если этот нечитаемый «смотрите как я могу» код для вас понятнее явных циклов с условиями, то с вами все ясно.
Кстати, ваш код будет тормозить при большом количестве элементов в nested списках из b. Объяснить, почему, или сами догадаетесь?
Вы лучше бы что-то написать сами попробовали на хваленом языке, вместо оптимизировать мое. В целом предсказуемо. Циклы быстрее делегатов, это последнее чем могу аргументировать люди, которые используют циклы в 2015 году вместо делегатов для логики. С другой стороны если язык не может предложить альтернативу циклам для бизнес логики из-за ограничений проектирования, то я бы хорошо подумал прежде чем его брать, даже учитывая всю заявленую быстроту.
Циклы быстрее делегатовТут дело не в циклах, а в незнании характеристик производительности базовых структур данных aka big O notation.
Дело в том что первичный мой вопрос был о семантике языка, а не о том что быстрее для коллекции b массив, или мап/сет. Это что слив такой неудачный?
Вне конкурса на «простоту», для любителей функционального стиля есть еще библиотека — rxjs.
В принципе, тоже довольно понятный код.
var pingServer = Rx.Observable.fromNodeCallback(pingUrl); //на случай если pingUrl написана в обычном для ноды стиле - с коллбеком.
function pingUrls(urls) {
var source = Rx.Observable.of(urls)
.every(function (url) {
return pingServer(url)
});
var subscription = source.subscribe(
function onNext(url) {
db.updateUrlSuccess(url);
redis.incUrlPingCounterFor(url);
},
function onError(err) {
db.updateURLError(err.url, err.reason);
redis.incUrlPingCounterFor(url)
},
function onCompleted() {
console.log('Completed');
});
}
Так же можно функцию redis.incUrlPingCounterFor(url) вынести в «every», если не важно будет она выполянтся перед запросами или после.
1.Способность держать овермного «сквозных» реквестов. В самом распространённом случае, сервак не ждёт, когда БД ответит, а обрабатывает ещё остальные реквесты, то же самое с I/O, сообщениями/реквестами, заливкой файлов на S3 и так далее и тому подобное (Вы скажете твистед и прочее event loop based, но совсем не торт, асинхронная модель пайтона и иже с ними до ноды не дотягивает)В дотнете с первой версии
2. Streams Streams Streams! Нет, серьёзно, это круто, как с точки зрения архитектуры, так и memory efficiencyВы про эти Streams? В дотнете с первой версии, правда в MS не было укуреных товарищей, догадавшихся смешать в одну кучу бинарные и текстовые стримы
3. Масштабируемость заложена в дизайне. Вы никогда не будете запускать 1 процесс ноды. 10, 20 (Наш потолок — 24 на одном сервере с 24 ядрами)— Давайте запилим платформу, которая крутится на одном потоке?
Серьезно, тот факт, что нода физически не может запустить больше 1 потока — это плюс?
Тогда стоит так же упомянуть, какой лимит памяти у одного процеса ноды и приподнести это как плюс. Вы никогда не будете запускать 1 процес ноды, потому что остальные 31 гигабайт оперативной памяти будут простаивать, верно?
5.Возможность писать изоморфные универсальные приложения, работающие на клиенте и на сервере, что абстрагирует фронтендщиков от бекенда — профит очевиден, бэки не занимаются ерундой и написанием темплейтов, и сконцентрированы на АПИКакой процент вашего javascript кода работает одновременно и в клиентской части приложения(в браузере) и в серверной (на сервере на бекенде)?
а с выходом ES6 и генераторов избавился от детских болячек с контролем асинхронности, так что сейчас как никогда приятно на нём писать
function GetUser(userID) {
__sync(function* (cb) {
var u = yield getUserFromMemcache(userID, cb);
if (!u) {
u = yield getUserFromDB(userID, cb);
} else {
yield logAccessToMongoDB(userID, cb);
}
return u;
});
}
Вы про это? Действительно, приятнее некуда.
Но есть и плюс, если человек пишет на ноде, то он в большинстве случаев знает, что он делаетРасскажите это в параллельном топике где консилиум Javascript Senior’ов не смог переписать 5 строчек кода на асинхронном javascript чтоб они делали то же самое, что делает синхронный код
Вы про эти Streams? В дотнете с первой версии, правда в MS не было укуреных товарищей, догадавшихся смешать в одну кучу бинарные и текстовые стримыobject streams и pipe не забываем, не забываем...
— Давайте запилим платформу, которая крутится на одном потоке?хм. Читаем дискуссию про потоки выше.
— А если люди спросят почему нет многопоточности?
— Скажем им, что масштабируемость заложена в дизайне
Серьезно, тот факт, что нода физически не может запустить больше 1 потока — это плюс?
__sync(function* (cb)это неправильный код
Какой процент вашего javascript кода работает одновременно и в клиентской части приложения(в браузере) и в серверной (на сервере на бекенде)?Всё, что касается серверного / клиентского рендеринга и получения данных от API. 90 %
Расскажите это в параллельном топике где консилиум Javascript Senior’ов не смог переписать 5 строчек кода на асинхронном javascript чтоб они делали то же самое, что делает синхронный кодГляну, может и у меня не получится. Можно ссылку?
object streams и pipe не забываем, не забываем...Опять таки, почему-то в MS додумались запилить отдельный нормальный фреймворк для обработки потоков данных и не смешивать его с низкоуровневыми бинарными потоками.
Я почему-то вообще не вижу проблемы.
Вы уже там договоритесь, однопоточна ли нода.
Расскажите это в параллельном топике где консилиум Javascript Senior’ов не смог переписать 5 строчек кода на асинхронном javascript чтоб они делали то же самое, что делает синхронный кодвообще-то вам написали, а вы куда-то пропали, и там была изначальная проблема в том что изначальная логика была мягко говоря странная
дайте линку
разгадка одна — компиляция бинарников. Надо и питон и node-gyp и компилятор православный(особенно на solaris), но раз заведёшь и всё работает
проблема чаще всего возникает в C++ компиляторах
итт диванные эксперты не знающие про основное преимущество ноды
Думаю багатьом цікаво які саме переваги. Багато дійсно не знають. Може розкриєте секрет?
секрета нет, только правильные запросы в гугл
Тобто:
1) або ви не можете назвати переваги
2) або не маєте бажання.
Якщо п.2, то дуже прошу все ж назвати їх, тоді, думаю, дана дискусія буде більше цікава, так як і друга сторона зможе аргументувати.
Прежнее название ноды, node.io, раскрывает основное преимущество — обработка ввода-вывода. То есть в то время, как остальные технологии множат треды для обработки I/O, гробя ресурсы, нода обрабатывает все в одном потоке очень эффективно. Причем некоторые считают «однопоточность» ноды основным недостатком. Как-то так.
в то время, как остальные технологии множат треды для обработки I/O, гробя ресурсы
I/O completion ports в Винде отменили?
Обычно кто так пишет тот как раз и не знает.
nodejs ще досить сира технологія і я не знайшов що в ній є таке, чтого не можна в php зробити. Паралельність: php thread, gearman. php-fpm static + opcache для того, щоб не тратити ресурси на запуск. Постійні процеси — php демон. А зручність написання zend розширень та php7, мені здається, роблять його поза конкуренцією.
Нода «однопоточна».
Постійні процеси — php демонКостыль. PHP это история не о демонах.
php thread, gearmanКостыль. PHP это история не о многопоточности.
php-fpm static + opcache для того, щоб не тратити ресурси на запускКостыль. Попытка загрузить Symfony/Zend/ваш любимый фреймворк быстрее чем за 5 секунд.
зручність написання zend розширень та php7Упаси Господь. Прийти в проект и увидеть там говнокод не только на PHP но еще и на Zephir/C или на чем там сейчас модно писать экстеншены это ужс.
Summary:
PHP безусловно неплохой язык для достаточно узкого круга задач, но надо адекватно воспринимать его нишевость и не пытаться прыгнуть выше головы там, где этого не стоит делать.
PHP безусловно неплохой язык для достаточно узкого круга задач,узкого?
Массовая ведь задача звучит так:
ответить на запрос веб-браузера информацией в обычно текстовом формате понятном браузеру по протоколу http
тогда получается все ЯП которые применяются в основном для этой задачи заслужили:
Х безусловно неплохой язык для достаточно узкого круга задач
Останутся кто, С, С++ для остального, широченного круга задач?
Костыль. Попытка загрузить Symfony/Zend/ваш любимый фреймворк быстрее чем за 5 секунд.то есть когда приложение, или ВМка висит в памяти всегда, это не костыль.
а что тогда не костыль?
про многопоточность в PHP — да. она там настолько левая, настолько вне истории и идеологии пыха, что меня всегда смущают те кто решили в проекте использовать что-то типа
php thread
то есть когда приложение, или ВМка висит в памяти всегда, это не костыль.Это вы уже додумали, т.к в моём комментрии ничего об этом не было.
а когда прикрутили opcache — то аяяй, костыль?А как это по вашему называется? Да, он даёт серьёзный прирост в перфомансе, но ведь по сути это костыль прикрученный для того, что бы совсем стыдно не было.
а что тогда не костыль?Всё не костыль, что не костыль. Конкретизируйте вопрос.
А как это по вашему называется?обычным инженерным подходом под общим названием — кеширование промежуточных результатов работы, для их использования в следующий раз, если их вычисление значительно дороже их хранения и получения.
Всё не костыль, что не костыль.понятно. вопросы к вам снимаются.
Демоны на пхп не очень-то умеют жить сами, для контроля за ними приходится настраивать например supervisord. А это уже не полноценные демоны. Хотя такие «демоны» имеют несомненный плюс — могут являться частью самого веб-приложения, и работать на одном с ним фреймворке.
Упоротые Гоферы в теме замечены были, а вот упоротые эрлангисты — нет. Куда катиться мир :-(
Хех=) Ну и опять пхпшники, с которых 95% думают «я знаю джабу скрипт- да все знают его, все же кнопочки на JQ клеили», будут примерять архитектурные паттерны и иные идеологии LAMP на node.js и рассуждать о ее перспективности и «ущербности» JS как такового- начиная с того что там не 100500 функций ядра на каждый чих.
Node.js просто другой, другой язык, другая идеология, другая архитектура и спроектирован не с целью выплевывать куски html в клиент, как php и его братья. Все эти споры не имеют смысла, без опыта в обеих средах и решения практических задач кроме как вывода hello world.
Ну а те разрабы, которые кроме технологии X вообщем то ничего не знают, тяжко переходят между языками, просто войдут в стадию отрицания того, что возможно язык/технология Y лучше подходит, отсюда генерится большое количество Г. на вентилятор.
Действительно, стандартные решения, там где нужно отдавать готовую страницу на клиент на php заметно проще и дешевле, но с этим же и node справляется, но прицел там на отдачу чистых данных и оперированием большим количеством мелких запросов.
Если разраб не может разбить задачу и выстроить правильную архитектуру под конкретную технологию, в силу недостаточного понимания, это проблемы разраба, а не технологии.
Nodejs — тупиковая ветвь эволюции. Будущее за go. Если не согласны, ждем обоснованных возражений тут — dou.ua/forums/topic/16012 .
Пора уже новый мэм заводить
— Тут кто-то программирует на nodejs? Вопрос есть.
— Я гошник!
Это суровая правда жизни
Основное преимущество node.js в том, что благодаря использованию единого языка «javascript» можно с меньшими усилиями front-end deva научить писать || поддерживать back-end. А javascript в web знают практически все и используют его если ни как основной язык, то как вспомогательный точно.
Начну из далека, бизнес требования к UI части сильно возросли, что повлекло многократное увеличения объема javascript кода. А такой большой объем кода на мобильных девайсах может парситься до
В прошлом была создана спецификация asm.js и написан под нее Emscripten компилятор, который генерил особенный javascript код(правда не читабельный), что VM на его основе могла создавать более оптимизированный машинный код, чем если это был обычный человеко-написанный javascript код. Но asm.js не решала проблему парсинга, т.к это оставался все тот же javascript код в текстовом представлении.
Предвидя будущее, 4 гиганта мировой IT индустрии Google, Microsoft, Mozilla, Apple и другие объединили усилия и создали стандарт называемый WebAssembly который решает обе проблемы. Проблему парсинга они решили с помощью компиляции исходного кода в AST(abstract syntax trees) в бинарном представлении. Это позволяет ускорить парсинг более чем в 20 раз по сравнению с обычным текстовым javascript файлом. hacks.mozilla.org/...webassembly-its-happening.
Код из WebAssembly может вызвать любой код написанный на javascript, любое api из окружения и в противоположную сторону так же можно будет вызывать код написанный в WebAssembly из plain javascript файла.
Благодаря тому что все поставщики современных браузеров вовлечены в разработку и реализацию нового стандарта, затею можно заранее считать успешной.
Не смотря на то что в описании сказано большими буквами «WebAssembly doesn’t replace JavaScript», они будут сосуществовать вместе, жить долго и счастливо, но ЭТОГО не будет. Не потому что кому то язык не нравится (хотя я очень люблю javascript, но еще больше я люблю C#) , а потому что тот формат в котором выполняется javascript файл -> байткод -> машинный код уже не удовлетворяет современным требованиям к быстрой загрузке(парсинге) и быстром выполнении. О каком сосуществовании идет речь? То что они дают эту возможность не означает что ею будут пользоваться, если будут то опять вернутся к старым проблемам.
Это все конечно мое личное мнение но со смертью javascript на front-end умрет и node.js.
А можно про WebAssembly на пальцах рассказать? Вроде понятно, что главная идея — ускорить исполнение js на фронтенде. Но как это выглядит со стороны разработчика? Нужно будет писать фронтенд на С/С++ вместо JS, чтоб потом скомпилить в WebAssembly? o_0
Главные идеи — портировать уже написанный код в веб, а также поддерживать разработку на других языках без ущерба производительности. То есть не хотящие переучиваться на javascript потенциально смогут писать и для фронтенда. Возможно, десктопные окружения смогут запускаться в браузере.
На мой взгляд, это больше технология для конвертации допотопного софта в веб и смерти js не предвидится.
лучше бы JS помер много лет назад, уже лет 15 пытаются натянуть сову на глобус. что только не придумывают чтобы из этого говна мамонта, что-то современное сделать.
не переживайте вы может когда-то разберетесь в программировании
что-то современное сделатьсовременность чем определяется?
Мне не очень понятно, почему Node.js сравнивают именно с PHP. Node.js — отличное подспорье для фронт-энда (npm, сборка модулей, дев сервера для одностраничных приложений аля webpack-dev-server), на бэкенде он небходим в основном для pub/sub решений и активной работы с файлами, в большинстве остальных случаев это решение на «поиграться». Очевидно, что у ноды есть будущее, но я это не универсальное go-to решение для сервера. Даже если вы разрабатываете SPA на каком-то ангуляре или реакте, относительно хорошо знаете джаваскрипт, часто API будет проще и лучше сделать на PHP, чтоб не переживать о вещах, которые не имеют непосредственного отношения к решению поставленной задачи (привет однопоточности ноды). Это, впрочем, мнение не подкрепленное каким-либо серьезным опытом, но у адвокатов ноды на бэкенде, как правило, такие же глубокие познания в других технологиях и не считая идеи изоморфного приложения их аргументы звучат не очень убедительно.
ниже писал, нода очень удобно если ваше приложение идеально описывается событийной моделью, к примеру та же робототехника — там сплошные события, и нода как раз там норм.
но в обычной веб разработке это редкость. в основном это больше пайп — запрос принял, сделал пару запросов в БД как то это смерджил отдал обратно — нода тут оверхед
Привет считающим однопоточность ноды недостатком.
Речь не о том, недостаток это или нет, а о том, что для большинства задач это не нужно, что это увеличивает затраты без видимых преимуществ для решения поставленной проблемы. Я не имею ничего против Node.js, просто не надо промывать мозги начинающим веб-разработчикам, рассказывая на каждом углу, что это будущий мейнстрим на бэкенде — вот вся мораль комментария выше.
Как раз-таки затраты увеличивает многопоточность. Или это про то, что пэхэпэшники просят меньше денег?
Какие затраты увеличивает многопоточность?
программисты которые знаю что это такое — просят больше денег ?
Затраты мозга, например. В ноде в большинстве случаев об этом не нужно думать.
В Hello World бэнчмарке возможно, в остальных сценариях это все наверняка очень условно и зависит от задачи. И да, если вы не Facebook, то ваше время дороже железа.
Вы поосторожнее с этим вашим Ноде.ДжС, так и до кинокарьеры можно дойти, по российскому образцу: twitter.com/...status/669834299688902656 :)
теперь я видел все...
может, там наоборот было: девелоперу наскучили сыры, захотелось разнообразия.
пет-проджект, так сказать.
Насыщенная и разнообразная жизнь, однако)
имхо подобные вещи для извращенцев. Нода имеет свою узкую нищу где она эфективна — в сервисах где нужно отправлять много мелких сообщений ьтипа соцсетей . но таких сайтов не много.
Просто разработчики ищут как обычно, волшебную пилюлю, панацею, которая поможет парой строк кода решать все проблемы и быстро разрабатывать приложения. Но в большинстве случаев получается больше гемора чем пользы. То же касается ангуляров и прочих клиентских фреймворков.
Это просто мода (или как щас говорят- тренд). не первая и не последняя — завтра придумают еще что то.
Нода имеет свою узкую ищу где она эфективна — в сервисах где нужно отправлять много мелких сообщений ьтипа соцсетей . но таких сайтов не много.Есть еще одна ниша:
не, нишу ПХП ДжС не перекроет — ДжС сильно сложен для многих в отличие от ПХП
скорее, сложна внезапная концепция глобальной однопоточности, что ставит высокие требования как в девелоперам, так и админам всего этого зоопарка.
касательно сложности языка: джаваскрипт все так же реализует миксины через банальное копирование, тогда как в PHP есть trait’ы.
ну, и traversable появился сильно раньше, пока мы тут дожидались поддержки генераторов и for ... in
UPD хаха, я понял, это все не всерьез :) отличный ход!
чушь, как раз PHP тут справляется намного проще. Не говоря о том что PHP по дефолту стоит на любом хостинге.
Привет из 2016, хостинг мертв. PaaS и IaaS наше все.
Для одностраничников, небольших сайтов-визиток и скромных интернет-магазинов — живее всех живых. И там PHP будет царствовать еще очень долго.
и скромных интернет-магазинов — живее всех живых.Magento — да, для очень скромных trends.builtwith.com/shop
Речь-то изначально шла про хостинг. Серьезные магазины вряд ли размещают на дешёвом shared hosting’е.
Речь-то изначально шла про хостинг.если некий инструмент позволяет с сопоставимыми затратами писать и для шаред хостинга, и для неешаред, то это очень полезный, толковый инструмент. и будет применяться широко.
по той ссылке тренды в екоммерсе
первое место Magento
второе WP+Woocommerce
Magento да, даже и пробовать не стоит на шареде поднимать.
Woocommerce — отлично там живет
и обе самые популярные e-commerce платформы — разработаны на php
а уж других, а уж лисапетов...
Из чего делается вывод что пых умирает, что на нем скорость разработки низкая, что он для очень узких задач, ...
как обычно меня интересуют не сами технологии :)
а вавы в голове ит-комьюнити.
на примере суждений о пыхе — они ну очень наглядны :)
PHP по дефолту стоит на любом хостингеМмм... хостинг... А какой версии стоит пхп на любом хостинге? А с какими дополнениями скомпилирован? А ssh, git на любом хостинге стоят?
7ой пых, SSH, git уже обычное дело. Не на любом конечно, но выбор среди хостеров с такими сервисами уже большой.
Вот чего пока не встречал массово, так это опкэш, acpu или мемкэш и php-fpm с nginx
Собственно ради этого и берут вирт сервера для проектов на php.
Не очень понимаю почему хостеры не предлагают такие плюшки. Вышло бы дешевле чем вирт сервер, и дороже чем шаред без этого. При меньшем «расходе» аппаратных средств чем у вирт сервера для хостера
из разряда красивых свистелок-перделок современных технологий, как только начинается настоящая нагрузка — заканчивается нода полностью
Очень спорно.
Вопрос правильной архитектуры.
Архитектура это конечно важно, но чисто физически нода не способна переварить столько же, сколько переварит сишный сервер с идентичным железом. Да, можно масштабироваться покупая новые и новые серверы, но это далеко не оптимальный путь ИМХО.
А зачем использовать железные сервера для ноды?
Оптимально сделать виртуалок по кол-ву физических ядер и перед ними балансер.
Вы так же оставляеие за скобками скорость разработки, внесения изменений, тестирования для сишного кода и для нодовских атомарных приложений. ( ведь нода как раз для них и рулит)
Железные сервера в любом случае используются, хоть там одна ось, хоть 100500 виртуалок, дело не в этом, а в том, что годится нода для мелочи всякой, а преподносится как затычка для решения любых вопросов и ведутся люди, пытаясь серверы на ноде в хайлоад проектах писать и наступают на эти грабли уже который год.
В хайлоаде все замечательно.
Вопрос архитектуры и пряморукости.
Пока вы будете писать правильное многопоточной приложение на сях — нодовский сервис зарелизится и снимет сливки с рынка.
Ещё раз говорю — нода для атомарок а не для монолитных больших приложений.
Т.е. функционал приложения разносится на микросервисы работающие через апи между собой. Так и масштабировать проще и боттлнеки искать.
я понял вашу позицию) что ж, херак херак и в продакшен тоже имеет право на жизнь
Вы как-то странно реагируете на фразу
снимет сливки с рынка
сишный сервер? Это вы имеете в виду писать server side на С? Good luck.
Я так понимаю, если в исходной фразе заменить С на Го, можна даблзрачик в теме поиметь.
А вы часто встречаете сервера написанные на си?
Можете привести пример? Не стеба ради — действительно интересно.
Если что, да, мне лень гуглить, поому что сомневаюсь, что нагуглю то, что надо.
Не, так не интересно)
Я надеюсь на серваки, аналогичные пыховым/рельсовым/нодовским.
Это не сервера. Сервера только на С :)
Т.е. в «Клиент — Сервер» сервер тоже только на С? :)
Все на только на C. Иначе не комильфо. :)
Там все равно модуль интерпретатора. Ноду не используют для сервинга статических ассетов
У вк вроде самописный сервер на си или плюсах.
у вк PHP — github.com/vk-com/kphp-kdb
vk.com/jobs?w=job45
Ну где-то у них да используется, дуров еще на стенке писал пост мол требуются С девы для написания компонентов.
жизнь короткакак и ассемблерные команды :)
вы много кода для работы с сетью на асме написали?
Ні, мене просто цікавлять причини вашого вибору. Чому C, а не asm?
ТА ЛАДНО? А я думав, один і той самий. Вагомий аргумент.
при желании/необходимости C код легко смешивается с ассемблерным. Но где это надо помимо совсем жесткого embedded, непонятно.
asm {
....
}
Давно отменили? Или линковку объектных файлов?
Сарказм пошел в странную сторону.
А серверсайда на C/C++ в научной и финансовой среде таки хватает.
Я не говорив, що його немає. Я веду лише до того, що є таки вагомі причини, чому для серверсайду частіше обирають більш високорівневі мови. І причини вибору між C та Node.js приблизно такі ж, як між Asm та C.
Технология будет развиваться- если за её спиной есть поддерка со стороны больших корпораций.
habrahabr.ru/company/ibm/blog/266647
Как по мне, будущее node.js уже давно наступило :)
Т.е о node.js можно забыть ? :)
видимо, зря я взял в кавычки будущее :) нет, имелось в виду, что вопрос был актуален в прошлом, когда будущее еще наступало. и node.js сейчас не новинка и давно используется в разработке сетевых решений (разного уровня)
Ну, еще интересно мнение о перспективах роста node.js )
www.tiobe.com/...paperinfo/tpci/index.html — а вот и ответ.
Чудова точність і використовується усюди.
В Україні майже нема ембеддед. А це основний consumer с прогерів. І відповідно Ваш висновок є хибним.
Погугліть, де використовується С, і тоді зрозумієте, чому так мало вакансій в Україні.
Ембедед — це не фронтенд. Там розробнику потрібно мати доступ до девайса. Тобто, розробник має знаходитися в R&D центрі, а їх в Україні обмаль. Та про що ми говоримо, взагалі? Просто подивіться на розмір цього сектору в Україні.
Когда приводите «статистику», используйте нормальную выборку, а не Украину. Учтите, что Украина — это аутсорс.
Короче говоря, почувствуйте разницу:
us.jooble.org/jobs-c-developer
us.jooble.org/...jobs-javascript-developer
Окей, отбросьте процентов 10 из выдачи, но вы все-равно получите нормальные цифры.
Вы не придирайтесь к погрешностям, а поймите, что приводить «доводы» основываясь на украинском рынке — это неверно.
Смешно от вас это слышать :)
Если вы считаете, что на C/C++ не ведется разработка — вы не правы.
Если вы считаете, что в Украине 35 вакансий и это показатель — вы не правы.
У вас есть что ответить?
Окей, отбросьте процентов 10 из выдачи,мне показалось там еще процентов 40 про дотнет тащемта.
На самом деле даже больше. Поиск там не очень... Для меня это не было очевидно (я основывался на первых
В общем, если поиграться с поиском, сделать некоторые слова обязательными, а остальные убрать, то по С количество результатов снижается до 15к (us.jooble.org/...- objective c- c#- nurse. Уверен, что можно урезать еще пару тысяч, а может и больше.
Кроме того, никто не усомнился в результатах по яваскрипту. Достаточно просто убрать слово «developer», которое и портит всю картину, и полусим всего 16к (us.jooble.org/jobs-javascript, в которых тоже, хоть и гораздо реже, встречаются левые работы.
Если предположить, что еще процентов 30 от в выдаче для C — это неподходящие работы — получим 10522 результатов.
Для яваскрипта — 16882 результатов.
В таком случае, видим, что отношение предложений на С к яваскрипту — 0,62
По украинскому рынку (на основе данных Константина) — 0.07
Короче говоря, да, с первыми результатами я облажался, т.к. в обе выборки попали ненужные работы. Но, в любом случае, нельзя приводить цифры для украинского рынка как аргумент использования языка.
Так ви зможете тепер вимовити в слух, що таки індекс TIOBE — не показник, коли треба проглянути перспективу мови програмування?Да, я согласен, что TIOBE не показатель. Мне интереснее было увидеть/показать, что данные по одной стране не могут отражать картину целиком. Все-таки, разница между Украиной и США получилась довольно большая. Может быть, в каком-то другом случае и не прокатило бы :)
Вообще, для меня более авторитетна статистика со стека (stackoverflow.com/...ch/developer-survey-2015. Хотя и она какая-то странная — яваскрипт три года подряд самый популярный... Но, во всяком случае, данные стека основаны не на поисковых запросах, а на собственной базе.
Можете еще тут глянуть githut.info
Все верно, я только еще позанудствую, сказав, что вы еще и С++ гдето потеряли ;-)
И поскольку в индексе TIOBE С и С++ разные вещи — результат странный получаеться.
JavaScript перспективен как серверный язык программированияНіяк. Їхнє хіпстерство та хаос з версіями пакетів зводить все нанівець. Тільки монополія в браузерах тримає це лайно на плаву.
Можете уточнить, что Вы имеете ввиду под «хаосом с версиями пакетов»?
после обновления ноды обычна какая-то зависимость отваливается
и часто Вы меняете версию рантайма для конкретного проекта? (не для нового, а для существующего). в моей практике не было причин менять версию рантайма для существующих (при этом активно развивающихся) проектов
Решение — не изменяйте рантайм на текущем проекте.
P.S.: т.е. изменение рантайма на любой другой платформе проходит гладко?
просто для баланса. заранее согласен, что это не показатель.
stackoverflow.com/...-but-not-in-java-1-7?rq=1
вылезло на реальном проекте.
там еще при апдейте на минорную часть версии вылезло. не в курсе, сколько убили на разбирательство, но точно больше дня.
PS аааа, да, речь-то про рантайм. тогда тем более не в тему.
жаль, сообщения не удаляются.
Ну крайние случаи есть везде. Но с нодой это не сравнить =).
с рантаймом могут тоже вылезти проблемы. Когдато вылезло что после обновления минорной версии ждк, приложения в некоторых местах стало отваливаться. Из за легаси кода, который юзал какуюто хитрость в кривом стандартном апи, и это апи «починили» в новой версии.
Но вообще апгрейдить рантайм безрег регрешн теста — себя не уважать, хотя конечно не знаю как там у нодеров заведено...
Нет, не особенная. Вы видимо никогда не обновляли версии библиотек в жаве и не пробовали перенести проект на сервер приложений с другой версией
Не, ни разу не делал подобного... Вот и не знаю, что там с явой :(
Ну, у меня изредка были проблемы с гемами. Кроме того, обновление некоторых гемов приводило к тому, что отпадала половина функционала (devise, cancan, paperclip).
Или у меня руки кривые :)
nvm? нет, не слышал. тоже самое можно сказать про питон, жаву и руби.
Такое можно сказать о любой технологии
Я би сказав навпаки, дуже зручно, завантажив пакет, практично весь функціонал в руках, бери користуйся, функціональний сайт можна створити за пару годин
Юрий Левин
Gennady Dogaev
Sergii Vashchyshchuk
Dmytro Yeremieiev
Bogdan Shyiak
Леонид Мартынюк
Леонид Мартынюк
Конь в Пальто
Iurii Besedin
Vladyslav Melnyk
Gremlin
Constantin Titarenko
double
Найкращі коментарі пропустити