IO.js или старые грабли под новым соусом



    «Свершилось! Node.js получило развитие в виде форка io.js! Привет ES6! Привет новый V8!» радовались разработчики. Полез смотреть с надеждой, что вот сейчас, начав с нуля, ребята исправили фундаментальные косяки!

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

    Обратная совместимость


    Нет, речь не о совместимостью с node.js, а речь об отсутствии гарантий, что после «очередного» обновления ядра движка, не отвалится что-то. Такую гарантию даёт JAVA, пускай множество методов считается deprecated и компилятор того гляди начнёт ругаться матом, тем не менее код, написанный на 2-ой яве работает и в 7-ой, и в 8-ой, и мы знаем, что будет работать в дальнейшем. Или, возможен путь C++ и GCC: компиляция с указанием на какой стандарт опираться. Так же отчасти гарантии отсутствуют на уровне документации (см. ниже)
    Многие проекты теряли популярность и «горели» именно из-за потери обратной совместимости. Некоторые на её наличии «выехали».
    Это критично для развивающейся платформы, движка.

    Компилируемые модули


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

    Документация


    Доки сильно улучшили, но местами всё равно дыры (ФС, Zlib, ...). Перечисление методов и функциональности это не документация, а, скорее, её черновик.
    Аргументы, их типы, аргументы и типы возвращаемые в коллбэкфункции, фатальные ошибки, которые «выкинут» ещё до вызова callback это уже документация. Думаю Гуру могут дополнить этот список.
    Особое внимание стоит уделить тому, что отсутствие документации говорит о неуверенности авторов и разработчиков движка в том, что всё так и останется. А значит нет никаких гарантий, что это не изменится, типы и порядок аргументов не поменяют и т.д.
    Критично для проекта, который используют много разработчиков, где нет времени проверять поведение, особенно в исключительных случаях (зависание сокета, открытие сетевого файла, др.)

    Unstable методы и модули


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

    Вывод


    Если нужно склепать сайт-визитку, маленький инет-магазин, чатик или форум, то не понятно, чего не хватает в Node.js. Для USS Enterprise же не годятся оба движка по хорошему счёту. О плюсах IO.js уже писали и, даже, совсем недавно о развитии движка и их, бесспорно, стоит принять во внимание.
    Учитывая, что движок развивается, активно принимает предложения, я надеюсь что сообщество поможет укрепить IOjs.
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 29
    • +13
      речь об отсутствии гарантий, что после «очередного» обновления ядра движка, не отвалится что-то

      Ага, а потом впиливать костыли для костылей для обратной совместимости, чтобы не дай Кнут не отвалилось бы ничего у 0.5% юзеров, которые до сих пор пишут под версию 0.6. Нет, вот как раз развивающемуся движку такого не надо.
      • +1
        Да, конечно, нельзя ориентироваться на слоупоков, но платформам, имеющим в базовой поставке менеджер пакетов, просто необходима обратная совместимость.

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

        В случае отсутствия обратной совместимости любая установка любого пакета превращается в лотерею (см composer + PHP — там подобное цветет и пахнет)

        Кроме того, полностью отказаться от обратной совместимости тоже нельзя — иначе придется поддерживать большой набор старья (опять же, см пхп 5.3)

        Мне нравится как реализована обратная совместимость в яве — методв не удаляются, а помечаются как deprecated, что позволяет запускать старый код на новых VM, но при этом не писать новые проекты с устаревшей функциональностью.
        • –2
          Обратная совместимость — это не только старые методы, а еще и старое поведение тех же самых методов. Помнится, с виндой была интересная история, что в 2k пришлось эмулировать какие-то баги из 9x (вроде бы из-за SimCity, ЕМНИП). А если всегда создавать только новые методы, которые «ну в этом-то релизе точно работают правильно и как надо», то для них скоро кончатся вменяемые имена.
          • +1
            Java как-то справилась с этим. А винда в принципе не пытается даже справляться, её задача обратная (в данном аспекте): чтобы обновлялись.
            • +1
              Я впервые услышал об этом от одного из разработчиков популярной игры SimCity, который поведал мне о критической ошибке в их программе: она использовала память сразу после ее освобождения. Главное табу, нарушение которого прощалось в DOS, но карается в Windows, где освобожденную память тут же стащит другое работающее приложение. Тестеры в команде разработки Windows протестировали множество популярных приложений, чтобы убедиться, что все работает без сбоев, но SymCity зависала. Они сообщили это разработчикам Windows, которые дизассемблировали SymCity, шаг за шагом в дебаггере найдя ошибку, и добавили специальный код, проверяющий наличие SymCity в памяти и запускающий распределитель памяти в специальном режиме, в котором SymCity разрешается использовать память после ее освобождения.

              russian.joelonsoftware.com/Articles/HowMicrosoftLosttheWaronA.html
        • –2
          Ну так это три главных признака типичного OpenSource-проекта — отсутствие вертикальной совместимости, отсутствие внятной и актуальной документации и проблемы с юзабилити из-за отсутствия понимания, для кого вообще создаётся данный продукт.
          • 0
            Just for fun
            • +1
              не вяжется с промышленным использользованием
              • 0
                да, и не должно вязаться, для продакшена есть нода
                • +2
                  В том-то и дело, что тоже не годится, а т.к. судя по всему она под гуглом ходит, то она встала намертво: гугл будет продвигать Го и банить ноду. Но если до ноды достучаться сложнее, чем до Чака Норриса, то вот развивающемуся проекту можно придать основательность =)
                  • +2
                    Всякий этих Го уже есть и будет еще много разных, тут ведь дело в том что нода это JS код, низкий порог вхождения, много школоты разработчиков.
                    • +1
                      При чём тут это? Я про ступор ноды, показательное нежелание развиваться.
                      Ну да, порог не высок, только вот IO и Node этим страдают в равной мере. Хотя если IO сделает доверенные пакеты, она и тут может приподняться)
                      Молодые проекты не надо толкать, зачастую, но стоит показать где грабли и почему не стоит на них наступать. Отсюда и название статьи) IO как раз такой. И пока он молод, он может стать основательным. А найдите мне программиста (не Python) который не ценит основательность =)
                      • 0
                        При чём тут это? Я про ступор ноды, показательное нежелание развиваться.

                        А я про Го уже, какойто там айо теперь уже раз вы упомянули сам Го продвигаемый гуглом.

                        Я не всегда ценю «основательность», допустим после java мне как релакс работать с js и нодой.
          • 0
            Все верно, проект ведь решили форкнуть гики для фана. В итоге нода будет для продакшена, айо — для хипстеров (если вообще будет). Оно ведь так часто бывает, если за опенсорсным проектом не стоит какая-либо компания (финансирование), то в продакшене использовать эти хоть и модные поделки боязно.

            А для ноды возможно это и не плохо. Это как аналогия комьюнити лицензии и коммерческой. Айо обкатывает технологии, нода проверенное по-немногу внедряет.
            • +1
              Ну вообще то, ноду форкунили не «гики для фана», а большая часть разработчиков самой ноды, так как их перестала устраивать политика проекта.
            • +5
              > Обратная совместимость
              Вы слышали о semver? Мажорное обновление на то и есть, чтобы заявить о том, что могут быть несовместимости с предыдущими версиями.

              > Компилируемые модули
              Согласен в плане сборки. Может меняться API V8, но это не проблема iojs. Вполне можно использовать nan для абстракции. Библиотека npm большая, для большинства задач есть альтернативы на js.

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

              Ещё одна статья-страшилка, наподобие той про ангуляр. Всё не так плохо.
              • 0
                Ещё одна статья-страшилка, наподобие той про ангуляр. Всё не так плохо.

                Да не плохо, если осмысленно подходить к выбору тулзов для продакшена.
                • +1
                  Под другим названием, но слышал. Обратная совместимость не обязательно нужна java-подобная (хотя это очень полезно). Окей, выпустили новый движок — дайте флаг запуска в режиме совместимости (как делает GCC, можно компилировать в режиме совместимости с более старой версией С++).
                  Почему обратная совместимость так важна: не редко, уйдя далеко вперёд во времени, движок круто эволюционирует. И без неё не запустится хорошо отлаженный скрипт, интерфейс или программа. Кто-то зелёный скажет: «да соберите вы старую версию, если она так нужна!» И библиотеки к ней, и компилятор, и вообще почти всю ОС под chroot-ом. Ради того, чтобы запустить старый отлаженный и рабочий скрипт.

                  Разве nan не должны использовать сами разработчики модуля на С++? Как это решает проблему вин/амд/арм гарантий сборки в целом?

                  При чём тут «я тестирую»? Необходимо понимать как работает тот или иной вызов ещё до написания кода. Зияют дыры в FS, Zlb, хотя в целом причесали.

                  Это призыв о помощи, т.к. круг программистов не так велик. А не страшилка =) Не плохо, но хуже от фундаментального превосходства над нодой не будет)
                • 0
                  а речь об отсутствии гарантий, что после «очередного» обновления ядра движка, не отвалится что-то

                  За гарантиями в проект v8. Думаете, он рискнет обновиться так что что-нибудь отвалится?
                  Я лично очень в этом сомневаюсь
                  io.js — это же по сути «обвес».
                  • +1
                    Как вы выразились «обвес» может, например, «сказать», а что-то нам идея ошибки первым аргументом не по вкусу стала, теперь первый арг — дата, а ошибка в общем потоке ошибок. Ну например. Так что не к v8, а именно к IO
                  • +2
                    Node и io.js для каждого модуля указывают что с API. Есть и frozen модули, вроде util, а есть и experimental, вроде smalloc. Если модуль будет deprecated — он так и пометится.
                    На счет компилируемых модулей — код платформозависим до той степени, до которой его довел разработчик этого модуля. На сколько я знаю все, что в io.js — не платформозависимо и поддерживаются все основные платформы и архитектуры.
                    • 0
                      Немного о статусах модулей
                      На счёт статуса модуля: это хорошо, на них можно уже опираться в продакшене, точнее на всё серьёзнее stable. Хотелось бы чтобы все базовые модули API довели до stable. Многовато unstable+experimental. Даже «просто при работой с ФС» утрированно и обывательски говоря =)

                      Проблема, что судьба deprecated не известна. Осуждаемые (но исполняемые всё-таки) или не поддерживаемые. И в этом суть проблемы.
                      Проблема в компилируемых модулях, что я не всегда предупреждён, что собираю проект с оным. Иных фундаментальных трудностей с ними нет)
                      • 0
                        Ноду не развивали долгое время, собственно от чего и родился форк. Теперь команда подготовила первый релиз, обновила зависимости. Подождите чу-чуть и будут модули доводиться до stable/frozen статуса.
                        Для сравнения в c++ до сих пор в стандартной библиотеке нет работы с файловой системой
                        • 0
                          Ждать можно по-разному. Отсюда и применил теорию 6-ти рукопожатий, попросив Хабр помочь донести данную критику до разработчиков =) Меня в своё время очень разочаровала нода, которая развивалась-развивалась, а такие ключевые детали так и остались граблями.

                          Поэтому IO — надежда. И пока он молод, в него можно заложить основы. Куй железо, пока горячо, правильно ведь?)

                          Нету, увы. В С++ обратная совместимость стандартов тоже отсутствует. Но gcc творит чудеса =)
                          BOOST
                          Хотя это хорошо реализуется стабильным и прекрасным бустом. Возможно я слишком мало его использовал, что так пишу. Я не против такой же стабильной библиотеки извне. Если, грубо говоря, можно будет не заботится вообще о stable/deprecated внутри платформы, а интерфейс всё свяжет сам, то круто. Это скорее инструмент, чем сам движок.
                          • +1
                            На мой взгляд правильно было бы конкретно сформировать ваши пожелания и написать в issue tracker. github.com/iojs/io.js/pulse — issues не остаютя без внимания, не смотря на напор.
                            • 0
                              Да, это правильно… Но я с английским, как с искусством шпагоглатания) Смертельно никак.

                              А ОбрСов уже можно строить, API уже не так молодо и многое отбросило. Если надо что-то внедрить и пощупать на масстестах — beta, флаги запуска и/или компиляции (вроде --experemental-methods) и т.д. в помощь.
                            • +1
                              И по поводу обратной совместимости стандартов — на мой взгляд совсем не весело тянуть за собой обратную совместимость в мажорных версиях. Что если вы сделали в языке/библиотеке что-то не так? Функция называется parse_str, а на деле это parse_url.
                      • 0
                        Хабраюзеры, я ни много ни мало удивлён! 50/50 практически людей, которые за улучшение IO в данных местах и против них. Хотя, может, последних задела критика IO =) Или ноды (всё-таки в статье о проблемах унаследованных от ноды).

                        Люди, которые считают это всё это второстепенными проблемами или не проблемами, отзовитесь, скажите плиз, а зачем Вам тогда вообще IO? =)
                        • 0
                          Нужен, пускай пилят, но не для продакшена, можно считать это nightly node.

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