We are very excited to be Gold sponsors of both Scala Days Berlin in May 14th – 17th and New York 19th – 21st June. Adam Warski one of the founders of SoftwareMill talks about his Scala journey.
This article orignally found on blog.scaladays.org and written by Adam Warski.
"One of the co-founders of SoftwareMill, where he codes using Scala and other technologies, Adam is involved in open-source projects, such as sttp, MacWire, and Quicklens. In advance of his talk, “sttp: the Scala HTTP client that you always wanted!” , we spoke to Adam about his Scala journey, about the challenge of the “developer experience” and why everyone is a CTO at SoftwareMill.
Tell us a little bit about your background and your current role.
I’m a software engineer by hobby, education and daily work. What started as simple QuickBasic/Turbo Pascal coding almost 30 years ago, resulted in writing software commercially first in Java, and now for seven years in Scala. Meanwhile, I also got involved in the open source community, as well as co-founded a custom software development company, SofwareMill in 2009.
While my “official” job title is a CTO, due to the way work is organized in SoftwareMill, teams are largely independent technically, so the same as “everybody is a CEO” at SoftwareMill, you could say that “everybody is a CTO”. Hence, my day-to-day role involves a bit of running the company, a bit of open-source/community work, and quite a lot of technical research or coding for clients.
What’s the biggest highlight of your career?
Why did you pick Scala and what kind of problems do they solve for you?
Initially I got interested in Scala as it was so much more programmer-friendly and nicer to write than Java. Hence looking for a “better Java”, without the boilerplate is what got me started. However now that’s no longer a unique trait of Scala: there are many new languages, a lot of them drawing inspiration from Scala which fill in the “better Java” role. Still, I think Scala has a number of advantages, which make it the best language out there. Just to mention three of them:
- Firstly, Scala is an immutable-first language. That’s because of the language itself: constructs which make writing immutable code easy, like first-class vals, case classes, higher order functions etc. But that’s also because how the standard library is designed and written. Immutability makes a number of things easier, especially in a highly concurrent world, and languages which favor immutability have an edge here.
- Secondly, Scala’s support for higher-kinded types and typeclasses (through implicits) make it much easier to work with wrapper/container-like types, such as Futures or Tasks. These wrappers are prevalent when coding in the asynchronous or reactive styles, and having language constructs which make it convenient e.g. to work in a codebase which makes heavy usage of Futures is another point in favor of Scala.
- Finally, Scala is JVM-based which gives it access to the whole ecosystem. While interop isn’t without problems, thin layers on top of Java libraries are often sufficient to work conveniently with a library providing some unique functionality.
What’s the most important challenge Scala developers are facing today?
On the other hand, and maybe more broadly, this includes the whole toolchain. The most user-facing are IDE integrations – for example, for some reason there’s a couple of LSP (Language Server Protocol) implementations. I suppose it would be better for the whole ecosystem if there was one but with a number of maintainers/contributors.
Apart from IDEs, there are also the build tools, which receive a lot of attention lately. Sbt got the 1.0 release, there’s ongoing work on Bloop, Mill, Cbt and others. While it won’t be good to have too much fragmentation in the area, I’m hoping that the best ideas will be eventually combined into one, leading build tool for Scala.
What’s one thing that could address this challenge?
We are lucky to have initiatives such as the tooling working groups, so I’m hoping that indeed 2018 will be the year of Scala’s tooling!
However, these working groups can only do so much. I think the “one thing” would be making Scala Center role more prominent, probably with more funding to get more development possible. Being a non-profit, Scala Center can have big potential in pushing the community, compiler and tooling forward.
Who should attend your talk at Scala Days and why?
My conference session is about one of my open-source projects, sttp. Making HTTP calls is a very common thing nowadays, and the aim of the library is to make this task more programmer-friendly than currently. Sttp contains an URI builder, which makes it possible to construct endpoint addresses dynamically in a convenient way, as well as a number of backend integrations. That way, regardless if you are working with akka-http or async-http-client, the request definition API is the same. Finally, sttp contains integrations with metrics and operational systems, which are often crucial in production deployments.
The talk will be almost entirely live-coding demoing the above features in practice, and showing how to make the task of working with HTTP endpoints both readable, type-safe and convenient.