толсто

И стейки едят вместо папыджонса

Вот это неплохо было. Больно так, жизненно

Пытаюсь от circe.generic.auto._ перейти на @ConfiguredJsonCodec
1. действительно ли стоит?
2. это же то же самое что derivedDecoder?
3. как вернее всего понять, куда еще надо добавить @Configured, а то sbt compile показывает проблему только в верхнем кейз-классе, а в каждый кейз используемый в нем - нужно заходить

@iOgre

1. да
2. deriveConfigured{Encoder|Decoder} из circe extras пакета
3. все вложения должны иметь кодеки, для configured тебе надо что бы конфигурация была в скоупе; если ее нет - будут проблемы (ну раньше, по крайней мере, так было; если что не поменялось в новых релизах)

да, я понял что если у меня case class A(x:CaseClassX, y:CaseClassY), то нужно чтобы кодек был и у CaseClassX, и у CaseClassY и далее, рекурсивно

это не совсем часть языка
синтаксически в языке ничего не изменилось, но в компилятор добавили возможности, позволяющие библиотекам вроде scala-async делать более эффективные преобразования деревьев, чем раньше делались на макросах

это же расширение может позволить и для любых других монадоподобных типов написать похожие синтаксические преобразования

Там какой-то общий механизм появился? Мне казалось что новую фазу добавили исключительно для async

Вот тут пример врайтера

Можете попробовать derevo и магнолиевые декодеры/енкодеры из derevo.circe.magnolia, так будет подсказывать, у каких классов нет кодеков

Сам синкасис противный, а не семантика. Ключевой поинт что это "понятнее" в корне не верен. Почему функции это непонятно, а вкрюченный прибитый гвоздями синтаксис async await никак напрямую не связанный с объектом это дохрена сразу понятно?

Нет

То есть в самом макро помечается нужное определение и предоставляется реализация StateMachine, которую потом будет разворачивать отдельная фаза?

Значит для своих монадок придётся дописывать отдельно

зато сразу видна императивная суть монад

Я согласен на -100%. Т.е. с точностью до наоборот.
Синтаксис соответствует расширениям вроде !-notation в идрис.
Т.е. вместо того, чтобы именовать каждый промежуточный результат в вашей процедуре, как вы это делаете в do\for,  вы можете писать сложные выражения вроде, т.е. вместо

  reserved <- reservedAmount
  items <- readItems
  itemsTotal = items.map(_.value).sum
  available <- availableAmount
  result = available - (reserved + itemsTotal)

и

result <- (readItems, availableAmount, items)
           .mapN{ (reserved, available, itemsTotal) => available - (reserved + itemsTotal)}

вы пишете

val result = !availableAmount - (!resevedAmount + (!readItems).map(_.value).sum )

или то же самое

val result = async(availableAmount) - (async(reservedAmount) + async(readItems).map(_.value).sum)

Как раз наличие такого синтаксиса я вижу только в положительном свете, а вот то, что он всегда транслируется в какую-то мутабельную стейтмашину - не очень

Ну она и так видна, а вот то, что в текущем синтаксисе нельзя субвыражения композить нормально вызывает у меня флешбеки от разработки на ЯП, у которых в 2010-м нельзя было

  reserved <- reservedAmount
  items <- readItems
  itemsTotal = items.map(_.value).sum
  available <- availableAmount
  result = available - (reserved + itemsTotal)

и

result <- (readItems, availableAmount, items)
           .mapN{ (reserved, available, itemsTotal) => available - (reserved + itemsTotal)}

val result = !availableAmount - (!resevedAmount + (!readItems).map(_.value).sum )

val result = async(availableAmount) - (async(reservedAmount) + async(readItems).map(_.value).sum)

Первый вариант лучше

совет конечно :/ как ток он отвечает на вопрос