Picking the right architecture = Picking the right battles + Managing trade-offs
These are the Kickstarter Engineering and Data role definitions for both teams.
| # [dependencies] | |
| # polars = { version = "0.38.3", features = ["lazy"] } | |
| use polars::lazy::prelude::*; | |
| use polars::prelude::*; | |
| fn analyze_sorting_behavior(sorted_df: &DataFrame) -> Result<(), String> { | |
| let index_col = sorted_df.column("index").map_err(|e| e.to_string())?.i64().unwrap(); | |
| let a_col = sorted_df.column("a").map_err(|e| e.to_string())?.i64().unwrap(); |
| object Foo { | |
| // based on this scalaz version: https://gist.github.com/Fristi/e7139a89e2c66d455e97 | |
| implicit def applicativeFuture(implicit executionContext: ExecutionContext) | |
| = new Applicative[Future] { | |
| override def pure[A](x: A): Future[A] = Future.successful(x) | |
| override def ap[A, B](ff: Future[(A) => B])(fa: Future[A]): Future[B] = | |
| ff.flatMap(fa.map(_)) |
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
#The Problem We just described standard design issues you have when you start creating layers of services, DAOs and other components to implement an application. That blog/gist is here.
The goal is to think through some designs in order to develop something useful for an application.
#Working through Layers If you compose services and DAOs the normal way, you typically get imperative style objects. For example, imagine the following:
object DomainObjects {
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