2023 подписчика

✏️ Потоковая обработка на go1.18

2 июля 20222 июл 2022

2 мин

✏️ Потоковая обработка на go1.18 В версии 1.18 языка Go появились генерики, дающие возможность писать обобщенный код, то есть код, не зависящий от конкретного типа данных. Например можно написать код, обрабатывающий потоки данных - применить к ним одну и ту же функцию, отфильтровать, просуммировать и т.д., не завязываясь на конкретные типы данных. Так как я вижу потенциал в парадигме поточной обработки с помощью итераторов/стримов и теперь есть возможность реализовать ее в Go, я решил сделать это. Эта идея появилась у меня после данной публикации. В ней рассказывается о библиотеке для языка Go для обработки данных с использованием генериков. Я попробовал эту библиотеку в своем проекте и столкнулся с следующими недостатками: настойчивое использование IO[A], который по сути представляет собой func()(A,error) то есть любую функцию, которая может вернуть ошибку. При написании кода это создает неудобства, потому что нужно всё заворачивать в этот IO и код превращается в жонглирование io.Map

В версии 1.18 языка Go появились генерики, дающие возможность писать обобщенный код, то есть код, не зависящий от конкретного типа данных. Например можно написать код, обрабатывающий потоки данных - применить к ним одну и ту же функцию, отфильтровать, просуммировать и т.д., не завязываясь на конкретные типы данных. Так как я вижу потенциал в парадигме поточной обработки с помощью итераторов/стримов и теперь есть возможность реализовать ее в Go, я решил сделать это.

Эта идея появилась у меня после данной публикации. В ней рассказывается о библиотеке для языка Go для обработки данных с использованием генериков. Я попробовал эту библиотеку в своем проекте и столкнулся с следующими недостатками:

настойчивое использование IO[A], который по сути представляет собой func()(A,error) то есть любую функцию, которая может вернуть ошибку. При написании кода это создает неудобства, потому что нужно всё заворачивать в этот IO и код превращается в жонглирование io.Map и io.FlatMap. Видимо это вдохновлено библиотеками с чисто функциональным подходом. Сделано это было, чтобы была функциональная чистота, что в итоге не очень (как по мне) ложится на процедурность языка Go.

Stream[A] это обертка над стейт-машиной. Стейт-машина в данном случае это структура, в которой либо ничего нет (конец потока), либо значение и продолжение (следующее состояние) машины. В итоге это создает две проблемы. Первая: чтобы создать стрим, нужно создать его продолжение, продолжение продолжения и тд. Единственный адекватный способ этим пользоваться, который я нашел - это рекурсия. Вкупе с отсутствием Tail call optimization это приводит к второй проблеме.

Работа с стримами переполняет стек. Модель потока как стейт-машины была построена так, что переход к новому состоянию - вызов функции. Поэтому, чтобы обойти стрим целиком, надо уйти в рекурсию на глубину, равную длине потока.

Построение типа Either[A,B]. По моему скромному мнению, это вообще тип, которого не хватает в Go и который разумно реализован в языке Rust. В библиотеке этот тип это структура, содержащая и элемент типа A и элемент типа B . Плюс булевое поле как способ идентификации какой из полей действителен на самом деле. Важно то, что по сути тип Either[A,B], семантика которого элемент типа A ИЛИ B, представляется в языке как пара из элемента типа A И элемента типа B.

Не совсем очевидный интерфейс. Хотя это скорее я не до конца разобрался, что и почему. Так или иначе, я считаю, что построил интерфейс более простой и прямолинейный, не потеряв в общности.

@Golang_google