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

Активные объекты в 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

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

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

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

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

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

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

Информативная обработка ошибок в Go

Концепт обработки ошибок в Go довольно интересен в первую очередь тем, что ошибка в Go это просто произвольный объект поддерживающий интерфейс с функцией Error() string. Подобный подход превращает ошибку в некий гибрид Boolean с текстовым описанием и изрядная часть кодовой базы Go проектов выглядит так:

func foo(val int) error {
    if val == 42 {
        return fmt.Errorf("42 is not allowed")
    }
    // normal workflow
    return nil
}
...
err := foo(1)
if err != nil {
// do some error handling
}
// normal workflow

Continue reading