Albert Serrallé Ríos aserrallerios

type checking requires testing the equivalence of runtime expressions

Quick prerequisite here: testing the equivalence of runtime expressions is, in general, undecidable for languages with straightforward recursion. (see: eq(PDA)) Thus, for Scala to be a dependently-typed language, we must clarify an ambiguity in this definition:

type checking requires testing the pessimistic equivalence of runtime expressions

Which is to say, the type checker will attempt to check the equivalence of runtime expressions, and in the cases where it fails, it will assume not-equal. In order to prevent this definition from being completely vacuous, let's further assume that there must exist at least one case (perhaps trivial) where the compiler is able to perform this runtime equivalence checking, and thus its equality check produces True.

Scala's rules in this area are more pessimistic than perhaps they could be, but they do still apply. Specifically, the following two rules are in play:

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

Generalized Algebraic Data Types in Scala

Basic GADTs

Here's an ADT which is not a GADT, in Haskell:

data Expr = IntExpr Int | BoolExpr Bool

Generating Flame Graphs for Apache Spark

Flame graphs are a nifty debugging tool to determine where CPU time is being spent. Using the Java Flight recorder, you can do this for Java processes without adding significant runtime overhead.

When are flame graphs useful?

Shivaram Venkataraman and I have found these flame recordings to be useful for diagnosing coarse-grained performance problems. We started using them at the suggestion of Josh Rosen, who quickly made one for the Spark scheduler when we were talking to him about why the scheduler caps out at a throughput of a few thousand tasks per second. Josh generated a graph similar to the one below, which illustrates that a significant amount of time is spent in serialization (if you click in the top right hand corner and search for "serialize", you can see that 78.6% of the sampled CPU time was spent in serialization). We used this insight to spee

Explaining Miles's Magic

Miles Sabin recently opened a pull request fixing the infamous SI-2712. First off, this is remarkable and, if merged, will make everyone's life enormously easier. This is a bug that a lot of people hit often without even realizing it, and they just assume that either they did something wrong or the compiler is broken in some weird way. It is especially common for users of scalaz or cats.

But that's not what I wanted to write about. What I want to write about is the exact semantics of Miles's fix, because it does impose some very specific assumptions about the way that type constructors work, and understanding those assumptions is the key to getting the most of it his fix.

For starters, here is the sort of thing that SI-2712 affects:

def foo[F[_], A](fa: F[A]): String = fa.toString

From zero to microservice with 𝚫 now

The following guide will show you how to deploy a simple microservice written in JavaScript using 𝚫 now.

It uses Open Source tools that are widely available, tested and understood:

Node.JS
NPM
Express

Scalawags #38: The Sound of Dotty

YouTube link: https://www.youtube.com/watch?v=e687bFp2FT4

Our guest is Martin Odersky, the creator of Scala. We invited him on specifically to discuss Dotty, a new compiler for Scala.

Your hosts this episode: Josh Suereth,

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

Clarify and agree on the scope of the system

User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?

	package beala

	import dogs._

	object Beala {

	// ironically dogs doesn't support unsafe operations by default,
	// so we have to build them ourselves (since we know our stream
	// is infinite and will always have elements).
	def head[A](as: Streaming[A]): A =

	trait NotSubTypeOf[A, B] // encoding to capture A is not a subtype of B
	// Note: We can use infix notation to write `A NotSubTypeOf B` instead of `NotSubTypeOf[A, B]`

	// evidence for any two arbitrary types A and B, A is not a subtype of B
	implicit def isSub[A, B]: A NotSubTypeOf B = null

	// define ambigous implicits to trigger compile error in case A is a subtype of B (or A =:= B)
	implicit def iSubAmbig1[A, B >: A]: A NotSubTypeOf B = null
	implicit def iSubAmbig2[A, B >: A]: A NotSubTypeOf B = null