Scala Tools

Open-source Scala projects categorized as Tools | Edit details

Top 23 Scala Tool Projects

  • GitHub repo Gitbucket

    A Git platform powered by Scala with easy installation, high extensibility & GitHub API compatibility

    Project mention: How to build a search engine with Ruby on Rails | news.ycombinator.com | 2021-09-16

    > Rails doesn't scale? Github's the largest code repository site in the world.

    You know, i think i understand both of the viewpoints here. Personally, i'd say that Rails doesn't scale as well as i'd expect it to. You can definitely build scalable systems in it, though you'll end up throwing a whole bunch of hardware resources, when compared to certain other languages and technology stacks, to serve similar load.

    For example, right now i self-host a GitLab (https://about.gitlab.com/) instance for managing my code repositories, CI builds and so on. Even with just me using it (alongside some automated processes), it routinely eats up close to 4 GB of RAM, which in my case is an entire VPSes worth and costs me about 60 Euros a year with Time4VPS (affiliate link, if you'd like to check it out: https://www.time4vps.com/?affid=5294) but would cost me way more in AWS, GCP etc. One could argue that that's not too expensive, but not everyone earns a lot of money and running 10-20 VPSes does eventually build up, since i can't afford colocation and my residential homelab setup with a WireGuard tunnel to bypass ISP NAT with a proxy VPS is pretty slow, even if i can afford more storage, RAM and CPU power that way.

    Compare that situation to projects like Gogs (https://gogs.io/), Gitea (https://gitea.com/), GitBucket (https://gitbucket.github.io/) and sourcehut (https://sourcehut.org/) - i'd argue that all of them on average use less CPU resources and memory for accomplishing similar tasks. For example, have a look here: https://forgeperf.org/

    However, we cannot ignore the fact that using Ruby might have been exactly what allowed for quickly creating the functionality of GitLab and many other platforms and tools out there, GitHub included, so the choice between usable software and innovation in the near future and performant software possibly years from now is a tricky one.

    There are probably good arguments for both, but noone can declare either to be better. Personally, i don't mind using Ruby, Python or even PHP when it makes sense and i don't need to worry about scalability from day 0.

  • GitHub repo dotty

    The Scala 3 compiler, also known as Dotty.

    Project mention: Programming BS: Checked Exceptions | reddit.com/r/programming | 2021-10-15
  • Nanos

    Run Linux Software Faster and Safer than Linux with Unikernels.

  • GitHub repo sbt

    sbt, the interactive build tool

    Project mention: SBT management on Apple M1 | reddit.com/r/scala | 2021-04-30

    It's an issue with the zule jvm and Java native access. A workaround is provided in this thread.

  • GitHub repo Mill

    Your shiny new Java/Scala build tool!

    Project mention: Thats my first time with Scala and wanted to create something interesting as first program, so created simple single colored window in LWJGL (which will turn into traingle), next in my tour is password generator, and then wayland implementetion as generated scala code from XML protocols. | reddit.com/r/scala | 2021-07-24

    Also, many scala folks are not happy with sbt. There's a new build tool on the block Mill - https://github.com/com-lihaoyi/mill - by Li Haoyi . He's a scala master and he's written a _great_ intro to scala https://www.handsonscala.com/

  • GitHub repo Metals

    Scala language server with rich IDE features 🚀

    Project mention: Scala - what is best development setup? | reddit.com/r/scala | 2021-04-27

    You should be able to use Metals with vim and get IDE-like functionalities in your preferred editor: https://scalameta.org/metals/

  • GitHub repo Wartremover

    Flexible Scala code linting tool

    Project mention: Newspeak and Domain Modeling | news.ycombinator.com | 2021-06-29

    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/

    4. https://typelevel.org/cats/api/cats/MonadError.html

    5. https://zio.dev/

    6. https://typelevel.org/

  • GitHub repo bloop

    Bloop is a build server and CLI tool to compile, test and run Scala fast from any editor or build tool.

    Project mention: Scala 3 and Web Tech Stack | reddit.com/r/scala | 2021-07-07
  • Scout APM

    Scout APM: A developer's best friend. Try free for 14-days. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.

  • GitHub repo Scalastyle

    scalastyle

    Project mention: Checklist for learning Scala | dev.to | 2021-02-08

    Find a code conventions document: the online Scala course that I’ve started uses Scalastyle for enforcing the style of the code. If it’s good enough for the Scala core team, it’s good enough for me.

  • GitHub repo Scalafix

    Refactoring and linting tool for Scala

    Project mention: Newspeak and Domain Modeling | news.ycombinator.com | 2021-06-29

    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/

    4. https://typelevel.org/cats/api/cats/MonadError.html

    5. https://zio.dev/

    6. https://typelevel.org/

  • GitHub repo Scapegoat

    Scala compiler plugin for static code analysis

  • GitHub repo Scoverage

    Scoverage Scala Code Coverage Core Libs

  • GitHub repo Scalatex

    Programmable, Typesafe Document Generation

  • GitHub repo Scurses

    Scurses, terminal drawing API for Scala, and Onions, a Scurses framework for easy terminal UI

  • GitHub repo Fastring

    Extremely fast string formatting

  • GitHub repo Scalariform

    Scala source code formatter

  • GitHub repo scala-trace-debug

    Macro based print debugging. Locates log statements in your IDE.

  • GitHub repo fast-string-interpolator

    Scala macro that generates ultra-fast string interpolators.

  • GitHub repo scalajs-benchmark

    Benchmarks: write in Scala or JS, run in your browser. Live demo:

  • GitHub repo Scaps

    Scala API Search

  • GitHub repo Time Series library

    Time Series library for Scala

  • GitHub repo dregrex

    Dregex is a JVM library that implements a regular expression engine using deterministic finite automata (DFA). It supports some Perl-style features and yet retains linear matching time, and also offers set operations.

  • GitHub repo pos

    Macro based print debugging. Locates debug statements in your IDE. Supports logging.

  • GitHub repo Spark Tools

    Executable Apache Spark Tools: Format Converter & SQL Processor

NOTE: The open source projects on this list are ordered by number of github stars. The number of mentions indicates repo mentiontions in the last 12 Months or since we started tracking (Dec 2020). The latest post mention was on 2021-10-15.

Index

What are some of the best open-source Tool projects in Scala? This list will help you:

Project Stars
1 Gitbucket 8,480
2 dotty 4,758
3 sbt 4,382
4 Mill 1,633
5 Metals 1,577
6 Wartremover 981
7 bloop 772
8 Scalastyle 681
9 Scalafix 638
10 Scapegoat 438
11 Scoverage 368
12 Scalatex 289
13 Scurses 231
14 Fastring 123
15 Scalariform 114
16 scala-trace-debug 111
17 fast-string-interpolator 69
18 scalajs-benchmark 66
19 Scaps 37
20 Time Series library 35
21 dregrex 31
22 pos 22
23 Spark Tools 11
Find remote jobs at our new job board 99remotejobs.com. There are 34 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com