Connecting...

W1siziisimnvbxbpbgvkx3rozw1lx2fzc2v0cy9zawduawz5lxrly2hub2xvz3kvanbnl2jhbm5lci1kzwzhdwx0lmpwzyjdxq

Tapad Takeaways: Scalar Conference in Warsaw by Luca Venturi, Håvard Wall, Paweł Cejrowski

W1siziisijiwmtgvmdgvmtqvmdgvmtgvmdivotcvrfbfntzrzfdrquf3uexalmpwzyjdlfsiccisinrodw1iiiwiotawedkwmfx1mdazzsjdxq

If you went along to Scalar Conference in Warsaw back in April you might have spotted Tapad there! After the conference they wrote this great review on their experience. Let us know what you thought of Scalar 2018.

 

'Last week, we visited Warsaw to participate in the fifth edition of the Scalar — Scala conference in Central Europe where latest Scala trends and use cases were presented. In case you missed it, here are some interesting insights and conclusions we gathered:

  • There is a huge activity in the field of reactive streams, with growing interest now that Java 9 standardized the Flow API, and more frameworks are embracing them. Akka Streams are kind of the obvious choice here, but more lightweight and easier solutions are emerging, with Monix in particular looking quite interesting.
  • Scalaz 8 is offering alternatives for projects where using Akka Actors is too heavy or cumbersome. Especially, when you don’t need to work in a distributed environment.
  • Blockchain is the buzzword of the moment, so there was also a presentation on how to use it in Scala; the speaker pointed out that as the complexity of the blockchain projects increases, developers started to move away from the C++ solutions and seeking libraries in the JVM space, which is now growing.
  • There were a couple of presentations related to experiences bringing a system into production, in particular one large scale logistic project using microservices, and one more focused on containers.
  • ScalaJS has been mentioned several times, and surely it can be attractive on some contexts. For example, if our project’s backend codebase is Scala-based we can expose the model as a library which can be used from JavaScript or even go further and completely hide HTTP layer using libraries like Endpoints.
  • For different reasons, there were 3 projects that have to deal with running untrusted and potentially dangerous code from users, and they come up with very different solutions:
  1. ScalaFiddle (which you should totally check out if you haven’t done so yet) chose to avoid the problem and the issues of sandboxing, compiling the code to ScalaJS and sending it back to the user for execution on the local machine; this approach limits the compatibility of ScalaFiddle to libraries that can run on ScalaJS.
  2. UX Forms decided to implement sandboxing, mainly using containers on Kubernetes, and tuning the JVM to use less memory than what is allocated to the container
  3. Cartographer.io went the hard way, and wrote a language from scratch, Atlas, to achieve maximum control and fun
  • We deeply enjoyed a presentation on the memory consumption of classes, where the speaker presented the surprising discovery that not only the type of garbage collector can affect the speed of your software (in his case, in some configuration, by even a magnitude of speed), but also the amount of memory required by the program to run. We will definitely need to investigate more this aspect.
  • The more expert Scala Developer could enjoy also more advanced presentations about leveraging the Type System to write more robust code. In particular, the talk presenting usage of hylomorphism with expressive schemas was an interesting input to the domain we are tackling.
All in all a great experience, made even better by the choice of restaurants that Warsaw provides!'
 
This article was written by Luca Venturi, Håvard Wall, Paweł Cejrowski and posted originally on Tapad Engineering.