Imagine you have a common business problem to solve. You need to write a program that fetches text from a web service and then creates a file in the local filesystem with content and path based on the downloaded information.
If you wanted to solve this problem in Scala, you would probably create a project with a build tool of your choice, search for libraries that would get you started fast, and add them as dependencies. Unfortunately, that would take considerable time, with more time added, if the script had to be deployed to production. In light of these issues, it seems unlikely that many would select Scala, by itself, for this purpose.
Now, what if you could skip or significantly shorten these steps? What if you were given the necessary libraries and setup? We don’t need to imagine this because Scala Toolkit, Scala CLI, and their integration are already making that a reality.
The power of Scala Toolkit
With Scala Toolkit and Scala CLI, the steps required to solve the previous problem would be to install the Scala CLI (note: other installation methods available here):
brew install scala-cli
Then, create a Scala script to solve the problem using the Toolkit libraries. In this case, we could use sttp for making the http requests and os-lib to operate on the files.
//> using toolkit import sttp.client3._ val client = SimpleHttpClient() val response = client .send(basicRequest.get(uri"https://httpbin.org/get")) val responseBody = response.body.getOrElse(exit("Service not responding")) val fileNameAndContent = responseBody.split(" ") os.write(os.pwd / fileNameAndContent(0), fileNameAndContent(1))
Then you simply run it with scala-cli and your task is finished:
Besides running the script, Scala CLI provides a large set of utilities to help you package and deliver the application. To learn more, visit the Scala CLI website.
What is Scala Toolkit?
Scala Toolkit is an ongoing effort by Scala Center and VirtusLab to compose a set of approachable libraries to solve everyday problems. But what makes a library approachable in these cases, one may ask? That’s a question we took seriously by applying techniques often used by User Experience researchers. Because when you think about it, the developer is the library’s user, and one of the main priorities for the library should be to make the user’s experience as good as possible.
These libraries will be made easily accessible as a precomposed package. This package will be available for each Scala release. In addition, Scala Toolkit is planned to have integrations with Scala CLI and major build tools, allowing instant access for users planning to use it in their projects.
Note that Scala Toolkit does not intend to create libraries of its own. The goal is to work with the maintainers of existing, battle-tested libraries. Neither will we promote these libraries as universal solutions. We plan to allow users to use them easily while acknowledging that other libraries will be better suited in certain situations.
Quick to learn
All libraries featured in the Toolkit will arrive with carefully prepared knowledge bases featuring well-structured practical information. In addition, all libraries will be available in one place, allowing the developers to find solutions and example snippets to solve their problems quickly. The availability of these resources and the focus on the simplicity of the libraries’ APIs should allow the developers to use them immediately, with occasional glances into the knowledge base if needed.
Measuring the developer’s experience
As good as it all may sound, the next problem arises: How to measure the quality of the developer’s experience, especially with libraries? That’s the next area where we do not intend to reinvent the wheel. Instead, we applied measures that we found successful in similar situations in the past. We constructed the main measures from our adjusted variation of the Cognitive Dimensions Framework, where we looked at the cognitive cost and time required in interactions with the library. Alongside that, we measured a set of practical aspects of each library, including tests, responsiveness and availability of the maintainers; documentation; popularity; dependencies; dependencies stability; small size; API stability; versioning schema; and cross-platform support. Finally, we considered language features used in the libraries, along with some structural measures that assess the overall consistency and structure of definitions in the libraries.
All of these measures are not only applied to the selection process. We are using it to provide the maintainers with an insight from the Developer Experience perspective. This insight, in some cases, helps the maintainers when planning new features and the API structure.
The current status
We’ve reached the first milestone for implementing the Scala Toolkit. We’ve talked with maintainers and interested parties and decided on the following libraries:
- MUnit for testing
- Sttp for HTTP client
- UPickle/UJson for reading, writing and operating on JSONs
- OS-Lib for operating on files and the operating system.
The library’s maintainers have confirmed that they will work with us to build the Scala Toolkit. Right now, they are working hard to make the APIs stable and to fix important issues.
We at Scala Center and VirtusLab are preparing tutorials and knowledge bases for these libraries. In parallel, we are planning and implementing the integrations with Scala CLI. And we are iterating on our Developer Experience framework and expanding our knowledge in these areas, applying it to the libraries chosen for the Toolkit.
The release of the Scala Toolkit will consist of two elements – the release of the libraries package and the publication of the tutorials in the knowledge base. The first version of the Scala Toolkit can be expected at the beginning of 2023.
Plans for the future
Up ahead are the outstanding milestones in this project. We plan to add more libraries to the Toolkit to expand its possibilities. The areas we’ve planned include building an HTTP server, plotting, supporting operations on more file formats, and many others. Moreover, we intend to iterate on the integrations with tooling. Our main focus in this area will be to give users stability and easy access to the libraries. We hope that it will make Scala feel fully “batteries-included”. These integrations will include other build tools, not only the Scala CLI.