Comments 29
речь об отсутствии гарантий, что после «очередного» обновления ядра движка, не отвалится что-то
Ага, а потом впиливать костыли для костылей для обратной совместимости, чтобы не дай Кнут не отвалилось бы ничего у 0.5% юзеров, которые до сих пор пишут под версию 0.6. Нет, вот как раз развивающемуся движку такого не надо.
Да, конечно, нельзя ориентироваться на слоупоков, но платформам, имеющим в базовой поставке менеджер пакетов, просто необходима обратная совместимость.
Многие npm пакеты не обновляются годами, но при этом вполне рабочие, и сейчас я уверен, что пакет, написанный под в 2013 без проблем заработает у меня в проекте.
В случае отсутствия обратной совместимости любая установка любого пакета превращается в лотерею (см composer + PHP — там подобное цветет и пахнет)
Кроме того, полностью отказаться от обратной совместимости тоже нельзя — иначе придется поддерживать большой набор старья (опять же, см пхп 5.3)
Мне нравится как реализована обратная совместимость в яве — методв не удаляются, а помечаются как deprecated, что позволяет запускать старый код на новых VM, но при этом не писать новые проекты с устаревшей функциональностью.
Многие npm пакеты не обновляются годами, но при этом вполне рабочие, и сейчас я уверен, что пакет, написанный под в 2013 без проблем заработает у меня в проекте.
В случае отсутствия обратной совместимости любая установка любого пакета превращается в лотерею (см composer + PHP — там подобное цветет и пахнет)
Кроме того, полностью отказаться от обратной совместимости тоже нельзя — иначе придется поддерживать большой набор старья (опять же, см пхп 5.3)
Мне нравится как реализована обратная совместимость в яве — методв не удаляются, а помечаются как deprecated, что позволяет запускать старый код на новых VM, но при этом не писать новые проекты с устаревшей функциональностью.
Обратная совместимость — это не только старые методы, а еще и старое поведение тех же самых методов. Помнится, с виндой была интересная история, что в 2k пришлось эмулировать какие-то баги из 9x (вроде бы из-за SimCity, ЕМНИП). А если всегда создавать только новые методы, которые «ну в этом-то релизе точно работают правильно и как надо», то для них скоро кончатся вменяемые имена.
Java как-то справилась с этим. А винда в принципе не пытается даже справляться, её задача обратная (в данном аспекте): чтобы обновлялись.
Я впервые услышал об этом от одного из разработчиков популярной игры SimCity, который поведал мне о критической ошибке в их программе: она использовала память сразу после ее освобождения. Главное табу, нарушение которого прощалось в DOS, но карается в Windows, где освобожденную память тут же стащит другое работающее приложение. Тестеры в команде разработки Windows протестировали множество популярных приложений, чтобы убедиться, что все работает без сбоев, но SymCity зависала. Они сообщили это разработчикам Windows, которые дизассемблировали SymCity, шаг за шагом в дебаггере найдя ошибку, и добавили специальный код, проверяющий наличие SymCity в памяти и запускающий распределитель памяти в специальном режиме, в котором SymCity разрешается использовать память после ее освобождения.
russian.joelonsoftware.com/Articles/HowMicrosoftLosttheWaronA.html
Ну так это три главных признака типичного OpenSource-проекта — отсутствие вертикальной совместимости, отсутствие внятной и актуальной документации и проблемы с юзабилити из-за отсутствия понимания, для кого вообще создаётся данный продукт.
Just for fun
не вяжется с промышленным использользованием
да, и не должно вязаться, для продакшена есть нода
В том-то и дело, что тоже не годится, а т.к. судя по всему она под гуглом ходит, то она встала намертво: гугл будет продвигать Го и банить ноду. Но если до ноды достучаться сложнее, чем до Чака Норриса, то вот развивающемуся проекту можно придать основательность =)
Всякий этих Го уже есть и будет еще много разных, тут ведь дело в том что нода это JS код, низкий порог вхождения, много школоты разработчиков.
При чём тут это? Я про ступор ноды, показательное нежелание развиваться.
Ну да, порог не высок, только вот IO и Node этим страдают в равной мере. Хотя если IO сделает доверенные пакеты, она и тут может приподняться)
Молодые проекты не надо толкать, зачастую, но стоит показать где грабли и почему не стоит на них наступать. Отсюда и название статьи) IO как раз такой. И пока он молод, он может стать основательным. А найдите мне программиста (не Python) который не ценит основательность =)
Ну да, порог не высок, только вот IO и Node этим страдают в равной мере. Хотя если IO сделает доверенные пакеты, она и тут может приподняться)
Молодые проекты не надо толкать, зачастую, но стоит показать где грабли и почему не стоит на них наступать. Отсюда и название статьи) IO как раз такой. И пока он молод, он может стать основательным. А найдите мне программиста (не Python) который не ценит основательность =)
Все верно, проект ведь решили форкнуть гики для фана. В итоге нода будет для продакшена, айо — для хипстеров (если вообще будет). Оно ведь так часто бывает, если за опенсорсным проектом не стоит какая-либо компания (финансирование), то в продакшене использовать эти хоть и модные поделки боязно.
А для ноды возможно это и не плохо. Это как аналогия комьюнити лицензии и коммерческой. Айо обкатывает технологии, нода проверенное по-немногу внедряет.
А для ноды возможно это и не плохо. Это как аналогия комьюнити лицензии и коммерческой. Айо обкатывает технологии, нода проверенное по-немногу внедряет.
UFO just landed and posted this here
Ещё одна статья-страшилка, наподобие той про ангуляр. Всё не так плохо.
Да не плохо, если осмысленно подходить к выбору тулзов для продакшена.
Под другим названием, но слышал. Обратная совместимость не обязательно нужна java-подобная (хотя это очень полезно). Окей, выпустили новый движок — дайте флаг запуска в режиме совместимости (как делает GCC, можно компилировать в режиме совместимости с более старой версией С++).
Почему обратная совместимость так важна: не редко, уйдя далеко вперёд во времени, движок круто эволюционирует. И без неё не запустится хорошо отлаженный скрипт, интерфейс или программа. Кто-то зелёный скажет: «да соберите вы старую версию, если она так нужна!» И библиотеки к ней, и компилятор, и вообще почти всю ОС под chroot-ом. Ради того, чтобы запустить старый отлаженный и рабочий скрипт.
Разве nan не должны использовать сами разработчики модуля на С++? Как это решает проблему вин/амд/арм гарантий сборки в целом?
При чём тут «я тестирую»? Необходимо понимать как работает тот или иной вызов ещё до написания кода. Зияют дыры в FS, Zlb, хотя в целом причесали.
Это призыв о помощи, т.к. круг программистов не так велик. А не страшилка =) Не плохо, но хуже от фундаментального превосходства над нодой не будет)
Почему обратная совместимость так важна: не редко, уйдя далеко вперёд во времени, движок круто эволюционирует. И без неё не запустится хорошо отлаженный скрипт, интерфейс или программа. Кто-то зелёный скажет: «да соберите вы старую версию, если она так нужна!» И библиотеки к ней, и компилятор, и вообще почти всю ОС под chroot-ом. Ради того, чтобы запустить старый отлаженный и рабочий скрипт.
Разве nan не должны использовать сами разработчики модуля на С++? Как это решает проблему вин/амд/арм гарантий сборки в целом?
При чём тут «я тестирую»? Необходимо понимать как работает тот или иной вызов ещё до написания кода. Зияют дыры в FS, Zlb, хотя в целом причесали.
Это призыв о помощи, т.к. круг программистов не так велик. А не страшилка =) Не плохо, но хуже от фундаментального превосходства над нодой не будет)
а речь об отсутствии гарантий, что после «очередного» обновления ядра движка, не отвалится что-то
За гарантиями в проект v8. Думаете, он рискнет обновиться так что что-нибудь отвалится?
Я лично очень в этом сомневаюсь
io.js — это же по сути «обвес».
Node и io.js для каждого модуля указывают что с API. Есть и frozen модули, вроде util, а есть и experimental, вроде smalloc. Если модуль будет deprecated — он так и пометится.
На счет компилируемых модулей — код платформозависим до той степени, до которой его довел разработчик этого модуля. На сколько я знаю все, что в io.js — не платформозависимо и поддерживаются все основные платформы и архитектуры.
На счет компилируемых модулей — код платформозависим до той степени, до которой его довел разработчик этого модуля. На сколько я знаю все, что в io.js — не платформозависимо и поддерживаются все основные платформы и архитектуры.
Немного о статусах модулей
На счёт статуса модуля: это хорошо, на них можно уже опираться в продакшене, точнее на всё серьёзнее stable. Хотелось бы чтобы все базовые модули API довели до stable. Многовато unstable+experimental. Даже «просто при работой с ФС» утрированно и обывательски говоря =)
Проблема, что судьба deprecated не известна. Осуждаемые (но исполняемые всё-таки) или не поддерживаемые. И в этом суть проблемы.
Проблема в компилируемых модулях, что я не всегда предупреждён, что собираю проект с оным. Иных фундаментальных трудностей с ними нет)
Ноду не развивали долгое время, собственно от чего и родился форк. Теперь команда подготовила первый релиз, обновила зависимости. Подождите чу-чуть и будут модули доводиться до stable/frozen статуса.
Для сравнения в c++ до сих пор в стандартной библиотеке нет работы с файловой системой
Для сравнения в c++ до сих пор в стандартной библиотеке нет работы с файловой системой
Ждать можно по-разному. Отсюда и применил теорию 6-ти рукопожатий, попросив Хабр помочь донести данную критику до разработчиков =) Меня в своё время очень разочаровала нода, которая развивалась-развивалась, а такие ключевые детали так и остались граблями.
Поэтому IO — надежда. И пока он молод, в него можно заложить основы. Куй железо, пока горячо, правильно ведь?)
Нету, увы. В С++ обратная совместимость стандартов тоже отсутствует. Но gcc творит чудеса =)
Поэтому IO — надежда. И пока он молод, в него можно заложить основы. Куй железо, пока горячо, правильно ведь?)
Нету, увы. В С++ обратная совместимость стандартов тоже отсутствует. Но gcc творит чудеса =)
BOOST
Хотя это хорошо реализуется стабильным и прекрасным бустом. Возможно я слишком мало его использовал, что так пишу. Я не против такой же стабильной библиотеки извне. Если, грубо говоря, можно будет не заботится вообще о stable/deprecated внутри платформы, а интерфейс всё свяжет сам, то круто. Это скорее инструмент, чем сам движок.
На мой взгляд правильно было бы конкретно сформировать ваши пожелания и написать в issue tracker. github.com/iojs/io.js/pulse — issues не остаютя без внимания, не смотря на напор.
И по поводу обратной совместимости стандартов — на мой взгляд совсем не весело тянуть за собой обратную совместимость в мажорных версиях. Что если вы сделали в языке/библиотеке что-то не так? Функция называется parse_str, а на деле это parse_url.
Хабраюзеры, я ни много ни мало удивлён! 50/50 практически людей, которые за улучшение IO в данных местах и против них. Хотя, может, последних задела критика IO =) Или ноды (всё-таки в статье о проблемах унаследованных от ноды).
Люди, которые считают это всё это второстепенными проблемами или не проблемами, отзовитесь, скажите плиз, а зачем Вам тогда вообще IO? =)
Люди, которые считают это всё это второстепенными проблемами или не проблемами, отзовитесь, скажите плиз, а зачем Вам тогда вообще IO? =)
Sign up to leave a comment.
IO.js или старые грабли под новым соусом