Вот так сделал:

object liftF {
    trait encoder {
      type Raw
      type Tag <: this.type

      implicit def liftedEncoder(implicit rawEncoder: Encoder[Raw]): Encoder[Raw @@ Tag] = LiftF[Encoder].lift
    }

    trait decoder {
      type Raw
      type Tag <: this.type

      implicit def liftedDecoder(implicit rawDecoder: Decoder[Raw]): Decoder[Raw @@ Tag] = LiftF[Decoder].lift
    }

    trait codec extends encoder with decoder
}

Потом попробую ещё новые ньютайпы заюзать

object liftF {
    trait encoder {
      type Raw
      type Tag <: this.type

      implicit def liftedEncoder(implicit rawEncoder: Encoder[Raw]): Encoder[Raw @@ Tag] = LiftF[Encoder].lift
    }

    trait decoder {
      type Raw
      type Tag <: this.type

      implicit def liftedDecoder(implicit rawDecoder: Decoder[Raw]): Decoder[Raw @@ Tag] = LiftF[Decoder].lift
    }

    trait codec extends encoder with decoder
}

liftedEncoder - лучше заменять на более специфические названия. Например circe_Encoder - это крайне хорошая привычка, иначе есть не малый шанс потом натолкнуться на коллизию имен в одном левел скоупе, а мы знаем, что скала не очень умна в этом плане и даже при не пересекающихся типах отказывается находить имплисит в таком случае)
И  rawEncoder можно смело на однобукву заменять, все равно не используется(это уже просто борьба за разумную чистоту кода 🙂 )

Согласен со всем. Недавно как раз натыкался на очередную проблему с шедоингом имплистов

нету в кассандре никакого дьюрабилити, ёпт

https://github.com/cb372/scalacache/issues/336
если коротко - нет

Там всё хуже, мвхи могут просто корраптиться, вплоть до незапуска нод пока их не грохнешь

ну там всё может корраптиться

чем коррапт мвэх особеннен

Кворум в пяти нодах, все записи с кворумом, чтения с единичкой или с кворумом:
Наблюдались спецэффекты:
- на одной из нод сдохла ссдшка, ноду убрали, добавили новую, перебалансировали, несколько успешных записей сделанных во время процесса (которые с кворумом) куда-то рассосалась. Количество - три штуки на сто тыщ

он случается гарантированно и после него может быть нужно переналить ноду

поведение 2: добавляли колонку в таблицу, куда шли записи, сеть моргнула, часть сделанных с кворумом успешных записей проебалась, процентов 20

при этом мне очень нравится кассандра - она простая, богатая на фичи, мне, мартыхану, само то

Причину нашли? Вообще "успешная запись в кассандре" не гарантирует успешную запись. Он по-моему в память пишет и время от времени сливает на диск. Если записать хоть во все ноды успешно, а потом они все умрут раньше чем данные слились, вы всё потеряете. Фокус в том чтобы достигнуть такой надёжности кластера чтобы такого никогда не случалось.

У них в багтрекере миллион багов на тему изменения схемы под нагрузкой

Одна нода сдохла, одна

Не меняйте схему под нагрузкой? Создавайте новую таблицу, переливайте туда данные, и потом старую удаляйте?

Можно ещё в жопу хвост вставить и потанцевать на столике. А можно не идеализировать инструмент

А кто тут идеализирует? Я как раз говорю что не надо отвёрткой гвозди забивать. Но говорить о том что Кассандра ненадёжная и данные теряет - неправильно. Ещё какая надёжная.

@odomontois : Вы фаундейшен гоняли? У меня клиент ссытся фаундейшена - типа "непроверенное временем решение"