Metals
Wartremover
Our great sponsors
Metals | Wartremover | |
---|---|---|
18 | 6 | |
2,017 | 1,059 | |
0.9% | -0.3% | |
9.8 | 8.8 | |
8 days ago | 4 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.
Metals
-
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
-
Tmux, NeoVim, etc. to write pure Kotlin code?
You might want to look at Scala, they have proper LSP support with metals which means you can write your code in vscode, neovim, emacs, or even fleet (the new jetbrains text editor).
-
New plugin to support LSP file operations
Please write in the comments if you know of any language servers I should test it with. Currently I tested only metals and rust-analyzer.
-
Why are all the guides on using LSP functionality full of bloat?
If you are using nvim-lspconfig you can pass the settings as a Lua table to the setup function. For example, here are may metals settings:
- Type-Signature.com
-
What is the one thing you need everyday to make your job easier?
Bazel support in Metals. I didn't spend all that time figuring out and adjusting Emacs/Spacemacs and making my workflow (almost) mouse-free just to scrap my config and switch to IDEA's rodent infested ways.
-
Scala 2.13.9 is here
There is one small issue involving code completion returning inappropriate completions in some cases; https://github.com/scalameta/metals/pull/4414 will fix it, once it's included in a release. Perhaps that's the PR you saw?
-
Scala Isn't Fun Anymore
It is, by quite a bit.
While the "Scala IDE" project is dead for all practical purposes, IntelliJ IDEA's Scala plugin is actually pretty amazing. There's also a VisualStudio plugin that does pretty much the same and is advancing by leaps and bounds. There are also interconnecting projects that provide i.e. language server or build server that are reused by other projects. It's pretty modular. Metals (https://scalameta.org/metals/) is amazing.
In general the language has become a wee bit faster to build, there was good progress with build times during the 2.12/2.13 cycles.
With Scala3 the language got a bit simpler; concepts that were implemented explicitly using (hehe) implicits got their own keywords and a lot of the opinionated boilercode that cause a lot of debates is now generated during complication and hidden. A lot of "standardization" has occurred.
- A Python-compatible statically typed language erg-lang/erg
-
Starting with Scala: editor and version choice?
IntelliJ has its own BSP. The other one is Metals. You can use it with many IDEs (vim, emacs, vscode, atom,...). Use it with emacs if you're comfortable with it.
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.
-
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/
What are some alternatives?
intellij-plugins - Open-source plugins included in the distribution of IntelliJ IDEA Ultimate and other IDEs based on the IntelliJ Platform
Scapegoat - Scala compiler plugin for static code analysis
Jupyter Scala - A Scala kernel for Jupyter
Scalastyle - scalastyle
sbt - sbt, the interactive build tool
Scalafix - Refactoring and linting tool for Scala
bloop - Bloop is a build server and CLI tool to compile, test and run Scala fast from any editor or build tool.
scalafmt - This repo is now a fork of --->
Linter - Static Analysis Compiler Plugin for Scala
dotty - The Scala 3 compiler, also known as Dotty.
Scurses - Scurses, terminal drawing API for Scala, and Onions, a Scurses framework for easy terminal UI