Skip to content

Instantly share code, notes, and snippets.

@dragos
dragos / scala-env.sh
Last active April 3, 2022 20:01
Simple bash functions to manage different Scala versions on the command line
#!/bin/bash -e
# where Scala tarballs are extracted
SCALA_BASE=$HOME/scala
# Usage:
#
# Install:
# . /path/to/scala-env.sh in your bash profile
#
@jdegoes
jdegoes / zio-test.scala
Last active January 6, 2023 14:08
Simple example of testing with ZIO environment
object test {
import scalaz.zio._
type UserID = String
case class UserProfile(name: String)
// The database module:
trait Database {
val database: Database.Service

Quick Tips for Fast Code on the JVM

I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.

This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea

Thread Pools

Thread pools on the JVM should usually be divided into the following three categories:

  1. CPU-bound
  2. Blocking IO
  3. Non-blocking IO polling

Each of these categories has a different optimal configuration and usage pattern.

@eed3si9n
eed3si9n / sbt-plugin-ranking-2017-08-05.md
Last active June 8, 2018 09:15 — forked from xuwei-k/sbt-plugin-ranking-2014-02-25
List of sbt plugins sorted by GitHub stars. This was generated using https://gist.github.com/eed3si9n/ea4ceef0c5e5c07d6e62c87bea029f88, then augmented by hand.
import cats.{Id, Monad, Traverse, ~>}
import scala.concurrent.{Await, Future}
import scala.concurrent.duration.Duration
object TagLess extends App {
case class PurchaseOrderId(value: String)
case class ProductId(value: String)
case class LocationId(value: String)

Why not both?

With the recent announcement of cats-effect, a relevant question from the past resurfaces: why does IO, which is otherwise quite Task-like, not define both or race? To be clear, the type signatures of these functions would be as follows:

object IO {
  def both[A, B](ioa: IO[A], iob: IO[B])(implicit EC: ExecutionContext): IO[(A, B)] = ???
  def race[A, B](ioa: IO[A], iob: IO[B])(implicit EC: ExecutionContext): IO[Either[A, B]] = ???
}
@travisbrown
travisbrown / queens.scala
Last active October 4, 2017 07:38
Aphyr's n-queens solution from Typing the technical interview, but Scala
class Nil
class Cons[X, Xs]
class First[List] { type X }
object First {
type Aux[List, X0] = First[List] { type X = X0 }
implicit val nilFirst: Aux[Nil, Nil] = ???
implicit def consFirst[X0, Xs]: Aux[Cons[X0, Xs], X0] = ???
}
object Playground extends App {
sealed trait IExp
final case class Lit(i: Int) extends IExp
final case class Neg(e: IExp) extends IExp
final case class Add(r: IExp, l: IExp) extends IExp
sealed trait Tree
final case class Leaf(s: String) extends Tree
final case class Node(s: String, ts: List[Tree]) extends Tree

Revisiting Tagless Final Interpreters

Tageless Final interpreters are an alternative to the traditional Algebraic Data Type (and generalized ADT) based implementation of the interpreter pattern. This document presents the Tageless Final approach with Scala, and shows how Dotty with it's recently added implicits functions makes the approach even more appealing. All examples are direct translations of their Haskell version presented in the Typed Tagless Final Interpreters: Lecture Notes (section 2).

The interpreter pattern has recently received a lot of attention in the Scala community. A lot of efforts have been invested in trying to address the biggest shortcomings of ADT/GADT based solutions: extensibility. One can first look at cats' Inject typeclass for an implementation of [Data Type à la Carte](http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesA