Форумы умерли, да здравствует Slack

Когда я только добрался до интернета, а сделал я это довольно поздно, судя по дате регистрации на РСДН-е я активен в сети с года так 2006, то был восхищён профессиональными форумами. Это было место с реальной движухой, там были умные люди, они обсуждали интересные вопросы и вообще жизнь кипела ключом. Время шло, форумы стали отмирать. Какие-то стали местом обсуждения политики, какие-то годятся только на то, что бы замерять у кого длиннее, где-то принято плакаться на тяжелую жизнь и мечтать свалить, а какие-то годятся только для мастурбации на карму. Когда-то активные завсегдатаи говорят что куда интереснее обсудить политику или похвастаться большой ЗП, нежели поговорить про дело… а для дела есть StackOverflow, где уже на все вопросы давно ответили. Я никогда не понимал как можно сравнить форум и SO, ведь SO – это про вопрос/ответ и все дискуссии строго пресекаются, а форум был в первую очередь про дискуссию. Можно еще вспомнить про Reddit, но по мне так это скорее коллекция ссылок, нашел что-то интересное, запостил даже не потрудившись пары предложений со своими мыслями добавить, а тебе почесали ЧСВ поставив плюсики.

При этом я всегда думал, что должны быть еще люди, которым интересно профессиональное общение в первую очередь, а потом уже карма, политика и прочие не имеющие к профессиональной деятельности вещи. И да, догадка была верна, я наткнулся на Slack! На сегодня хотелось бы отметить следующие сообщества: Continue reading →

Приведение интерфейсов для базовых типов в Go

На работе завязалась интересная дискуссия: если в Go вообще всё можно привести к интерфейсу, является ли интерфейс некой базой для любого типа в Go? Как отслеживаются ошибки приведения типов для таких случаев? К примеру возьмем следующий код:

import (
    "fmt"
    "reflect"
)

func interfaceArg(i interface{})  {
    fmt.Println("type:", reflect.TypeOf(i))
}

func main() {
    var x float64 = 3.14
    interfaceArg(x)
}

Continue reading →

Clojure и AWS Lambda

Последнее время я неспешно работаю над своим новостным C++ ботом и в качестве заключительного шага его нужно где-то “поселить” жить. Вариантов, конечно же довольно много, начиная своим компьютером заканчивая облаками, но наиболее экономически целесообразным и простым в поддержке выглядит какое-либо бессерверное решение, например AWS Lambda. Так как Clojure приложение как Lambda я еще никогда не запускал, то решил вынести эксперименты отдельно от основного проекта. Оказалось не сложнее чем с Go, всего-то нужно взять подходящую библиотеку для простой и наглядной реализации точки входа, сделать правильную сборку, да не забыть про Terraform для удобного управления инфраструктурой.
Continue reading →

C++ интервью && многопоточность

В рамках поддержки формы и необходимости размяться перед серьезным поиском работы я походил по разным собеседованиям и надо сказать, вопросы по многопоточности в связке с С++ на них стали появляться. Очень редко по сравнению с количеством вопросов по сортировке гномиков и прочей ересью, но тем не менее за этот год я столкнулся аж с 2 вопросами из этой области в компаниях, которые активно используют C++11 и выше. Что удивительно, некоторые до сих пор сидят на С++98, а то и на вообще Си-с-классами.
Continue reading →

Haskell – это прекрасно, но…

Правда, я не понимаю как я мог заниматься разработкой в течении 18 лет и не удосужиться прочитать хотя бы одной книги по Haskell и даже не написать простенького “Hello world!” на этом изумительном языке. Наверное, меня всё время так или иначе отпугивали разные слухи и истории на тему того, какой это дико сложный и непойми-нахрена-нужный язык. Не иначе!

К счастью у меня, с одной стороны, нашлось довольно большое количество свободного времени для изучения чего-то совершенно не нужного в повседневной работе, а с другой стороны, мне посоветовали несколько книг по Haskell в рамках внезапно разросшейся дискуссии об этом языке на Facebook и пусть ни одна из них мне не подошла, но начало было положено. Проблема с книгами собственно в том, что имея за плечами изрядный опыт программирования, большинство из них выглядят невероятно скучными. Ну зачем долго и в мельчайших деталях обсуждать что такое let или сопоставление с образцом? Ясно же, что Haskell не будет для кого-то первым языком и у читателя уже есть что-то за плечами для того, что бы провести аналогии и понять о чем идет речь с полуслова. К моей радости я наткнулся на What I wish I Knew, которая отвечает на изрядное количество прикладных вопросов относительно языка и наиболее распространенных паттернов использования и мне где-то я разыскал рекомендацию Get Programming with Haskell в которой кратко и по делу рассматривают основные концепции языка. Сначала мне эта книга сильно не понравилась, но оказалось что нужно просто пропустить/пролистать первые две главы и всё будет просто великолепно. Continue reading →

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…