Paweł Kaczor pawelkaczor

Every Argument for Static Typing Applies to Typed Errors

Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.

An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.

Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty

Thread Pools

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

CPU-bound
Blocking IO
Non-blocking IO polling

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

Enforcing invariants in Scala datatypes

Scala provides many tools to help us build programs with less runtime errors. Instead of relying on nulls, the recommended practice is to use the Option type. Instead of throwing exceptions, Try and Either types are used for representing potential error scenarios. What’s common with these features is that they’re used for capturing runtime features in the type system, thus lifting the runtime scenario handling to the compilation phase: your program doesn’t compile until you’ve explicitly handled nulls, exceptions, and other runtime features in your code.

In his “Strategic Scala Style” blog post series,

Applied Functional Programming with Scala - Notes

1. Mastering Functions

A function is a mapping from one set, called a domain, to another set, called the codomain. A function associates every element in the domain with exactly one element in the codomain. In Scala, both domain and codomain are types.

val square : Int => Int = x => x * x

	import fs2.{Chunk, Stream, Pull}
	import cats.collections.Heap

	import cats.implicits._

	object SortMerge {
	def sortMerge[F[_], A: Ordering](streams: List[Stream[F, A]]): Stream[F, A] = {
	implicit val ord: cats.Order[Stream.StepLeg[F, A]] =
	new cats.Order[Stream.StepLeg[F, A]] {
	val ordA = implicitly[Ordering[A]]

	sealed trait Expr

	case class Const(d: Double) extends Expr

	case class Var(a: String) extends Expr

	case class Times(l: Expr, r: Expr) extends Expr

	case class Plus(l: Expr, r: Expr) extends Expr

	package docs.akka.persistence.typed

	import scala.concurrent.duration.FiniteDuration

	import akka.actor.typed.ActorRef
	import akka.actor.typed.Behavior
	import akka.actor.typed.scaladsl.Behaviors
	import akka.actor.typed.scaladsl.LoggerOps
	import akka.persistence.typed.PersistenceId
	import akka.persistence.typed.RecoveryCompleted

	package fpmax

	import scala.util.Try
	import scala.io.StdIn.readLine

	object App0 {
	def main: Unit = {
	println("What is your name?")

	val name = readLine()

	package com.softwaremill.akka

	import java.time._

	import akka.actor.ActorSystem
	import akka.stream.ActorMaterializer
	import akka.stream.scaladsl.Source

	import scala.collection.mutable
	import scala.concurrent.Await

	trait OrderedAtLeastOnceDelivery extends AtLeastOnceDelivery {
	type DeliveryId = Long

	private case class Delivery(destination: ActorPath, deliveryIdToMessage: (DeliveryId) => Any)

	private val deliveryQueue = scala.collection.mutable.Queue.empty[Delivery]

	override def deliver(destination: ActorPath)(deliveryIdToMessage: (DeliveryId) => Any): Unit = {
	if (super.numberOfUnconfirmed == 0) {
	super.deliver(destination)(deliveryIdToMessage)