Я сражался с Node.js достаточно долго, что бы перестать получать от этого удовольствие, так что, по крайней мере пока, это мое официальное прощание! И, что еще важнее, я ищу людей, которые смогут поддерживать мои проекты!
Node отлично справляется с некоторыми вещами, но, к сожалению, это не самый подходящий инструмент для того, что мне сейчас интересно. Я все еще планирую использовать его для сайтов, но если вы хотели бы заняться поддержкой одного из моих проектов, дайте мне знать. Просто оставьте комментарий с вашим именем на гитхабе, ссылкой на npm и название проекта. Как обычно я прошу не привносить больших изменений в сущеcтвующие 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 привлекает людей с самыми различными уровнями знаний и умений.
There’s no central registry for Go packages, so you’ll often see 5 or 6 packages of the same name. This can be a little confusing at times but it has an interesting side-effect, you really have to review each one to determine the best solution. With Node there are usually canonical packages such as “redis”, “mongodb-native”, or “zeromq”, so you may stop right there and just assume those are the best ones.
Не существует единого репозитория для библиотек Go, поэтому часто можно встретить 5 или 6 разных пакетов с одним и тем же именем, что может иногда вызвать путаницу, но у этого есть и полезная сторона: нужно внимательно проверять каждый, чтобы выбрать самое лучшее решение. В Node есть общепринятые модули, вроде “redis”, “mongodb-native”, или “zeromq”, так что можно предположить, что это лучший вариант и остановить поиски.
Go или Node?
Если вы много работаете на распределенными проектами, то примитивы для параллелизации в го покажутся вам выразительными и полезными. Мы могли бы сделать похожие вещи в Node с помощью генераторов, но, по моему, генераторы позволят нам пройти лишь половину пути. Если у нас не будет отдельной обработки и репоринга ошибок для стеков, мы достигнем лишь средних результатов. Я также не хочу ждать три года, пока сообщество что-то родит, когда существуют готовые решения, которые отлично работают
Обработка ошибок на мой взгляд реализована в Go гораздо лучше. Node позволяет нам принять решения для каждой отдельной взятой ошибки, но есть несколько вещей, где у Node все плохо:
- У вас могут быть дублированные коллбэки
- У вас может вообще не быть коллбеков (потерялись)
- У вас могут быть ошибки вне диапазона
- Эмиттеры могут получить несколько ошибочных событий
- Отсутствующие события с ошибками отправляет все в лес
- Часто непонятно, откуда берутся обработчики ошибок
- Обработчики ошибок слишком многословны
- Коллбеки — отстой
В Go если мой код выполнен, он выполнен, нельзя еще раз выполнить оператор. В Node это не так. Вам может показаться, что код закончил выполнение, ровно до того момента, пока библиотека случайно не запустит колбек несколько раз, или неправильно очистит обработчики, что вызовет повторое исполнение кода. С этим непросто разобраться, особенно когда код уже в продакшене, да и зачем? Другие языки не будут причинять вам эту боль.
Node в будущем
Я еще надеюсь, что у Node все будет в порядке, множество людей вложили в него свой труд и у него есть потенциал. Я считаю, что Joyent и команда должны с фокусироваться на удобстве использования: производительность ничего не значит, если ваше приложение сложно отлаживать, рефакторить и разрабатывать.
Наличие ошибок вроде “Error: getaddrinfo EADDRINFO”, по прошествии 4-5 лет, показывает расстановку приоритетов. Понятно, что можно пропустить такие мелочи, если вы концентрируете свои усилия на разработки ядра системы, но пользователи раз за разом напоминают про это а результатов все еще не видно. Мы обычно получаем ответы от людей из «элиты», заявляющих, что то, что есть сейчас идеально, но на самом деле все наобот.
Потоки (Streams) сломаны, работать с колбэками неудобно, сообщения об ошибках расплывчаты и непонятны, инструменты не вызывают восторга, соглашения сообщества вроде есть, но им еще далеко до того, что есть в Go. Учитывая все вышеперечисленное, существует набор задач, для которых я продлолжу использовать node: веб сайты, может какой-нибудь прототип или API. Если Node сможет починить свои основные проблемы, тогда у него есть неплозие шансы оставаться полузным, однако аргумент о предпочтении производительности удобству использования работает на очень хорошо, когда существуют решения, которые быстрее и удобней.
Я не пытаюсь задеть кого-то лично, множество действительно талантливых людей работают с и над Node, но больше это интереса для меня не представляет. Я провел отличное време в этом сообществе и встретил довольно много клевых людей.
Мораль сей истории такова: не живите в пузыре, оглянитесь и посмотрите, что еще есть вокруг, возможно вы снова полюбите программирование. Вокруг есть множество отличных решений и моей ошибкой было то, что я слишком долго ждал, чтобы пойти и попробовать их.
Автор: z6Dabrata
