http://habrahabr.ru/post/228751/

Примечание от переводчика:

Я решил перевести эту статью в основном из-за личности автора. TJ вложил очень много усилий в развитие Node.js и его инфраструктуры, он автор таких проектов как express, jade, mocha, stylus, автор 550 репозиториев на npm. Существуют также теория, что под этим именем скрывается группа людей.

Как бы то ни было, JavaScript и Go сообщества в ближайшие время ожидают изменения.

Покидая страну Node.js

Я сражался с Node.js достаточно долго, что бы перестать получать от этого удовольствие, это мое официальное прощание! И, что еще важнее, я ищу людей, которые смогут поддерживать мои проекты!

Node отлично справляется с некоторыми вещами, но, к сожалению, это не самый подходящий инструмент для того, что мне сейчас интересно. Я все еще планирую использовать его для сайтов, но если вы хотели бы заняться поддержкой одного из моих проектов, дайте мне знать. Просто оставьте комментарий с вашим именем на Github, ссылкой на npm и названием проекта. Как обычно я прошу не делать больших изменений в существующих API: создать новый проект будет проще.

Я также продолжу поддерживать Koa.

Святой Грааль

Мне всегда нравился С, но каждый, кто работал с C знает, что хоть этот язык и может приносить удовольствие, он подвержен ошибкам. Сейчас довольно сложно обосновать выбор этого языка в качестве инструмента на каждый день, так как скорость работы с ним невелика. Я всегда восхищался простотой, но в данном случае сложно уехать далеко без огромного количества шаблонного кода.

Чем больше времени я посвящаю работе с распределенными системами, тем больше меня расстраивает направление, в котором движется Node, предпочитающий производительность удобству использования и надежности. На прошлой неделе я переписал довольно большую распределенную систему на Go. Она надежнее и быстрее, ее легче поддерживать и покрытие тестов у нее больше: проще и приятнее работать с синхронным кодом.

Я не говорю, что Go — «Святой Грааль», он не идеален, но для меня, среди существующих сейчас языков, Go — отличный выбор. Со временем, когда языки следующего поколения, такие как Rust и Julia найдут свое применение и повзрослеют, я уверен, что количество отличных решений увеличится.

Лично меня Go больше всего впечатлил скоростью развития языка. Весьма впечатляет увидеть, как разработчики стремятся к 2.0 и, как я слышал, не боятся поломать обратную совместимость, что отлично.

ПОПРАВКА: Я видимо неправильно прочитал рассылку, никаких критических изменений ближайшее время не планируется.

Было бы круто, если бы это было так, я верю, что отказ от обратной совместимости помогает языку развиваться, хотя я и не софтверная корпорация поддерживающая гигантские системы

Почему Go?

Node все еще отличный инструмент и если вам все нравится, то нету повода переживать. Но если у вас есть хоть какие-то сомнения, не поленитесь оглянуться и посмотреть, что еще есть вокруг — я подсел на Go в первые же несколько часов использования его в производстве.

Еще раз, я не утверждаю, что Go — самый лучший язык в мире, и вам обязательно нужно начать его использовать, но он весьма зрел и надежен для своего возраста (ему примерно столько же, сколько и Node.js), рефакторинг с типами прост и приятен, инструменты, которые Go предоставляет для профилирования и отладки работают отлично, а в сообществе есть устоявшиеся представления о документации, форматировании, измерении скорости и дизайне API

В момент первого знакомства с Go, стандартная библиотека показалась мне просто ужасной, в основном из-за того, что я привык к ультра-модульности в Node, и видел, как гниет стандартная библиотека в Ruby. Когда я начал больше работать с языком, я понял, что большая часть stdlib Go играет важную роль в разработке программного обеспечение: компрессия, JSON, буферизированный ввод/вывод, операции над строками и прочее. Большая часть этих API хорошо продуманы и мощны. Можно писать целые программы, в основном используя лишь стандартную библиотеку.

Сторонние библиотеки Go

Многие Go библиотеки выглядят и чувствуются одинаково, большая часть стороннего кода, с которым я до этого момента работал довольно хорошего качества, что не часто встречается в случае Node, потому что JavaScript привлекает людей с самыми различными уровнями знаний и умений.

Не существует единого репозитория для библиотек Go, поэтому часто можно встретить 5 или 6 разных пакетов с одним и тем же именем, что может иногда вызвать путаницу, но у этого есть и полезная сторона: нужно внимательно проверять каждый, чтобы выбрать самое лучшее решение. В Node есть общепринятые модули, вроде “redis”, “mongodb-native”, или “zeromq”, так что можно предположить, что это лучший вариант и остановить поиски.

Go или Node?

Если вы много работаете над распределенными проектами, то примитивы для параллелизации в Go покажутся вам выразительными и полезными. Мы могли бы сделать похожие вещи в Node с помощью генераторов, но, по моему, генераторы позволят нам пройти лишь половину пути. Если у нас не будет отдельной обработки и отчетов для ошибок стеков, мы получишь весьма средние результаты. Я также не хочу ждать три года, пока сообщество что-то родит, когда существуют готовые решения, которые отлично работают

Обработка ошибок, на мой взгляд, реализована в Go гораздо лучше. Node позволяет нам принять решения для каждой отдельной взятой ошибки, но есть несколько вещей, где у Node все плохо:

• У вас могут быть дублированные callback'и
• Вызов callback'а может потеряться по дороге
• У вас могут быть ошибки вообще из других потоков
• В обработчик emitter могут прийти несколько событий типа «error»
• Если не поймать ошибку, то все полетит к чертям
• Часто непонятно, как именно обрабатываются ошибки
• Обработчики ошибок слишком многословны
• Callback'и — отстой

В Go если мой код выполнен, он выполнен, нельзя еще раз выполнить оператор. В Node это не так. Вам может показаться, что код закончил выполнение, ровно до того момента, пока библиотека случайно не запустит callback несколько раз, или неправильно очистит обработчики, что вызовет повторое исполнение кода. С этим непросто разобраться, особенно когда код уже в продакшене, да и зачем? Другие языки не заставят вас так страдать

Node в будущем

Я еще надеюсь, что у Node все будет в порядке, множество людей вложили в него свой труд и у него есть потенциал. Я считаю, что Joyent и команда должны сфокусироваться на удобстве использования: производительность ничего не значит, если ваше приложение сложно отлаживать, рефакторить и разрабатывать.

Наличие ошибок вроде “Error: getaddrinfo EADDRINFO”, по прошествии 4-5 лет, показывает расстановку приоритетов. Понятно, что можно пропустить такие мелочи, если вы концентрируете свои усилия на разработке ядра системы, но пользователи раз за разом напоминают про это а результатов все еще не видно. Мы обычно получаем ответы от людей из «элиты», заявляющих, и сейчас все идеально, но, на самом деле, все обстоит иначе.

Потоки (Streams) сломаны, работать с callback'ами неудобно, сообщения об ошибках расплывчаты и непонятны, инструменты не вызывают восторга, соглашения сообщества вроде есть, но им еще далеко до того, что есть в Go. Учитывая все вышеперечисленное, существует набор задач, для которых я продолжу использовать Node: сайты, может какой-нибудь прототип или API. Если Node сможет починить свои основные проблемы, тогда у него есть неплохие шансы оставаться полезным, однако аргумент, о предпочтении производительности удобству использования, работает не очень хорошо, учитывая, что существуют решения, которые быстрее и удобней.

Я не пытаюсь задеть кого-то лично, множество действительно талантливых людей работают с/над Node, но больше это интереса для меня не представляет. Я провел отличное время в этом сообществе и встретил довольно много клевых людей.

Мораль сей истории такова: не живите в пузыре, оглянитесь и посмотрите, что еще есть вокруг, возможно вы снова полюбите программирование. Вокруг есть множество отличных решений и моей ошибкой было то, что я слишком долго ждал, чтобы пойти и попробовать их.

Примечание от переводчика:

Совсем незадолго до появления переведенной статьи, была опубликована заметка от Will Yager с противоположным мнением: Почему Go плохой (eng.), было бы здорово, если бы кто-то знакомый с Go, взялся бы за перевод, чтобы дополнить картину.