Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
http4s-micrometer-metrics
Discontinued Http4s https://http4s.org metrics implementation based on meters4s https://github.com/ovotech/meters4s
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
However, ZIO continues to offer cats-effect type classes and I certainly have no doubt cats-effect 3 continues to benefit from John's contributions. Furthermore, I likewise don't doubt the value of the ZIO ecosystem generally, and John's success in building the ZIO community speaks for itself. I personally have chosen to remain closer to the other, let's say "classical," pure FP ecosystems, partially for historical (or, if you prefer, "sunk cost") reasons, but partially because I'm satisfied the value of the Haskell/Typelevel/PureScript/fp-ts/etc. interplay warrants it.
Let me recommend watching Programming Without Type Classes. IMO, /u/jdegoes does a characteristically excellent job of explaining the goals, and therefore the architecture, of the ZIO ecosystem. In particular, he lays out some information about how the ZIO ecosystem strives to retain the reasoning ability those of us in the Typelevel ecosystem appreciate about the type classes we've come to know and love (or know and loathe...) while also retaining the ZIO ecosystem's distinctive "pure FP the native Scala way" and what I'll loosely call its "batteries included" philosophy, by which I mostly mean that the actual ZIO type constructor combines aspects of what, in the Typelevel ecosystem, we get from the MonadError and Kleisli type class and type. This is the clearest explanation of why the ZIO ecosystem is as it is, from a conceptual standpoint, I've yet seen.
To me, as a user of, but not a contributor to, the answer is actually pretty simple: the Typelevel ecosystem retains a lot of contact with the Haskell ecosystem and continues to inspire, for example, the PureScript and fp-ts ecosystems. The Typelevel community continues to make good progress dealing with, for example, the challenges in supporting effective type inference with the architecture they've chosen. Things are getting better, and at least for me, the investment is paying off.
To me, as a user of, but not a contributor to, the answer is actually pretty simple: the Typelevel ecosystem retains a lot of contact with the Haskell ecosystem and continues to inspire, for example, the PureScript and fp-ts ecosystems. The Typelevel community continues to make good progress dealing with, for example, the challenges in supporting effective type inference with the architecture they've chosen. Things are getting better, and at least for me, the investment is paying off.
I know of https://github.com/davenverse/epimetheus and https://github.com/ovotech/http4s-micrometer-metrics but we don't use Prometheus and want to have our business-specific metrics (so not only http), so neither of these libraries can help us. Metrics feel a bit like a blind spot in the TypeLevel community.
I know of https://github.com/davenverse/epimetheus and https://github.com/ovotech/http4s-micrometer-metrics but we don't use Prometheus and want to have our business-specific metrics (so not only http), so neither of these libraries can help us. Metrics feel a bit like a blind spot in the TypeLevel community.