kubukoz

import $ivy.`org.typelevel::cats-effect:3.2.9`

import cats.effect._

object Main extends IOApp.Simple {
  def run: IO[Unit] = IO.println("hello Nix!")
}

kubukoz

You mention that you would only use circe auto derivation in only a few limited cases - may I ask why? It looks like you are using semi-auto derivation instead. Why is this better/more stable?

The difference is where the derivation happens - in semiauto, you only have one place where a codec for a given type will be derived: at definition site, which is usually the companion object (it's the companion object in our case, but it could be anywhere really - point still stands that it's easier to track). In auto derivation, codecs are derived as needed by the usage - e.g. in the endpoint definitions or in a controller (depending on the tech stack you use). The problem here is that you need all the codecs of all the fields and all their fields (...and so on...) to be available there.

The centralization of the codecs in Semiauto mode allows us to switch to a different format at any time, while keeping the representation consistent across all usages of it. Additionally, it allows us to test the codec logic witho

kubukoz

Why you prefer cats instead of zio? TF? It’s looks like zio ecosystem more widely and zio 2.0 has better performance What do you think?

Great question!

Performance-wise, it really depends on what you're doing. The problem with benchmarks (including the ones posted for ZIO and Cats Effect) is that they apply only to abstract situations, which are often nothing like what you see in real applications. A great write-up on this problem by Daniel Spiewak here, he wrote it better than I ever could: https://gist.github.com/djspiewak/f4cfc08e0827088f17032e0e9099d292

Also, this is not an app meant for production - I don't care that much about performance under load because there will be no load. And individual operations will often be bounded by I/O anyway, so the efficiency of the underlying runtime is likely not going to make a noticeable difference in use. Then again, both the client and server are JVM apps, so even the start-up penalty of the client will slow us down than picking even the least efficient e

kubukoz

def demo = {
  def foo(a: Int, b: Int) = s"foo(a = $a, b = $b)"

  val a = 42
  val b = 50

  Macros.named(foo(b, a))
}

kubukoz

 import shapeless._

  import shapeless.ops.tuple._

  trait ReplaceFirstInTuple[Head, Replacement, Tup, TupReplaced] {
    def replace(ik: Tup, j: Replacement): TupReplaced
    def first(ik: Tup): Head
  }

  object ReplaceFirstInTuple {

kubukoz

import scala.deriving.*
import scala.compiletime.*

trait Show[T]:
  extension (t: T) def show: String

given Show[String] = s => s
given Show[Int] = _.toString

object Show:

kubukoz

// This could be very useful for https://github.com/kubukoz/datas/blob/2d7ba9d1b4974bc03500c556279152ce441226ea/core/src/main/scala/datas/tagless.scala


trait TraverseK[Alg[_[_]]]:

  def traverseK[F[_], G[_]: Applicative, H[_]](alg: Alg[F])(fk: F ~> ([a] =>> G[H[a]])): G[Alg[H]]

  def sequenceK[F[_]: Applicative, G[_]](alg: Alg[[a] =>> F[G[a]]]): F[Alg[G]] =
    traverseK(alg)(FunctionK.id)

kubukoz

import scala.deriving.*
import scala.compiletime.*

inline def valuesOf[T <: Tuple]: List[String] = inline erasedValue[T] match {
  case _: EmptyTuple => Nil
  case _: (h *: t)   =>
    erasedValue[h] match {
      case label: String =>
        label :: valuesOf[t]
    }

kubukoz

trait Labels[S] {
  def label(v: S): String
}

object Labels {
  import scala.deriving.*
  import scala.compiletime.*

  inline def derived[T](using s: Mirror.SumOf[T]): Labels[T] =

kubukoz

trait ConsoleDsl {
  // callers will never know what this is, and that's a good thing
  type A

  def println(s: String): A
  def readLn: A

  def combine(a: A, b: A): A
}