Прежде всего, это статья, переведенная из прощального узла TJ.js. Я действительно оказал некоторое влияние после прочтения этой статьи, но я не согласен с некоторыми взглядами автора. Например, я думаю, что реестр пакетов Node.js является одним из его многочисленных преимуществ, но GO немного не хватает в этом отношении. Из -за личного уровня я не понимаю много вещей при переводе. Я также пошел в блог автора и Stackoverflow, чтобы задать несколько вопросов, чтобы получить ответы. В переводе все еще есть много вещей, и я надеюсь получить точку зрения.
Пса Как новичок Node.js, благодаря TJ за его усилия и прошел весь путь.
текст:
Попрощайтесь с node.js
Оставить сферу node.js
Я сражался с узлом. Что еще более важно, мне нужен сопровождающий.
Узел действительно великолепен в некотором смысле, но это не подходящий инструмент, в конце концов, для того типа программного обеспечения, в котором я интересовался в последнее время. Я все еще планирую использовать узел в качестве веб -сайта, но если вы заинтересованы в поддержании какого -либо проекта, просто оставьте сообщение, чтобы записать свое имя пользователя GitHub, имя пользователя NPM и имя проекта, чтобы сообщить мне. Обычно все, что я прошу, это то, что вы не полностью меняете свой существующий API. Если вы действительно хотите это сделать, лучше начать новый проект.
KOA - это проект, который я буду продолжать поддерживать. (С Co и друзьями)
История Святого Грааля
Я всегда любил C, но каждый, кто работает в D Development, знает, что это ценно, но склонно к ошибкам. Трудно доказать выбор языка в повседневной работе, так как это не самая быстрая работа. Простота также является причиной того, что ее всегда хвалили, но вы не пойдете очень далеко без большого количества шаблонов.
Поскольку все больше людей участвуют в разработке распределенных систем, тенденция развития производительности узлов по сравнению с удобством использования и устойчивости меня была более разочарованной. За прошедшую неделю я переписываю относительно большую распределенную систему в GO, которая надежна, работает лучше и легко поддерживать и имеет лучшее испытательное покрытие из -за общей красоты и легче разрабатывать синхронный код.
Я не говорю, что Go - это Святой Грааль, он не идеален, но Go - отличный ответ для меня для многих языков, которые существуют сегодня. Поскольку все больше и больше этих языков «следующего поколения», таких как Rust и Julia, находят свое место и зрелые, я уверен, что у нас будут больше отличных решений.
Лично я очень взволнован GO из -за его итерации, я очень рад видеть, что они стремятся достичь версии 2.0, и, согласно новостям, которые я слышал, они не боятся разрушить оригинальные великие вещи. Если это правда, я счастлив, больше, потому что я считаю, что если это действительно полезно для этого языка, я должен быстро разбить то, что уже есть. Но я также не программный гигант, управляющий большим количеством систем. : D.
Под редакцией: я должен был неверно истолковывать некоторые списки рассылки отправки, и они не стремятся вносить некоторые разрушительные изменения в любое время. @enneff
Зачем идти?
Если узел работает для вас, и вам не о чем беспокоиться, это все еще отличный инструмент. Но если что -то вас беспокоит, не забудьте выпрыгнуть из своей коробки и посмотреть, что еще находится за пределами коробки - меня привлекли к нему в течение нескольких часов после первоначального использования, чтобы создать продукт.
Опять же, я не могу сказать, что Go, безусловно, лучший язык, и вы должны пойти с ним. Но для своего возраста он очень зрелый и надежный. (Примерно в том же возрасте, что и узел). Типовая реконструкция - это весело и простая, инструменты домашнего задания и отладки, предоставляемые GO, великолепны, и сообщество имеет очень сильные правила по документации, форматам, критериям и дизайну API.
Будучи настолько привыкшим к чрезвычайно модульному узлу и, испытав гнирующую стандартную библиотеку Руби, когда я впервые услышал о Go, я подумал, что ее стандартная библиотека была ужасной. После того, как я погрузился в этот язык, я понял, что большинство стандартных библиотек необходимы на данном этапе, такие как сжатие, JSON, IO, буферизованные вводы, струнные операции и т. Д. Большинство из этих API хорошо определены и мощны. Легко написать всю программу, просто используя эти стандартные библиотеки.
Сторонние пакеты GO
Большинство библиотек GO выглядят одинаково, большинство стороннего кода, которое я использовал до сих пор, имеет высокое качество, и их трудно найти в узле, потому что JavaScript привлекает разработчиков на разных уровнях квалификации.
Там нет реестра для пакетов GO, поэтому вы обычно видите 5 или 6 одинаковых пакетов одновременно. В какой -то момент это может вызвать некоторую путаницу, но имеет интересный побочный эффект, и вы должны решить, какой из них является лучшим вариантом, тщательно просмотрев каждый пакет. Через узел обычно существуют спецификационные пакеты, такие как «Redis», «Mongodb-родной» или «zeromq», так что вы остановитесь на этом и сделаете вывод, что они являются лучшими.
Если вы выполняете некоторую распределенную работу, вы найдете впечатляющие параллельные типы данных Go, которые очень полезны. Мы можем получить что -то похожее на генераторы в узле, но, по моему мнению, генераторы только наполовину сделаны. Без независимой обработки ошибок стек отчетности по -прежнему обычный, даже если он лучше. Когда эти решения работают хорошо, я не хочу ждать реорганизации сообщества в течение трех лет.
На мой взгляд, обработка ошибок GO является выдающейся. Узел великолепен с точки зрения того, что вы должны думать о каждой ошибке, и решать, как это сделать. Однако узел не удается в:
Вы можете повторить обратный вызов
Вы не можете сделать обратный вызов и заблудиться в нестабильном состоянии (например, забудьте передать ошибку для обработки обратного вызова. Когда возникает ошибка, узел проглотит ошибку без каких -либо обратной связи)
Вы можете получить ошибку вывода
Эмиттеры могут получить несколько неправильных событий
Забыл неправильное событие, чтобы справиться с этим, все испортит
Часто не уверен, что нужно для обработки ошибок
Обработка ошибок очень избыточная
Обратный вызов ужасен
В Go, когда мой код заканчивается, он заканчивается, и вы не можете повторно его предъявить его в заявлении. Это неясно в узле. Вы подумаете, что программа полностью выполнена до тех пор, пока библиотека неожиданно не вызовет обратный вызов несколько раз или неправильно не очистит обработчиков, а затем не приведет к выполнению кода снова выполнять. Довольно сложно найти эти причины в фактическом производственном коде, зачем их беспокоиться? Другие языки не позволят вам испытать эти боли.
Узел будущего
Я все еще надеюсь, что Узел делает хорошую работу, многие люди вкладывают в него огромную инвестицию, и у него есть такой потенциал. Я думаю, что Joyent и команда должны сосредоточиться на удобстве использования - если ваше приложение хрупкое и трудно отлаживать, рефактор и развивать, производительность бессмысленна.
Через 4-5 лет у нас все еще будет такая расплывчатая ошибка «ошибка: getaddrinfo eaddrinfo», и этот факт говорит нам, где находятся приоритеты развития узла. Понятно, что когда вы сосредотачиваетесь на построении ядра системы, легко пропустить эти вещи. Я думаю, что пользователи выразили свое мнение о таких вещах снова и снова, но не видели никаких результатов. Обычно мы получаем несколько ответов за то, что утверждают, что то, что у нас есть, уже идеально. На практике это не так.
Потоки прерываются, обратные вызовы не прост в использовании, ошибки неясны, инструменты не просты в использовании, существует правила сообщества, но им, кажется, не хватает по сравнению с Go. Несмотря на это, я могу продолжать использовать узел для некоторых конкретных задач, таких как создание веб -страниц или некоторые фрагментированные API или прототипы. Если узел может решить некоторые из своих фундаментальных проблем, то у него есть шанс остаться актуальным, но когда есть другое решение, которое работает выше, чем доступность, когда более высокая производительность и более высокие аргументы доступности не заходят слишком далеко.
Если сообщество Node решает принять генераторы и реализовать их в очень основном узле и соответствующим образом передавать ошибки, есть шанс сделать это. Это полностью улучшит удобство использования и надежность узла.
Хорошей новостью является то, что я разговаривал с великолепным и талантливым парнем, который не давно внес основной код в Стронглуп. Они явно применяют правильный способ решить эти проблемы, чтобы упростить работу будущих узлов, слушая ответы разработчиков на платформу и планируя найти правильный способ решить эти проблемы. Я не уверен, как закончится конфликт между несколькими компаниями в одновременной разработке основной части, но я надеюсь, что водитель разработчика победит.
Это не означает, что это атака на людей, многие действительно талантливые люди работают с узлом или на узле, но это больше не то, чем меня интересует. Я прекрасно провел время в сообществе узлов и встретил некоторых действительно интересных людей.
Значение истории в том, что вы не должны быть ограничены своим собственным кругом! Посмотрите, что в другом месте, и вы можете наслаждаться программированием снова. За пределами этого есть много удивительных решений, и ошибка, которую я совершил, заключается в том, что я слишком долго ждал, чтобы играть с ними!