zio quick read: Extracting the executor for a service

zio quick read: Extracting the executor for a service I had the need to obtain an Executor from the default zio runtime and use it to create a service. Let’s assume you have a def mkMyService ( executor : java . util . concurrent . Executor ) : MyService = ? ? ? and you want to create the client using the zio default runtime thread pool. For example, to use a specific Executor with HttpClient which is a new async http client in java 11. Otherwise, HttpClient uses a common, shared thread pool which may or may not be what you want. Since the executor is in the ZIO environment and we want to create a layer so that the “client” is in the R (the input environment) for all effects, we can pull the executor out as an effect then add it to a layer. Here’s the code (this is the hard way): type MyEnv = Has [ MyService ] val resources : Layer [ Nothing , MyEnv ] = ZLayer . fromEffect ( ZIO . executor . map ( _ . asJava ) ) >>> ZLayer . req

1 line exception handling (scala.util.control.Exception) and functional programming, tie-in to zio

1 line exception handling (scala.util.control.Exception) and functional programming, tie-in to zio I’ve been using scala3/dotty for awhile and am in the process of converting around 25 of my libraries to the new syntax and compiler. That’s another story. As I am converting code in my own libraries, I remember transcribing a small number of zio-sql functions and types into dotty/scala3 to see if I would like the optional brace syntax. For that test, I used different exception handling constructs than just try-catch . I was thinking about zio-sql today because of some activity related to that project. It prompted me to write up this thought since I had not blogged in awhile. The scala.util.control.Exception class has been around for awhile but may not be widely used. Typically when you encounter an error, you throw an exception. If you are not using a functional programming (FP) style you are most likely letting the exception propagate up, up, and up! In contrast

dotty+scala.js+async: interesting options

dotty+scala.js+async: interesting options With the soon-to-be-released dotty 3.0.0-M1 (2020 Q4) and scala.js support rapidly improving (thanks @sjrd and team!), we can soon use scala.js with dotty. One area that has always been interesting to watch is the development of language constructs for managing effects such as Future for scala and async/await for javascript. Many languages have async/await support. scala 2.13.3 came out with -Xasync support that allows async { await(...) } like syntax. This “desugaring” can be used in combination with existing syntax such standard for-comprehensions or monadic style (chained function calls). Hence, there are 3 approaches. Working with javascript types, especially Promises, has always been problematic. For example, typescript 4.x recently introduced refinements so that Promise typing was better. Even dedicated languages such as typescript have had typing issues :-) Directly manipulating js.Promise s is important for fro

runtime start stop times for zio effects

runtime start stop times for zio effects Sometimes you need to collect the start and stop times for an effect running. For example, if the effect represents a job, you may want to record the job start and stop times in a database for analysis. zio has a .timed combinator that provides you a duration, but if you need to also add the start and stop time, .timed is not quiet right. Fortunately, we can add a few zip’ish combinators and get what we need. I use scala.js js.Date in the code below but substitute in your own date function as appropriate: /** Capture run stats including start and stop datetime. Once you have used the * timing result via `flatMap{ case (start,stop,delta,exit) => ... }`, use * `ZIO.done(exit)` to push the exit value back into an effect if desired. */ def timeRun [ R , E , A ] ( effect : ZIO [ R , E , A ] ) : ZIO [ R with zio . clock . Clock , Nothing , ( js . Date , js . Date , zio . duration . Duration ,

zio streams + scala.js: example of designing a streaming db API

zio streams + scala.js: example of designing a streaming db API nodejs has a streams API. However, if you are using zio with scala.js, you may want to use zstreams. To use zstreams, you will need to adapt your APIs. The content below was inspired by a recent zio stream Itamar training video: While scala.js is used below on nodejs, as always, scala.js has such good conformance to scala that you cannot really tell its javascript except for the use of javascript APIs. The example below adapts a javascript streaming API to scala.js and zio’s zstreams. It makes certain tradeoffs to reduce implementation time to a few minutes (the time it takes to write a blog). Generally, since its javascript, we don’t need to worry about parallelism. Ideally, we would write something whose pattern could be moved over to the jvm or another platform where parallelism is possible. Here are some good resources on zio streams: zio manual: ht