djspiewak

[error] (testsJS / Test / fastLinkJS) org.scalajs.linker.frontend.optimizer.OptimizerCore$OptimizeException: The Scala.js optimizer crashed while optimizing constructor cats.effect.unsafe.SchedulerSuite.<init>;V: java.lang.AssertionError: assertion failed: Found Assign in expression position
[error] Methods attempted to inline:
[error] * constructor munit.FunSuite.<init>;V
[error] * munit.internal.MacroCompat$CompileErrorMacro.$init$;V
[error] * munit.FunFixtures.$init$;V
[error] * munit.TestOptionsConversions.$init$;V
[error] * munit.TestTransforms.$init$;V
[error] * munit.SuiteTransforms.$init$;V
[error] * munit.ValueTransforms.$init$;V
[error] * munit.BaseFunSuite.$init$;V

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

djspiewak

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.

djspiewak

Git DMZ Flow

I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.

• Two developers working on independent features must never be blocked by each other
  • No code freeze! Ever! For any reason!
• A developer must be able to base derivative work on another developer's work, without waiting for any third party
• Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
• Developers must be able to work on multiple features simultaneously, or at lea

djspiewak

Where does Cats Effect cancelation become practically unavoidable? I feel like I never really need to think about it.

Timeouts are the easiest practical example to think about. If you contemplate that whole chain, from request handling in the server layer through the fiber which processes that request, making new requests to upstream services, waiting on those results, etc… there's a lot of timeouts involved in that. Any time you have a timeout, you need to recursively cancel everything which rolls up under it, and you need that cancelation to have a few properties:

• It must be irreversible (if you have a timeout, you can't un-timeout; this also implies a degree of determinism)
• It must be respected promptly
• It must backpressure control flow (ensuring that the continuation is not yielded until all finalizers have completed, implying constituent resources are released)
• It must not create invalid states (use after free) or leaks (related to backpressure)

Some of these are actually in mutual confl

djspiewak

org.scalajs.linker.runtime.UndefinedBehaviorError: java.lang.NullPointerException
  at $throwNullPointerException(/Users/daniel/Development/Scala/cats-effect/series-3.6.x/tests/js/target/scala-2.13/cats-effect-tests-test-fastopt/main.js:67:9)
  at $n(/Users/daniel/Development/Scala/cats-effect/series-3.6.x/tests/js/target/scala-2.13/cats-effect-tests-test-fastopt/main.js:71:5)
  at cats.effect.std.MutexSpec.<init>(/Users/daniel/Development/Scala/cats-effect/series-3.6.x/tests/js/target/scala-2.13/cats-effect-tests-test-fastopt/file:/Users/daniel/Development/Scala/cats-effect/series-3.6.x/tests/shared/src/test/scala/cats/effect/std/MutexSpec.scala:30:37)
  at {anonymous}()(/Users/daniel/Development/Scala/cats-effect/series-3.6.x/tests/js/target/scala-2.13/cats-effect-tests-test-fastopt/file:/Users/daniel/Development/Scala/cats-effect/series-3.6.x/tests/shared/src/test/scala/cats/effect/std/MutexSpec.scala:28:13)
  at scala.scalajs.reflect.InvokableConstructor.newInstance(/Users/daniel/Development/Scala/cats-ef

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

djspiewak

Introduction to scalaz-stream

Every application ever written can be viewed as some sort of transformation on data. Data can come from different sources, such as a network or a file or user input or the Large Hadron Collider. It can come from many sources all at once to be merged and aggregated in interesting ways, and it can be produced into many different output sinks, such as a network or files or graphical user interfaces. You might produce your output all at once, as a big data dump at the end of the world (right before your program shuts down), or you might produce it more incrementally. Every application fits into this model.

The scalaz-stream project is an attempt to make it easy to construct, test and scale programs that fit within this model (which is to say, everything). It does this by providing an abstraction around a "stream" of data, which is really just this notion of some number of data being sequentially pulled out of some unspecified data source. On top of this abstraction, sca

djspiewak

java.lang.NullPointerException
java.lang.NullPointerException
java.lang.NullPointerExceptionte 46s
	at java.lang.Throwable.<init>(Throwables.scala:11)
	at java.lang.Exception.<init>(Throwables.scala:383)
java.lang.NullPointerException
	at java.lang.Throwable.<init>(Throwables.scala:11)
java.lang.NullPointerException
	at java.lang.Throwable.<init>(Throwables.scala:11)
	at java.lang.Throwable.<init>(Throwables.scala:11)

djspiewak

diff --git a/core/src/main/scala-3 b/core/src/main/scala-3
deleted file mode 120000
index 609602e..0000000
--- a/core/src/main/scala-3
+++ /dev/null
@@ -1 +0,0 @@
-scala-2.13
\ No newline at end of file
diff --git a/core/src/main/scala/cats/mtl/Handle.scala b/core/src/main/scala/cats/mtl/Handle.scala
index e8bb1f7..e304b58 100644