С написанием рингбуффера история такая, что у меня сейчас для котлин библиотек нет репозитория никакого.
Можно написать это в какой-нибудь util и потом когда-нибудь вынести в отдельную репу и публиковать ее в свой артифактори, чтобы потом реюзать, да?

Мне просто не нравится писать собственные утилиты, вот и все

Вы предлагаете мне решать проблему с производительностью на листе из 5 элементов, написав свой рингбуффер и нагадив в код проекта лишними классами - как бы красиво они не выглядели.
Как по мне это и есть yagni

Извините канешно. Ну если бы была какая-то библиотека в интернете с этим рингбуффером, я был бы щаслив

Тянуть библиотеку ради одного класса = ок, написать класс самому = не ок? Ничего не попутали?

Ладно, бессмысленный спор, не буду продолжать, пользы никакой не принесет.

Конечно не попутал.
Свой код мне надо поддерживать,а код библиотеки не надо. Вот и все.

Ну это уже действительно вкусовщина.

Вот какой-то пример из apache - https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/queue/CircularFifoQueue.html

Спасибо больше. Извините, что я развел срач вместо того, чтобы пойти и загуглить самому.

Позвольте поинтересоваться, а в чём заключается будущая поддержка рингбуффера? Мне казалось, достаточно скопипастить себе реализацию (процентов на 90 уверен, что можно найти готовый или почти готовый гист), подточить при надобности напильником, написать тесты и забыть о ней как о страшном сне.

Я не то, чтобы топлю за этот вариант, просто конкретный тезис смутил.

С заказчиками обсуждать будут перспективы наращивания функциональности

Тут вопрос чисто идеологический.
Если для вас нормальная практика копипастить гисты в свои репозитории - дело ваше.

Ну, если готовая библиотека не нашлась, и при этом оно покрыто тестами и работает -- почему бы и нет.

Впрочем, раз вы нашли библиотеку, вопрос, очевидно, снят.

1. Можно явно использовать джавовую реализацию если не нужна multiplatform (а она сама expirimental если что), и тогда не нужно будет использовать "очень страшный" @ExperimentalStdlibApi -- лучший вариант
2. Возможно тут подойдет Channel(5) из корутин (мало-ли, мы же саму проблему не знаем) -- возможный вариант
3. Есть pcollections если действительно нужны персистентные коллекции -- странный, как и тащить arrow и прочие огромные либы которые решают совсем другие проблемы

ringbuffer (тот же LMAX disruptor), который советуют, решает задачу параллельного, быстрого записи/чтения множественными тредами, но он совсем не подходит чтобы держать постоянно заполненый буффер из N элементов

Привет всем, наткнулся на группу, есть желание посвятить свою жизнь разработке, с чего начать посоветуйте?)

С онлайн курсов

и @kotlin_start