In this post I want to share a short recap of first Wrocław Scala User Group (WSUG) meetup. This will be kind of TIL entry, it doesn’t aim to cover the full presentation content. If you’d like to join the next meeting, join us at Wroclaw Scala User Group at meetup.com. The meetup was held in Polish so the slides are not translated.

First talk - ‘Pain-free APIs with Smithy4s’ - Jakub Kozłowski kubukoz

In this talk Jakub introduced us to Smithy - an IDL (Interface Definition Language) built for defining implementation agnostic API descriptions. During the talk we have focused on the aspects that are difficult when designing and evolving a system, namely the communication problems.

We have learned how to use Smithy to design a simple API. My key takeaways are:

  • Smithy can provide you with a single source of truth about how the systems communicate
  • With Smithy you can get rid of the implementation details during the design phase and agree on the interface in a polyglot environment
  • Makes it easier to make your code understandable - instead of knowing the project language to learn it’s API, the client just reads Smithy files
  • Smithy4s is the way to go if you want to use Smithy in Scala

The slides are available here.

Second talk - ’Jak człowiek myśli o kodzie, i jak tę wiedzę wykorzystuje Scala Toolkit.’ - Szymon Rodziewicz szymon-rd

The translated title is “How a person thinks about code, and how this knowledge is used by the Scala Toolkit”. In this one shared some insights from the Scala Toolkit development.

Digression - what’s Scala Toolkit anyway?

I figured I just leave a link here, but it seems the initiative doesn’t have any landing page. Instead of being a standalone project on it’s own, the toolkit is an initiative around scala-cli(soon to become the default Scala runner). It aims to make prototyping with Scala much easier by using a //> using toolkit that would load a set of opinionated libs for the most common tasks like using a HTTP client. A sample code snippet that calls an API using toolkit is shown in the listing below.

//> 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))

If you want to learn more about the initiative, check out the blog post by VirtusLab.

The presentation

During the talk we have learned how the team behind Scala Toolkit decides which libraries should be included, and how they come up with their criteria. They did this by introducing Cognitive Dimensions - a framework for estimating the cognitive cost of the code.

In case of Scala Toolkit, the aim is to improve scripting, prototyping and building simple services. Considering this goal they rate the dependencies based on criteria like:

  • Abstraction level
  • Expressiveness
  • Visibility
  • Compliance with the domain
  • Ecosystem fit

What does it mean for us? Well take the abstraction level as an example. We don’t want the language newcomer to understand the higher kind types, but the regular generics should be enough.

As the result of the process, authors of the toolkit cooperate with the authors of selected library to make them even better for newcomers. One of the examples of such actions can be found in this PR https://github.com/softwaremill/sttp/pull/1545.

You can find the slides here