Removed the registry steps since the drivers are now signed. This should allow you to use hidusbf without affecting secure boot. If you still want to see them, look at the previous revision of this guide.
| // summary : ZIO learning - zio tests cheat sheet as tests | |
| // keywords : scala, scalacli, zio, ziotest, @testable, cheatsheet | |
| // publish : gist | |
| // authors : David Crosson | |
| // license : Apache NON-AI License Version 2.0 (https://raw.githubusercontent.com/non-ai-licenses/non-ai-licenses/main/NON-AI-APACHE2) | |
| // id : 372e9d7a-34ab-4130-ab39-f5d060b0a2f7 | |
| // created-on : 2021-11-13T10:01:55+01:00 | |
| // managed-by : https://github.com/dacr/code-examples-manager | |
| // run-with : scala-cli $file |
Jan Nasiadka from scalac contacted me to get some feedback about our usage of ZIO. My answers below, since they can benefit the community more broadly.
Context: we use ZIO in the context of https://rudder.io, a scala application that is 11 years old - far from a greenfield application with ZIO as base architectural choice. We used ZIO as a better framework to cleanly manage errors, porting piece of existing code to it. We are part of ZIO community since 2018 (since ZIO inception, when it was not yet ZIO but a part of scalaz, and when there was only a bifunctor, no context in it). Given our usage, we use ZIO in a specific way: we have tons of entry points and evaluation of ZIO effects, not one main entry point in the "main" method of the app. For correctness, that forced us to call a lot of blocking effects (you never know what a java lib is doing), and so we stressed the thread pool ergonomics, and helped make that part better (and some part
Why you prefer cats instead of zio? TF? It’s looks like zio ecosystem more widely and zio 2.0 has better performance What do you think?
Great question!
Performance-wise, it really depends on what you're doing. The problem with benchmarks (including the ones posted for ZIO and Cats Effect) is that they apply only to abstract situations, which are often nothing like what you see in real applications. A great write-up on this problem by Daniel Spiewak here, he wrote it better than I ever could: https://gist.github.com/djspiewak/f4cfc08e0827088f17032e0e9099d292
Also, this is not an app meant for production - I don't care that much about performance under load because there will be no load. And individual operations will often be bounded by I/O anyway, so the efficiency of the underlying runtime is likely not going to make a noticeable difference in use. Then again, both the client and server are JVM apps, so even the start-up penalty of the client will slow us down than picking even the least efficient e
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
Fibers are an abstraction over sequential computation, similar to threads but at a higher level. There are two ways to think about this model: by example, and abstractly from first principles. We'll start with the example.
(credit here is very much due to Fabio Labella, who's incredible Scala World talk describes these ideas far better than I can)
Consider the following three functions
| COLLECTION 0 1 5 10 50 100 500 1000 | |
| Array[Int] 16 24 40 56 216 416 2016 4016 | |
| immutable.BitSet 24 24 24 24 24 32 96 160 | |
| immutable.IntMap[Int] 16 40 328 688 3568 7168 35968 71968 | |
| immutable.List[Int] 16 56 216 416 2016 4016 20016 40016 | |
| immutable.Map[Int,Int] 16 40 304 720 4856 9680 53504 111760 | |
| immutable.Queue[Int] 40 80 240 440 2040 4040 20040 40040 | |
| immutable.Set[Int] 16 32 264 480 3016 5840 27696 57952 | |
| immutable.SortedMap[Int,Int] 40 88 280 520 2440 4840 30008 62008 | |
| immutable.SortedSet[Int] 40 104 296 536 2456 |
