Returning to Rust: A Journey Through Tooling, Performance

When I started tackling the Maelstrom challenges, my initial thought was to use C++. It’s a language I know inside out, and its performance is hard to beat. However, as I contemplated setting up the project, I realized I couldn’t justify fighting with the C++ pipeline for free. Crafting a proper CMake or Bazel configuration might be worthwhile for large-scale projects or when compensated, but for personal experiments? It’s an unnecessary headache.

Why Go is My Default Choice

For most non-performance critical scenarios, Go is my default, no-brainer choice. It has a clean build system, excellent tooling, and a developer experience that doesn’t make me dread the setup process. Go’s simplicity allows me (and any level team) to focus on solving the problem rather than wrestling with the environment. Yet, this time, I decided to take a different path.
Continue reading

Minimal CI for Go library with GitHub actions

Continuous Integration (CI) has become an essential part of modern software development, and for good reason. It ensures code quality, speeds up development, and catches potential issues early. However, you can get started without an elaborate CI setup. Even a minimal CI setup can significantly improve your workflow. Here’s why every project should have at least minimal CI and how to implement it effectively using GitHub Actions.

What Constitutes Minimal CI?

For a project to benefit from CI without excessive complexity, it should include the following essential components:

1. Project Compilation: Verify that the codebase is always in a buildable state.
2. Unit Test Execution: Ensure the core functionality works as expected.
3. Static Code Analysis: Catch bugs and enforce coding standards before they become an issue.

Continue reading

GFSM: A Simple and Fast Finite State Machine for Go

Design patterns are not widely used in Go, as they can often lead to unnecessary complexity in the codebase. However, the Finite State Machine (FSM) is an exception that proves to be incredibly useful. When I set out to design GFSM, I aimed to create a fast and straightforward FSM implementation for Go.

I initially sought a quick and straightforward FSM solution for Go, but I couldn’t find anything that met my needs. Drawing inspiration from the speed-focused and minimalistic principles of C++ while remaining true to Go’s idioms, I developed GFSM to fill this gap. The outcome is GFSM—a library that distinguishes itself from alternatives like looplab/fsm by prioritizing speed and simplicity.

Whether orchestrating microservices, handling distributed systems, or designing embedded systems, GFSM brings the reliability and efficiency needed to keep things running smoothly.

Real-World Use Case: Two-Phase Commit Protocol

One of the best showcases for FSMs is the Two-Phase Commit protocol (TPC), widely used in distributed systems to ensure atomic transactions. Let’s explore how GFSM can model this protocol step by step.

Continue reading

Форумы умерли, да здравствует 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

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

Два года с Go

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

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

Continue reading

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

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

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

Начнем с самого важного: при каких условиях этот язык скорее вреден.
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