Developer Survey Results за 2019 год

На SO появился самый интересный Developer Survey Results за 2019 год. Самые на мой взгляд главные моменты в этом опросе:

  • Python растет невероятно быстрыми темпами для такого не молодого языка, нашел свою нишу. Тут, безуспловно, изрядную роль в столь стремительном росте оказали ML с одной стороны и рост популярности автоматизации всего и вся с другой стороны. А так как Python великолепно себя зарекомендовал в обоих областях, то ожидать чего-то иного было бы сложно. Если вы думаете о том, какой бы язык изучить – не думайте, возьмите область в которой популярен Python разберитесь, окупится.
  • Rust самый желанный и быстро растущий язык на протяжении последних 4-х лет. Лично для меня это невероятно удивительный факт с учетом сложности этого языка. Думаю что изрядная составляющего этого роста – шумиха вокруг языка от людей, которые на нем ничего сложнее “Привет Мир” не писали, но факт остается фактом и шумиха не может не сказаться на количестве вакансий на этом языке. Опытным разработчикам, особенно с опытом в C/C++ есть на что обратить внимание.
  • Моя персональная слабость – Vim, по прежнему входит 5-ку самых популярных сред для разработки! Ура и вечной жизни этому восхитительному редактору.
  • Kotlin стал 4-м по желанности языком! Восхитительная новость, а JetBrains молодцы!
  • В общем случае лучше всего платят за Site Reliability Engineering (что за зверь такой?) и DevOps. Если же говорить про разработчиков, то в лидерах Clojure, Go, F# и Scala. Если с Clojure мне совершенно не понятно кто и за что так хорошо платит, то F# и Scala – это явно финансы, а Go – это разнообразные бэкенды и облака. Выбор куда идти за хорошей ЗП довольно простой, правда?
  • Наиболее оптимистично смотрящие в будущее разработчики живут в Китае, наименее оптимистичные в Западной Европе. Ну что, тоже более чем ожидаемо, но то, что даже программисты начали что-то подозревать кажется занятным.
  • Для большинства разработчиков программирование – это еще и хобби. Я, видимо, в какой-то другой вселенной живу, но где эти 80% у которых программирование – хобби?!
  • В Индии почти все разработчики постоянно ищут работу. Во всех остальных странах для которых приведены данные тренд противоположный.

Активные объекты в Go

Активные объекты – это прекрасно, но не всегда и везде легко доступны. Почему они могут быть полезные в Go и как их эмулировать ниже. И, да, я осознанно использую дремучий термин Активные объекты из POSA, так как Акторы в современном виде – это сильно более объемный и разносторонний концепт. BlaBlaManager о котором пойдет речь ниже, был взят в качестве иллюстрации исключительно потому, что с чем-то подобным я не так давно боролся, но сама идея Активных объектов и уж тем более Акторов куда более широко применима, именно за этой информацией я бы посоветовал либо сходить к eao197, либо почитать про AKKA.

В большинстве приложений обладающих состоянием скорее рано чем поздно заводиться объект с именем так или иначе похожим на BlaBlaManager. В стародавние времена, аккурат на пике популярности GOF, он был формой синглтона, да и сейчас, к сожалению, часто им остается. Если дизайн у проекта изначально был верный, или если проект пережил рефакторинг, то BlaBlaManager будет управлять только одним ресурсом, но может и не повезти, тогда BlaBlaManager окажется свалкой всего и вся, объектом-Богом. Так же BlaBlaManager обычно имеет методы похожие на RegisterFoo, RemoveBoo, FindBazz и тому подобное. То есть речь идет об объекте, который хранит некоторое динамически изменяемое состояние системы и/или одной из её подсистем. Думаю, все так или иначе вспомнили о подобном объекте в текущем проекте, если же нет, то я вам очень завидую.
Continue reading →

Go-каналы изнутри

Так как Go стал для меня вторым основным языком после C++, стало очевидно, что надо понимать как он работает не только снаружи, но и изнутри. Я немного сомневался с чего начать, то-ли с горутин, то-ли с каналов. Приблизительно представляя как может быть реализовано и то и другое, первым и наиболее разумным кандидатом на пристальное изучение оказались каналы. Ну что сказать, интересно!

Реализация каналов вместе со всей остальной низкоуровневой частью лежит в src/runtime/chan.go, и довольно легко поддается анализу. Физически, канал представлен структурой hchan, где наиболее интересно выглядят следующие моменты:
Continue reading →

Основная головная боль в мире C++

В процессе обсуждения увлекательного вопроса “за что не любят современный C++” всплыл интересный список последствий UB оптимизаций. В отличие от довольно простого управления памятью которое мы получили начиная с C++14, UB – это действительно ужас-ужас, который фактически не реально держать в голове.

Великолепный пример с переполнением при умножении i на миллиард, который позволяет компилятору сильно “упростить” цикл:
Continue reading →

Rust и социальные факторы

Так сложилось, что вчера, с одной стороны, Евгений провел довольно интересную аналогию между моделью памяти Rust и книгой и это была, наверное, самая наглядная иллюстрация различий в отличиях управления памятью между Rust и C++. А с другой стороны я прочитал  “Memory Management Patterns in Business-Level Programs” из 148 выпуска Overload в которой вскользь затронут этот же вопрос. В обоих случаях отношение к изменениям принесенным Rust на мой взгляд очень разумное: изменения на выдающиеся не тянут и решают уже решенную со времен C++14 (хотел бы написать со времен C++11, но make_unique появился только в C++14, а без него модель была не полной) проблему сильно более сложным способом, заставляя думать не только о корректности логики как таковой, но и о доказуемой корректности кода с точки зрения конкретной версии компилятора.

При этом, все мы живем в обществе, работаем в командах и не можем игнорировать вау эффекты и стадные инстинкты. По не очень понятным мне причинам я со всех сторон наблюдаю щенячий восторг по поводу Rust от людей которых я бы ну никак не заподозрил в таком. Например сегодня был диалог с очень продвинутым Python-разработчиком и не менее продвинутым C# разработчиком о том, что Rust – это круто, Rust – это нам надо и мы уже начали затягивать его в нашу кодовую базу. При этом какие-либо аргументы в пользу того, что то же самое можно сделать в меньшее количество легче воспринимающихся строк кода на C++14 (так как код не будет изобиловать модификаторами времени жизни) отбрасываются сразу с аргументами “я 15 лет назад на C++ писал – жуткое убожество”.

Наблюдая за скоростью продвижения Rust исключительно (как мне кажется) за счет этого загадочного вау-эффекта начинаешь задумываться, а может всё же стоит вложиться в него временем более серьезно? Не по тому, что такое большое количество народу не может ошибаться, а потому, что когда говоришь с фанатиками и понимаешь предмет их фанатизма, легче “продать” что-то кажущееся правильным и нужным лично тебе. И пусть логически проект проще и быстрее выполнить на C++, желание сделать на чем-то ином очень важный стимул который довольно часто положительно сказывается на качестве готового решения. Единственная и самая главная неизвестная для меня в этом вопросе, а на как долго хватит этого Растоманского запала? Что же будет после него? Понятно, что C++ был, есть и будет, но вот Rust…

Два года с Go

Сейчас подвожу итоги где-то 2-х лет разработки серии проектов на Go и довольно приятно удивляюсь тому, насколько хорошую защиту от дурака имеет Go по-умолчанию. Выстрелить себе в ногу просто невероятно сложно и в общем случае разработчик может просто сконцентрироваться на задаче не думая про UB, особенности move semantic и кучу других вещей, которые постоянно должны быть в голове у C++ разработчика.

Если отбросить очень сильное упрощение языка и попытаться выделить какие же именно решения позволили сильно упростить работу, то я бы отметил два: 1) отсутствие классов и наследования, 2) запрет на циклические импорты.

Continue reading →

ML не взлетает…

В начале этого года меня довольно сильно проперло с  машинного обучения. Настолько сильно что я прошел Deep Learning Specialization и стал размышлять на тему того, что дальше делать и как это монетизировать.

В плане того, что делать дальше курсы в рамках  Deep Learning Specialization довольно наглядно показали что тема откровенно бездонная, и если хочется не просто как-то решать задачи при помощи TensorFlow и иже с ними, но и понимать то что делаешь, то нужно копать отсюда и ужина, который ожидается в лучшем случае через несколько лет. Я было даже взялся за Mathematics for Machine Learning, чтобы освежить школьную математику, которая была само собой благополучно забыта за 20 лет после окончания школы. Но что-то мне начало казаться, что так слона не съесть, так как он слишком велик. У меня вообще сложилось ощущение что люди в ML делятся на две категории: одни понимают как оно работает, а вторые просто используют инструменты без понимания что внутри. И само собой, этих самых вторых около 98%, что выглядит очень страшно…

С монетизацией тоже не всё понятно. Несмотря на шумиху вокруг ML, тема довольно нишевая и если приглядется к вакансиям в мире ML, то нормальный уровень (текущий, грубо говоря) дохода гарантирует только звездный уровень с PhD в данной области в придачу. Возникает довольно твердое убеждение что успешно продать ML в дополнение к моей основной специализации скорей всего не выйдет. А если что-то нельзя продать, то зачем оно нужно?

Плюс мир ML чем-то напоминает мир JavaScript с новыми прорывными решениями по нескольку раз в год, что сильно контрастирует с моей текущей специализацией. Те же сети и системная разработка позволяет довольно прохладно относиться к гонке за новинками, так как нового тут не так уж и много. К примеру те же несчастные корутины, которые “вот наконец решат все проблемы разработки сетевых приложений на C++”, обсасывают со всех сторон уже третий год, и реализации в 3-х основных компиляторах как разом как небыло, так и нет. Хорошо если через год-другой выкатят…

Но так как учить что-то надо всегда и во всех ситуациях, я на некотором распутье, то-ли продолжить копать ML, но не очень понятно как и в каком направлении, то-ли… ну, к примеру, посмотреть на blockchain, с куда более близкими криптографией, сетями и т.п.

CppCon 2018

В этом году мне посчастливилось в третий раз оказаться на конференции CppCon. Как и в прошлые годы, на конференции можно найти интересные доклады из практически любой области применения C++. Если сравнивать с конференциями прошлый лет, то в 2018 году вышло на уровне 2016, просто конференция 2017 была особенно прекрасной по содержанию 🙂
Внезапно самыми интересными для меня в этом году оказались не доклады Гуру С++, которые на этом деле собаку съели, а выступления не замеченных мной ранее докладчиков.
  1. Текущая ситуация, когда сообщество информационной безопасности стоит особняком от сообщества разработчиков, мне кажется в корне не верной и доклад Software Vulnerabilities in C and C++ как раз был направлен на устранение данного безобразия. Это просто замечательное начинание, так как конференции типа BlackHat и PHdays скучны для разработчиков, а сами безопасники к нам не ходят. В результате образуется нелепый вакуум, хотя в теории оба сообщества должны тесно работать друг с другом.
  2. Идея доклада Better C++ using Machine Learning on Large Projects вроде и лежит на поверхности, но решились реализовать такое только в Ubisoft Montreal. Суть идеи проста: у нас есть история коммитов и история ошибок. А что будет если их объединить и натренировать сеть? Может даже получиться не только предсказать будет ли в коммите дефект (с довольно хорошей вероятность 75%), но и автоматом предложить код с исправлением?
  3. Как неожиданно выяснилось, прямой конкурент Maya и 3D MAX пишет команда из 25 человек и очень успешно занимается этим последний 21 год. Вызовы и их решение в докладе Patterns and Techniques Used in the Houdini 3D Graphics Application.
  4. Довольно хороший рассказ про организацию сборочного пайплайна (правда у нас лучше вышел) в докладе Big Infrastructure at a Small Scale.
  5. Многопоточность – боль для очень и очень многих включая меня. What do you mean “thread-safe”? обобщает вопросы связанные с безопасностью разработки многопоточного кода на концептуальном уровне. В вроцессе много думал и планирую пересмотреть.
Остальное интересное и не очень:
  1. Начиналось все со Страуструпа и Concepts: The Future of Generic Programming. Скучно, как и все виденные мной предыдущие его выступления, но не пойти на Самого тоже никак.
  2. Очень-очень хороший доклад от Kate Gregory Simplicity: not just for beginners. Хорош он в первую очередь тем, что призывает и доступно объясняет что же такое простой код, к которому все разработчики должны стремиться.
  3. Доклад Саттера как-то смутно отложился в голове, вроде всё здорово и увлекательно, но… то-ли “но к чему это”, то-ли “а зачем столько лишних слов” не давали мне покоя на докладе Thoughts on a More Powerful and Simpler C++. Самое главное что я из него вынес и собираюсь как можно скорее опробовать флаг -Wlifetime, пиару которого была посвящена половина этого доклада. Да, вторая половина про метаклассы, которые постепенно начинают принимать очертания и лет через 10 мы их получим, если повезет.
  4. Закрывал конференцию доклад про нашумевшую уязвимость Spectre: Secrets, Side-Channels, Sandboxes, and Security с живой демкой и кучей ассемблерного кода. Было невероятно интересно и познавательно.
  5. Часто задавался вопросом “как же работает отладчик”, но ленился найти на него ответ и тут всё взяли да рассказали на How C++ Debuggers Work. Про отладчики было вообще много, как потому что  Backtrace активно пиарятся, так и потому, что писать нормально поставить процесс разработки на C++ выходит сильно не у всех.
К сожалению я упустил целую кучу потенциально интересных докладов, которые теперь жду на YouToube:
  1. Git, CMake, Conan – How to ship and reuse our C++ projects и Debug C++ Without Running я пропустил из-за энергичного и очень посредственного доклада Александреску Expect the Expected.
Ну а самым разорчаровывающим докладом где, как мне кажется, никто не понял зачем докладчик вообще вышел на сцену был Interfaces matter: High Performance and Heap Allocated Containers. В итоге вместо часа доклад уложился в 30 минут и вопросов не было от слова совсем, так как единственные вопрос “а к чему тут это все было?” как-то не удобно задавать…
Удивительным изменением в этом году было количество рускоговорящих на конференции, по моим прикидкам около 10, может быть 15% от общего числа посетителей. В итоге мы весело и познавательно посидели небольшой компанией в человек 20 в баре перед отъездом, жаль только из Касперского на конференции я никого из знакомых не увидел.

Зачем и кому нужен Go?

Так вышло, что последнии 2 года я довольно плотно работаю не только с давно привычными мне C++ и Python, но и Go. Как мне кажется, 2 года довольно приличный срок для того чтобы сформировать свое мнение о каком-либо инструменте, так что, пора им поделиться. Так же, по моим ощущениям, про Go обычно пишут люди из небольших компаний и стартапов, я же буду писать с точки зрения разработчика из матерой корпорации специализирующейся на разработке ПО.

Когда Go не нужен и не полезен

Начнем с самого важного: при каких условиях этот язык скорее вреден.
Continue reading →

Командная строка и Windows

Надо признать, что время не стоит на месте и за те 9 лет что я не работал с Windows много что изменилось. Довольно неожиданным для меня открытием оказалось современное состояние командной строки на Windows, которая дошла до некого рабочего состояния. Не совсем, конечно, Vim так же хреново работает как и раньше, но всё же. Итак, как сделать окружение Windows относительно удобным для того, кто привык к *NIX. Continue reading →