Application Development Meanderings

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 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 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 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: https://www.youtube.com/watch?v=XIIX2YSg7M0 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

vertically scaling nodejs: dotty + graaljs + zio You can horizontally or vertically scale. Horizontal scaling usually involves running multiple separate process either on the same compute server or on different servers. It is relatively complex to scale horizontally if you need to share state. Engineers often scale horizontally and decouple different data “domains” into micro-services, both of which can also be more complex to engineer. Cloud compute services and frameworks like Kubernetes help you scale horizontally but at, potentially, a large increase in complexity. You can also scale vertically. Multi-threaded programming is harder than single threaded programming. Python and nodejs are loved by developers because they make the compute enviroment simpler, and hence, the programming simpler. nodejs has asynchronous programming support via ES “await” syntax or js Promises, both of which are harder to use than straight procedural code. But, most developers have f