Scala: Lessons learned from the Battlefield 

Disclaimer Presentations are intended for educational purposes only and not to replace independent professional judgment. The views and opinions expressed in this presentation do not necessarily reflect the official policy or position of blibli.com. Audience discretion is advised. 

Who am I? • Alex Xandra Albert Sim • Lead Principal R&D Engineer at blibli.com • [email protected] • bertzzie(.sim) 

SCALA: THE OVERVIEW 

Safety Record is NICE • Bye bye NullPointerException* (Option type to the rescue) • Immutability is good and easy to reason • Functional tools (ADT, first-class function, etc) is VERY nice 

Parallelism is Simple and Concise • There is a built in Future • It is powerful enough to do almost anything you want to easily re: parallelism • Controlling the parallelism is done via ExecutionContext For everything else, there’s Akka 

1000s People, 1000s Style “Syntactic Diabetes” What’s the difference between line 2 and 3? 

Implicitly Bad • Implicit is essentially, scala’s answer to dependency injection • Two kind of implicit: parameter and conversion • Where does the execution context come from? Which one is used? Hard to know until runtime (!) • Could use from scope, companion object, injected by other class, etc. Can’t ever be sure until something goes wrong. • New user might have to use implicit everywhere if they’re not careful! • The good thing is that this problem is very well documented, and mostly phased out / deprecated. 

Error Messages are eh.. 

Scala Operational (-) Tooling needed to support production operations are either not as updated or not as good as Java’s (-) Latest stuff support (i.e. consul, etc) usually relies on community-maintained stuff (+) Most mainstream APM (NewRelic, Datadog, etc) has scala support (+) Profiling tools are supported and good 

Conclusion • Good for working on parallelism / concurrency • Good for writing type-dependent and safely critical software • Example of good use case: data pipeline, real time application • Stuffs to avoid: implicit, overly “exotic” syntax • Be aware of the operational challenges for large scale system Additional notes: • Stuff to be prepared for: error FAQs, good knowledge base • Sharing knowledge to everyone re: Scala could be challenging 

Now scala build tools “SIMPLE” BUILD TOOLS 

How SBT Code is Executed (Simplified) • Phase 1 – Each line of sbt file is a Setting that will be combined into Seq[Setting] – This Seq[Setting] will be passed to all subprojects • Phase 2 – Interpret the whole Seq[Setting] (remember to also parse := and ++=) – The resulting type should be a graph (!) of Task • Phase 3 – Interpret the graph of Task and execute it – Remember that this is a dependency graph, this needs to be executed in topological order – There might be caches inside of each nodes / edges 

SBT Execution Model • First phase is pure Scala • Second phase is a DSL that’s basically another language • Is the following code the same? SBT Scala someVar := someValue val someVar = someValue libraryDependencies += “com.gdn” %% “test” % “0.0.1” val libraryDependencies = deps ++ Seq(ModuleID(“com.gdn”, “test”, “0.0.1”)) 

SBT Is Always Chill 

SBT Tooling is not Ideal 

Writing SBT Plugin • Documentation is short and too simple :( • Not enough easy to read and follow code in the wild • Difficult to find local experts to help 

Summary • Tooling support could be better • Performance wise, SBT leaves a lot to be desired • Both the data and execution model is too complex for mere mortal (like me) • Any kind of customization is basically black magic and SODD (Stack Overflow Driven Development) • Conclusion: don’t doo anything too complex on sbt. Use gradle if possible. 

CLOSING 

Closing • Make sure your use case fit Scala’s strength • SBT is official, but other tools are good too. Don’t be afraid to experiments, especially if you’re still small and have other environments too. • Training new people is difficult, but not that difficult 

Thank You Slides at: https://s.id/8tYos