Skip to main content

Go, Ruby, C++, etc

Совсем разучился писать что-то кроме спецификаций :)

Go
Попробовал Golang в продакшене (в прошлом году). Поначалу было непривычно пока не грокнул golang way (ну или я так думаю что грокнул). Итого несколько sidekiq воркеров запускающихся по расписанию которые генерили репорты для HP ArcSight и неслабо нагружали сервер были заменены на streaming report generaion service написанный на Golang который работает 24/7/365 и потребляет ресурсов в десятки раз меньше. Помимо этого умеет обрабатывать ситуации вроде дисконнекта RabbitMQ или postgres.
Выводы:



  • community, отсутствие необходимости backwards compatibility = huge benefit
  • если за языком стоит корпорация с мешком денег то это положительно сказывается на качестве/производительности рантайма/vm/etc (КО)
  • go get, go build - просто и быстро
  • io.Writer - прекрасен (клиент "внезапно" вспомнил что хотел чтобы репорты создавались в виде gzip архивов - для этого понадобилось добавить 5 строк и 1 поменять).
  • очень большое колличество библиотек (пакетов) написанных "с нуля" в которых зачастую используется uniform interface (как в контейнерах STL например) и которые можно начать использовать буквально за 5 минут.
  • дженериков реально не хватает
  • я бы предпочел C++ будь в нем CSP concurrency
  • преимущество языка в том что он простой и easily fits in your brain, т.е. очень быстро можно в него вьехать и достаточно продуктивно писать
Ruby
После того как Google купила Postrank и Ilya Grigorik   перестал писать про ruby колличество сопоставимого по качеству конента уменшилось значительно (мое впечатление). Исключение составляют блоги rubinius и jruby. Ruby is a memory hog - вся надежда на JRuby+Truffle и OMR (или опять же - на IBM и Oracle, ну кто бы мог подумать). Есть еще Maglev но судя по всему smalltalk + seaside используеся чаще чем maglev+ rails :) - спираль развития еще не дошла до того момента когда новое поколение программистов заново откроют для себя smalltalk (чего только smalltalk images стоят).
Отдельно упомяну sidekiq и его убогий dashboard (даже не смотря на pro версию), и странные конфликты с sidetiq + "Dead Actor" или "Actor crashed" сообщения от celluloid в логах отдебажить которые просто не хватает времени/рук.  Строить worker queue поверх редиса и наворачивать логику job management наверное изначально было плохой идеей. Надо было beanstalk брать тогда бы сейчас писал о нем, но кто ж меня слушал :)

C++
С каждой своей новой инкарнацией (C++11, C++14) становится все юзабельнее и юзабельнее, C++17 - сделает python не нужным :). Думаю нас ждет C++ ренесанс после того как люди поймут что можно выкинуть свои фермы серверов и заменить их на gpu accelerated computation units.
Blazegraph с их mapgraph и gpu accelerated rdf triplestore (wikidata  is powered by blazegraph btw) и off-jvm heap - одна из первых ласточек за которыми нужно смотреть внимательно - они делают правильные вещи на мой взгляд. Hypertable тоже наглядно показывает преимущества языков которые не генерят столько мусора что для его сборки нужен отдельный GC )). Хотя надо признать что в новом golang GC заимпрувили очень хорошо и вроде как Oracle тоже есть что предложить в новой java.

Рабочее
Никогда не разделял взгляд будто уход из инжиниринга в менеджмент это логическое развитие ИТ карьеры и не понимал людей которые так думали. Либо я асоциальный тип и, несмотря на то что легко схожусь с людьми, предпочитаю работать с машинами либо рациональный т.к. проблем при работе с машинами меньше кмк :). Но увы - "не так сталося як гадалося" - "надо же это кому-то делать" и вот нате - ты теперь тим лид. Вдобавок вместо одного вменяемого инженера на стороне клиента добавился к одному существующему невменяемому менеджеру еще один, тоже невменяемый и начал фигачить дубликаты карточек в таск трекер. Видимо это какой-то вирус, т.к. QA кастомера тоже начал заводить баги - дубликаты существующих. Я стал ненавидеть be nice behaviour  - которое мешает людям доносить друг другу реальное положение вещей ("нельзя использовть слово problem - используйте issue, т.к. problem - это КЗ головного мозга у кастомера и вообще - ааа"). Впервые столкнулся с тем что человек не в состоянии понять то, что ты ему говоришь прямым текстом (сразу вспомнился Задорнов) - в упор. Разительно отличается CTO родом из UK (он же product owner) но он не хочет участвовать в sprint planning. Проблема в том что кроме него со стороны заказчика никто вообще не отстреливает на должном уровне ни problem domain ни предлагаемые решения - только даты дедлайнов, коммитменты и метрики тасков в трекере. Вот тогда я понял о чем говорил тех лид кастомера на последнем митинге.

Сижу читаю Death March, Эдварда Йордона