Wartremover
ZIO
Our great sponsors
Wartremover | ZIO | |
---|---|---|
6 | 59 | |
1,059 | 3,981 | |
-0.3% | 0.5% | |
8.8 | 9.5 | |
7 days ago | 7 days 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.
Wartremover
-
Is Scala to Java the same relationship as TypeScript has with ECMAScript?
By contrast, Java and ECMAScript are essentially what we might call "classical" imperative OOP languages, although ECMAScript reveals much more of its Lisp-inspired "map/filter/reduce" FP roots. IMO ESLint is essentially table stakes for working with ECMAScript, but honestly, I wouldn't stop there and would insist on working in TypeScript, including some of the tooling for ESLint specifically for TypeScript, dialing type-safety up to 11, effectively like using Wart Remover with Scala.
-
Scala Resurrection
I'm awed by the maturity of the Scala 2 compiler. Every minor version in the 2.13 series adds a new linting improvement. You can see that if you have sbt-tpolecat in your project. I'm always happy to see that some option from Wartremover is no longer used.
-
New to Scala;
I was recently trying to move away from Scapegoat to Wartremover and I got bitten by this bug which is particularly prevalent in codebases using Typelevel libraries.
WartRemover to disable some of Scala’s more questionable features.
-
Which static analysis tool do you use for Scala?
There is also wartremover but you cannot run it separately from your compile command.
-
Newspeak and Domain Modeling
or `NonUnitStatements` without explicit annotation.
This effectively locks you into writing pure code (you can extend the linter to cover other things like not using `Future` or not using Java libs outside of `MonadError` from cats[4]). The linters operate on typed ASTs at compile time, and have plugins for the most popular scala build tools. Coupled with `-XFatalWarnings', you can guarantee that nothing unexpected happens unless you explicitly pop the escape hatch, for the most part.
You can still bring in external libraries that haven't been compiled with these safties in place, so you aren't completely safe, but if you use ZIO[5]/Typelevel[6] libraries you can be reasonably assured of referentially transparent code in practice.
There are three schools of thought, roughly, in the scala community towards the depth of using the type system and linters to provide guarantees and capabilities, currently:
1) Don't attempt to do this, it makes the barrier to entry to high for Scala juniors. I don't understand this argument - you want to allow runtime footguns you could easily prevent at compile time because the verifiable techniques take time to learn? Why did you even choose to use a typesafe language and pay the compilation time penalty that comes with it?
2) Abstract everything to the smallest possible dependency interface, including effects (code to an effect runtime, F[_] that implements the methods your code needs to run - if you handle errors, F implements MonadError, if you output do concurrent things, F implements Concurrent, etc.) and you extend the effect with your own services using tagless final or free.
3) You still use effect wrappers, but you bind the whole project always to use a concrete effect type, avoiding event abstraction, thus making it easier to code, and limiting footguns to a very particular subset (mainly threadpool providers and unsafeRun or equivalent being called eagerly in the internals of applications).
My opinion is that smallest interface with effect guarantees (#2) is best for very large, long maintenance window apps where thechoice of effect runtime might change(app), or is out of the devs' control (lib); and #3 is best for small apps.
TL/DR; You can go a really, really long way to guaranteeing effects don't run in user code in scala. Not all the way like Haskell, but far enough that it's painful to code without conforming to referential transparency.
1. https://github.com/scalacenter/scalafix
2. https://github.com/scalaz/scalazzi
3. http://www.wartremover.org/
ZIO
- The golden age of Kotlin and its uncertain future
-
I had a great experience with Scala and hopefully it will get more popular
scala has 2 healthy and pretty complete lib ecosystems : check out typelevel and ZIO. Both are FP oriented, which might not be your cup of tea at first glance but I would encourage you to try em out ! Softest introduction would be to start with the typelevel cats library and build up from there. The excellent Scala with Cats will ease you softly into an FP mindset. It's a bit dated and for scala 2 only but translating to Scala 3 is a very good exercise if you feel so inclined !
-
Is it prudent to use Scala for anything new?
Last but not least, Scala is currently the language with one of the best effect systems in my opinion (https://zio.dev/). Kotlin for example has copied the approach with https://arrow-kt.io/ which I think is great actually. But when comparing Scala and Kotlin here, Scala wins by a large margin, it is a completely different world. It's like building a highly concurrent system in Erlang vs C.
Of course, if you don't want to learn things like union types, traits/typeclasses and effects (similar to async/await but more powerful) you will be annoyed by Scala. But once you learned them, you can never go back.
-
How to get started?
ZIO
-
Reconnecting with Scala. What's new?
Links: - https://dotty.epfl.ch/ - https://scala-native.org/en/stable/ - https://www.scala-js.org/ - https://typelevel.org/ - https://zio.dev/ - https://github.com/scala-native/scala-native/pull/3120 - https://github.com/lampepfl/dotty/pull/16517 - https://dotty.epfl.ch/docs/reference/experimental/index.html - https://scala-cli.virtuslab.org/ - https://scalameta.org/metals/ - https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html - https://www.scala-lang.org/blog/2023/04/18/faster-scalajs-development-with-frontend-tooling.html - https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html
-
Is Parallel Programming Hard, and, If So, What Can You Do About It? [pdf]
I use ZIO (http://zio.dev) for Scala which makes parallel programming trivial.
Wraps different styles of asynchronicity e.g. callbacks, futures, fibers into one coherent model. And has excellent resource management so you can be sure that when you are forking a task that it will always clean up after itself.
Have yet to see anything that comes close whilst still being practical i.e. you can leverage the very large ecosystem of Java libraries.
-
40x Faster! We rewrote our project with Rust!
The one advantage Rust has over Scala is that it detects data races at compile time, and that's a big time saver if you use low level thread synchronization. However, if you write pure FP code with ZIO or Cats Effect that's basically a non-issue anyway.
-
What’s so great about functional programming anyway?
> It's a weakness of functional programming, not the language.
I would strongly object this.
Have you seen ZIO?
-
Switching career from F# to scala
But overall, I'm happier with Scala. It has not one, but two lively FP communities. I recommend that you pick one of them: ZIO or TypeLevel (Cats Effect, fs2, http4s, ...). To some extent, you can mix TypeLevel libraries in ZIO projects.
- New to Scala;
What are some alternatives?
cats-effect - The pure asynchronous runtime for Scala
Monix - Asynchronous, Reactive Programming for Scala and Scala.js.
Http4s - A minimal, idiomatic Scala interface for HTTP
Vert.x - Vert.x is a tool-kit for building reactive applications on the JVM
cats - Lightweight, modular, and extensible library for functional programming.
Scapegoat - Scala compiler plugin for static code analysis
Scalastyle - scalastyle
fs2-kafka - Functional Kafka Streams for Scala
Reactor-Scala-Extensions - A scala extension for Project Reactor's Flux and Mono
Scala.Rx - An experimental library for Functional Reactive Programming in Scala
Scalafix - Refactoring and linting tool for Scala
scalafmt - This repo is now a fork of --->