| //> using scala "3" | |
| import scala.compiletime.{erasedValue, summonInline, constValue, error} | |
| import scala.deriving.Mirror | |
| import scala.collection.Factory | |
| import scala.annotation.implicitNotFound | |
| import scala.util.NotGiven | |
| import Field.TypeForLabel | |
| infix type =:!=[A, B] = NotGiven[A =:= B] |
Daniel Ciocîrlan recently published a video showcasing a dependency-injection (DI) approach developed by Martin Odersky that uses Scala's implicit resolution to wire dependencies automatically. (See also his reddit post.)
The basic pattern for defining services in Odersky's approach is as follows:
class Service(using Provider[(Dep1, Dep2, Dep3)])
| runner.dialect = scala3 | |
| runner.dialectOverride.allowSignificantIndentation = false | |
| # allows `if x then y` | |
| runner.dialectOverride.allowQuietSyntax = true |
| wasm | js | wasm / js | |
|---|---|---|---|
| sha512 | 12368.78034 | 69356.554 | 0.1783361431 |
| sha512int | 12078.89027 | 18342.09272 | 0.6585339229 |
| queens | 3.299606497 | 9.262363477 | 0.3562380709 |
| list | 76.06484363 | 142.8739845 | 0.5323911412 |
| richards | 92.35085892 | 130.1592505 | 0.7095220552 |
| cd | 40129.51947 | 62085.45494 | 0.6463594332 |
| gcbench | 111415.1666 | 135005.6104 | 0.8252632331 |
| tracerFloat | 1048.518644 | 1280.901067 | 0.8185789445 |
Generic programming is a discipline that encourages the construction of abstractions and the reuse of software component without loss of efficiency. Subtyping through inheritance can be adversary to this goal because it encourages type erasure, promising that efficiency is maintained thanks to dynamic dispatch. Sadly, this promise gets broken when generic data structures and algorithms depend on more than one generic receiver. In those instances, one must resort to generic parameters to preserve type information, introducing expensive annotation costs. This short article examine this problem and then discusses how type classes, an alternative approach to practice generic programming, can address many of the issues presented by subtyping through inheritance.
Disclaimer:
| //> using scala "3.3.0" | |
| import scala.util.boundary, boundary.break | |
| object Loops: | |
| type ExitToken = Unit { type Exit } | |
| type ContinueToken = Unit { type Continue } | |
| type Exit = boundary.Label[ExitToken] |
| package app.implicit_constraints | |
| object Bounds1 { | |
| case class Container[A](a: A) | |
| implicit class IntContainerExtensions(container: Container[Int]) { | |
| def addWithExtension(other: Int): Int = container.a + other | |
| } | |
| val intContainer: Container[Int] = Container(5) |
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
| bin/ | |
| # Scala/SBT specific | |
| project/ | |
| target/ | |
| build/ | |
| # Scala-Cli build folder | |
| .scala-build/ |
| import shapeless._, shapeless.ops.hlist._, shapeless.labelled.FieldType | |
| trait Op[A] extends DepFn1[A] | |
| trait LowPriority { | |
| implicit def identity[A]: Op.Aux[A, A] = Op.createInstance(i => i) | |
| } | |
| object Op extends LowPriority { | |
| type Aux[A, OUT0] = Op[A] { type Out = OUT0 } |