Mutating the immutable
summary
A Scala platform at a bank adds @node annotations plus a scalac compiler plugin (Scarlet Async), an execution scheduler and cache, and an entity model with scenario/tweak/given blocks so functions stay referentially transparent while supporting mutable-seeming changes. The codebase is ~3M lines with ~500 devs and ~60k core lines; experiments show cache lookups over millions of node calls cost seconds (13–20s) but save minutes to over an hour (16m and 1h12m) of execution time.
AI-written summary · about
chapters (6)
- 0:00Start
- 4:31How We Manage Change
- 12:34Referential Transparency
- 15:01Parallelism
- 15:29Memorization
- 41:01We Are GonNa Do some Questions Now but if We Don't Get Time To Get to Your Question like Come to Our Stand or Kind Of Find Us Afterwards I I'M Not Sure How Long We Go Up but We'Ll Take some Questions Now Thank You Reimplementation of Monique's Tasks Backed by a this Seems like a Reemployment a Ssin of Monique's Tasks Backed with a Scheduler with some Lazy Valves Thrown in It Reminds Me a Lot of Your Pure Functional Programming Maybe a Little Own Scholar Zio with Effects How Is It Different Okay So I Think the Big Difference Is that the There Is Not the Invasion of Hype System of the Runtime Constructs So in All those Things You Mentioned You Know like in My Examples They'Re Mostly Floats Right So or Doubles So in My Examples the Type that the Program Is Dealing with Is a Double It's Not a Future of Cancelable of Double Mm-Hmm
related talks
52mBenefits of addressability - clean management of mutation
25mImmutable APIs and mutable internals: a Scala design case study
31mStarship Enterprise: Functional Programming at Huge Companies
35mIntroducing Typelevel Scala into an OO environment
50mQuantifying and Explaining Immutability in Scala
29mCascade: a Meta-Language for Change, Cause and Effect
34mA Year living Freely
01h 44mFunctional Programming: Technical Reasons to Adapt