Skip to content

Instantly share code, notes, and snippets.

Working or IDK

Albert Serrallé Ríos aserrallerios

Working or IDK
Block or report user

Report or block aserrallerios

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
non / sizes.txt
Last active Oct 16, 2019
Size of various JVM data structures in bytes (top column is number of elements).
View sizes.txt
COLLECTION 0 1 5 10 50 100 500 1000
Array[Int] 16 24 40 56 216 416 2016 4016
immutable.BitSet 24 24 24 24 24 32 96 160
immutable.IntMap[Int] 16 40 328 688 3568 7168 35968 71968
immutable.List[Int] 16 56 216 416 2016 4016 20016 40016
immutable.Map[Int,Int] 16 40 304 720 4856 9680 53504 111760
immutable.Queue[Int] 40 80 240 440 2040 4040 20040 40040
immutable.Set[Int] 16 32 264 480 3016 5840 27696 57952
immutable.SortedMap[Int,Int] 40 88 280 520 2440 4840 30008 62008
immutable.SortedSet[Int] 40 104 296 536 2456
gvolpe /
Last active Oct 12, 2019
Shared State in pure Functional Programming

Shared State in pure Functional Programming

Newcomers to Functional Programming are often very confused about the proper way to share state without breaking purity and end up having a mix of pure and impure code that defeats the purpose of having pure FP code in the first place.

Reason why I decided to write up a beginner friendly guide :)

Use Case

We have a program that runs three computations at the same time and updates the internal state to keep track of the

non /
Last active Dec 2, 2019
Simple example of using seeds with ScalaCheck for deterministic property-based testing.


ScalaCheck 1.14.0 was just released with support for deterministic testing using seeds. Some folks have asked for examples, so I wanted to produce a Gist to help people use this feature.

simple example

These examples will assume the following imports:


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


Principled Meta Programming for Scala

This note outlines a principled way to meta-programming in Scala. It tries to combine the best ideas from LMS and Scala macros in a minimalistic design.

  • LMS: Types matter. Inputs, outputs and transformations should all be statically typed.

  • Macros: Quotations are ultimately more easy to deal with than implicit-based type-lifting

  • LMS: Some of the most interesting and powerful applications of meta-programming

jdegoes / AsyncToIO.scala
Last active Nov 11, 2017
A sketch of an `Async ~> IO`
View AsyncToIO.scala
val AsyncToIO: NaturalTransformation[Async, IO] {
def apply[A](fa: Async[A]): IO[A] = {
for {
ref <- newIORef[Either[Throwable, A]](Left(new Error("No value")))
counter <- IO(new java.util.concurrent.CountDownLatch(1))
_ <- fa.register(v => ref.set(v).flatMap(_ => IO(counter.countDown()))
_ <- IO(counter.await())
v <- ref.get
a <- v match {
case Left(e) =>

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.

non /
Last active Feb 2, 2019
I feel like conversations around laws and lawfulness in Scala are often not productive, due to a lack of rigor involved. I wanted to try to be as clear and specific as possible about my views of lawful (and unlawful) behavior, and what I consider a correct and rigorous way to think about laws (and their limits) in Scala.


A law is a group of two or more expressions which are required to be the same. The expressions will usually involve one or more typed holes ("inputs") which vary.

Some examples:                 === x

How does attempt violate the laws?

The IO scaladoc mentions that the attempt function can be used to violate the functor laws. This seems like an odd claim, especially since one would expect such a violation would be a bug to be fixed! Specifically:

Materializes any sequenced exceptions into value space, where they may be handled. This is analogous to the catch clause in try/catch. Please note that there are some impure implications which arise from observing caught exceptions. It is possible to violate the monad laws (and indeed, the functor laws) by using this function! Uh... don't do that.

So how does this happen exactly? Conspicuously, IO passes the functor laws (as well as all of the other laws) in its unit test suite, so either the functor laws must be under-specified, the scaladoc is wrong, or something very fishy is going on.

The answer is something of a mix of the three. Here is the law (in Haskell syntax) which is violated:

You can’t perform that action at this time.