interop-cats
mdoc
Our great sponsors
interop-cats | mdoc | |
---|---|---|
5 | 4 | |
158 | 385 | |
1.3% | 0.5% | |
5.2 | 8.4 | |
1 day ago | about 1 month ago | |
Scala | Scala | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
interop-cats
-
I have decided to connect my future with Scala (if possible), need little advice
If you're using http4s, don't use ZIO. Yes, ZIO has an interop-cats module, so you can do this. But using http4s means you're working in the conceptual framework the Typelevel ecosystem is based on (and what interop-cats does can be characterized as "describe ZIO's implementation in those terms, so the Typelevel ecosystem can make heads or tails of it.") This is essentially all cost and no benefit: you can't avoid understanding the Typelevel ecosystem if you use http4s (at least, no more than you can by using cats-effect), and you don't get any of the value proposition of ZIO (interop-cats gives you Typelevel typeclass instances for the RIO type alias, which means your error channel is rooted in Throwable, and you're faced with the most complex part of the ZIO ecosystem: ZLayer, which the Typelevel ecosystem doesn't use and doesn't need). Finally the ZIO ecosystem is still quite immature, and this brings us to documentation. There is not (yet!) anything comparable to:
- Using FS2 alongside ZIO?
-
Friction-less scala - Tell us what is causing friction in your day-to-day life with Scala
These are necessarily oversimplifications. In particular, the ZIO ecosystem offers the relevant instances of cats-effect typeclasses to support use of the ZIO type in the cats-effect ecosystem.
-
Why Typelevel hates ZIO?
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.
-
Is it possible to use cats' monad transformers (OptionT, EitherT) with an effect type (F) that has >1 type parameter?
It seems that zio/interop-cats faces a similar issue.
mdoc
- Optimal decision-making with examples built using scala
-
Friction-less scala - Tell us what is causing friction in your day-to-day life with Scala
Literally what scaladoc is, it comes with sbt. Although, it's better when enhanced with mdoc so that you get the standard microsite template like these. It would be nice to have an sbt serveDocs and if everyone would host their docs for external linking, but javadoc doesn't do that either.
-
A Scala rant
The good news is that scaladoc is produced by default by sbt and published by default. So you can often pull it from the same repository your library jar came from, extract it with zip, and read the docs. But that's also totally unnecessary - javadoc.io allows you to put in your module info and serves the docs for you, so if there's an older version you can access the documentation this way. Rely on the type signatures, since they can't lie, whilst comments (including scaladoc comments) can. Honestly, library authors should be using mdoc and including examples on every public method, and that type of documentation is something you can almost always contribute to a project for a quick pr kudos.
-
The future of Scaladoc
I know it's not new but the "Snippet validation and results (mdoc)" features in mdoc are so cool. Really takes some of the tedium out of working with documentation since you can know that as you evolve your code the compiler will make sure you keep the docs in sync. Whole new level of Readme-Driven Development
What are some alternatives?
cats-effect - The pure asynchronous runtime for Scala
sbt-unidoc - sbt plugin to create a unified Scaladoc or Javadoc API document across multiple subprojects.
slick-cats - Cats instances for Slick DBIO
sbt-mima-plugin - A tool for catching binary incompatibility in Scala
fs2-grpc - gRPC implementation for FS2/cats-effect
sbt-revolver - An SBT plugin for dangerously fast development turnaround in Scala
sbt-crossproject - Cross-platform compilation support for sbt.
coursier - Pure Scala Artifact Fetching
purescript - A strongly-typed language that compiles to JavaScript
sbt-pack - A sbt plugin for creating distributable Scala packages.
mules-http4s - Http4s Caching Implementation
sbt-updates - sbt plugin that can check Maven and Ivy repositories for dependency updates