TonioGela

//> using scala "3.2.1"
//> using lib "com.monovore::decline-effect::2.4.1"
//> using lib "co.fs2::fs2-io::3.4.0"
//> using packaging.output "mkString"
//> using platform "scala-native"
//> using nativeMode "release-fast"
//> using nativeGc "none"

import cats.effect.*
import cats.effect.std.*

Daenyth

"Monad" is a word that describes a set of behaviors

In scala, we use the Monad[Foo] typeclass from cats to define instances of this behavior.

The essence of its behavior is the ability to describe a series of computations, where one computation depends on the result of the computation that came before it.

For example, Monad[Option] shows that the Option[A] data type can be used to describe computations of A which may result in no value.

djspiewak

Understanding Comparative Benchmarks

I'm going to do something that I don't normally do, which is to say I'm going to talk about comparative benchmarks. In general, I try to confine performance discussion to absolute metrics as much as possible, or comparisons to other well-defined neutral reference points. This is precisely why Cats Effect's readme mentions a comparison to a fixed thread pool, rather doing comparisons with other asynchronous runtimes like Akka or ZIO. Comparisons in general devolve very quickly into emotional marketing.

But, just once, today we're going to talk about the emotional marketing. In particular, we're going to look at Cats Effect 3 and ZIO 2. Now, for context, as of this writing ZIO 2 has released their first milestone; they have not released a final 2.0 version. This implies straight off the bat that we're comparing apples to oranges a bit, since Cats Effect 3 has been out and in production for months. However, there has been a post going around which cites various compar

TimWSpence

import cats.implicits._
import cats.effect.{Blocker, IO, IOApp, ExitCode}
import java.util.concurrent.Executors

object Test extends IOApp {
  override def run(args: List[String]): IO[ExitCode] = {
    val blocker = Blocker.liftExecutorService(Executors.newCachedThreadPool())
    blocker.blockOn(
      for {
        _ <- printThread

djspiewak

Fibers

Fibers are an abstraction over sequential computation, similar to threads but at a higher level. There are two ways to think about this model: by example, and abstractly from first principles. We'll start with the example.

(credit here is very much due to Fabio Labella, who's incredible Scala World talk describes these ideas far better than I can)

Callback Sequentialization

Consider the following three functions

Daenyth

Parallels between map and similar functions

map          :: F[A] => (A =>     B)   => F[B]
flatMap      :: F[A] => (A =>   F[B])  => F[B]
traverse     :: G[A] => (A =>   F[B])  => F[G[B]]
flatTraverse :: G[A] => (A => F[G[B]]) => F[G[B]]
traverse_    :: F[A] => (A =>   F[B])  => F[Unit]

Daenyth

Concurrent resource caching for cats

Motivation

cats-effect Resource is extremely handy for managing the lifecycle of stateful resources, for example database or queue connections. It gives a main interface of:

trait Resource[F[_], A] {
  /** - Acquire resource
    * - Run f
 * - guarantee that if acquire ran, release will run, even if `use` is cancelled or `f` fails

kalpeshsingh

#!/bin/sh

branch="$(git rev-parse --abbrev-ref HEAD)"

# get computer name to append in Chime message
username=$USER

# a branch name where you want to prevent git push. In this case, it's "master"
if [ "$branch" = "master" ]; then
  echo "You can't commit directly to '"${branch}"' branch" # webstorm or intellij will show this as popup

Daenyth

The problem

I have some data which has adjacent entries that I want to group together and perform actions on. I know roughly that fs2.Pull can be used to "step" through a stream and do more complicated logic than the built in combinators allow. I don't know how to write one though!

In the end we should have something like

def combineAdjacent[F[_], A](
 shouldCombine: (A, A) => Boolean,

djspiewak

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