In Scala implicit parameters are everywhere, starting from the infamous
ExecutionContext that is needed to execute any
However as soon as you require 2 implicit instances of the same type in a function, you compilation fails and you have to make one of them non-implicit. And it works, you can still pass the parameter explicitly where it’s needed but you miss the point of not having to add extra parameter to the function call.
Let me walk you through an example and to make it something useful, let’s try to fix the useless stack traces that one might get when using async code.
Continue reading “Getting rid of implicit parameters”
unapply method is often left unconsidered although it presents an elegant way to solve some specific problems.
The situation we’re going to look at in this article is when we need to add constructors (that can possibly failed to a class).
First let’s take a concrete example with a simple value class:
Continue reading “The case for unapply”
final case class Id(value: Int) extends AnyVal
This blog is a follow up from the previous one and builds up on our small effect experiment. As good as our abstraction goes it still wraps a plain Scala
Future which is eager. Meaning that as soon as you create a
Future it starts executing on the provided
Our effect wrapper
F suffers the exact same issue as it just wraps a
final case class F[+E, +A](value: Future[Either[E, A]]) extends AnyVal
Why is that a problem? Simply because it makes it harder to reason about the code.
Continue reading “A lazy future”
If you’ve used Scala Future in a real application you probably realised that having a failed
Future wrapping any
Throwable isn’t the most efficient way to handle errors in your application.
I used Scala Future in this example but it applies equally to cats effects. Any type like
IO[A] suffers the same issue in that regard as it doesn’t provide an error channel other than
It’s basically the same issue as the undocumented Java
Continue reading “The problem with EitherT”
RuntimeException. The only way to know what exceptions are thrown is to look at the implementation (when it’s possible).
After an overview of cats-effect which deals with single effect it feels natural to have a look at fs2 and see how multiple effects can be combined into a stream.
As we’ve covered some common streaming patterns with Akka stream a while ago it’ll be interesting to see how they compare with each other.
Continue reading “Streaming patterns with fs2”
After many applications written using Scala’s Futures, Akka Actors or Monix,… Cats-effect is now my favourite stack to write Scala programs. Why is that?
Well, it makes your code easier to write and reason about while providing good performances.
As a programmer we don’t really like to deal with errors. We like to focus on the happy path – the one that provides value – and deal with the errors later because … well, we have to do it!
However dealing with failures is crucial if we don’t want our program to stop on the first error it encounters.
But still we don’t want to mix the “clean” code of the happy path with the “dirty” error handling code. And in fact this is what exceptions were suppose to bring: A clean happy path in a
try statement and the error handling code in a
catch statement. You know everything clean and separated.
In Scala we have a rich type-system which gives us more options to handle errors. But before we start let’s be clear by what we mean by errors. Continue reading “Dealing with errors”
We all know we should write tests to make sure our system behaves as it is supposed to.
Surely tests are necessary to ensure correctness of our programs but they only depend on what the programmer is willing to test (or can think of testing).
What I mean is that there will always be gaps in the test coverage, like uncovered corner cases or improbable combinations of events, …
In Scala we have a powerful type system that we can use to help us avoid some mistakes.
Why would you bother writing a test to make sure a function handle some corner cases correctly when you can use the type system to make sure such cases won’t ever happen. Continue reading “Leveraging the type system to avoid mistakes”
A load-balancing strategy is a strategy allowing to spread the load (e.g. HTTP requests) over a fleet of instances providing some functionality. If you’re like me you probably think of a sort of load-balancer (e.g. Nginx, AWS ELB, …) in front of several nodes (e.g. EC2 instances, docker containers, …). This is, indeed, a very common pattern but there are other alternatives with different pros and cons. Continue reading “Load-Balancing strategies”
Grpc-akkastream, the akka-stream implementation built on top of GRPC looks good on the surface but if you look under the hood there is one problem: it doesn’t provide any support for back-pressure.
Akka-streams (as any reactive-stream implementation) provides a way for back-pressure and GRPC (at least the Java version) also has an API that support back-pressure. Let’s see how we can wire everything together and provide a truly reactive akka-stream implementation for GRPC! Continue reading “Back-pressure in Grpc-akkastream”