Closing Keynote: The Tyranny of Structurelessness

A presentation at Code BEAM Virtual in May 2020 in by Brooklyn Zelenka

Slide 1

Slide 1

T YRANNY THE OF STRUCTURELESSNESS N O I T I D E L UA H H O W M O R E M E A N I N G F U L C O D E C A N M A K E Y O U R P R O J E C T M O R E R E S I L I E N T & M A I N TA I N A B L E H T R I

Slide 2

Slide 2

THE T YRANNY OF STRUCTURELESSNESS For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of GOTO statements in the programs they produce πŸŽ€πŸ’§ EDSGER DIJKSTRA

Slide 3

Slide 3

THE T YRANNY OF STRUCTURELESSNESS For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of GOTO statements in the programs they produce πŸŽ€πŸ’§ EDSGER DIJKSTRA

Slide 4

Slide 4

THE T YRANNY OF STRUCTURELESSNESS What’s she on about? Elixir doesn’t have GOTOs… πŸ€” THIS AUDIENCE

Slide 5

Slide 5

THE T YRANNY OF STRUCTURELESSNESS B R O O K LY N Z E L E N K A , @ E X P E D E

Slide 6

Slide 6

THE T YRANNY OF STRUCTURELESSNESS B R O O K LY N Z E L E N K A , @ E X P E D E β€’ Cofounder/CTO at Fission β€’ https://fission.codes β€’ Make DevOps & Backend obsolete 😈 β€’ Spending a lot of time with IPFS, DIDs, CRDTs β€’ Want to hear more? Berlin FP online meetup June 2 β€’ PLT & VM enthusiast β€’ Prev. Ethereum Core Developer β€’ Primary author of Witchcraft Suite & Exceptional β€’ This is a version of CodeBEAM Amsterdam 2019 keynote β€’ Whova app for Q&A afterwards

Slide 7

Slide 7

THE BIG IDEA

Slide 8

Slide 8

THE BIG IDEA πŸ’­βš™πŸš€

Slide 9

Slide 9

THE BIG IDEA ONE-LINER

Slide 10

Slide 10

THE BIG IDEA ONE-LINER ✈ Work at a higher level πŸ›Έ

Slide 11

Slide 11

THE BIG IDEA LANGUAGE DESIGN REFLECTS INTENDED USE 🌐

Slide 12

Slide 12

THE BIG IDEA W H O ’S O RG LO O KS L I K E T H I S ?

Slide 13

Slide 13

THE BIG IDEA W H O ’S O RG LO O KS L I K E T H I S ? 🧠 πŸ‘¨πŸ’» πŸ‘©πŸ’» πŸ‘©πŸ’» πŸ‘¨πŸ’» βš™ πŸ‘©πŸ’» πŸ‘¨πŸ’»

Slide 14

Slide 14

THE BIG IDEA W H O ’S O RG LO O KS L I K E T H I S ? 🧠 πŸ‘¨πŸ’» πŸ‘©πŸ’» πŸ‘©πŸ’» πŸ‘¨πŸ’» βš™ πŸ‘©πŸ’» πŸ‘¨πŸ’»

Slide 15

Slide 15

THE BIG IDEA HOW ABOUT THIS? πŸ‘©πŸ’» πŸ‘©πŸ’» πŸ‘¨πŸ’» βš™ πŸ‘¨πŸ’» πŸ‘©πŸ’» πŸ‘¨πŸ’»

Slide 16

Slide 16

THE BIG IDEA HOW ABOUT THIS? πŸ‘©πŸ’» πŸ‘©πŸ’» πŸ‘¨πŸ’» βš™ πŸ‘¨πŸ’» πŸ‘©πŸ’» πŸ‘¨πŸ’»

Slide 17

Slide 17

THE BIG IDEA QUESTIONS

Slide 18

Slide 18

THE BIG IDEA QUESTIONS We want more type of features over time. As a result, complexity grows at an exponential rate.

Slide 19

Slide 19

THE BIG IDEA QUESTIONS We want more type of features over time. As a result, complexity grows at an exponential rate. How do you make Elixir code more flexible and easier to reason about at scale?

Slide 20

Slide 20

THE BIG IDEA QUESTIONS We want more type of features over time. As a result, complexity grows at an exponential rate. How do you make Elixir code more flexible and easier to reason about at scale? Do you think that the patterns we use today are the best possible patterns for software?

Slide 21

Slide 21

THE BIG IDEA QUESTIONS We want more type of features over time. As a result, complexity grows at an exponential rate. How do you make Elixir code more flexible and easier to reason about at scale? Do you think that the patterns we use today are the best possible patterns for software? How will you write code in 2025, 2030, and 2050?

Slide 22

Slide 22

THE BIG IDEA CORE We need to evolve our approach: focus on domain and structure!

Slide 23

Slide 23

THE BIG IDEA CORE We need to evolve our approach: focus on domain and structure! ✨ πŸ¦„ πŸš€

Slide 24

Slide 24

IN THE LARGE

Slide 25

Slide 25

IN THE LARGE 🌟

Slide 26

Slide 26

IN THE LARGE C O D E YO U U S E D TO W R I T E Imperative

Slide 27

Slide 27

IN THE LARGE C O D E YO U U S E D TO W R I T E Imperative

Slide 28

Slide 28

IN THE LARGE β€œGOOD” ELIXIR Imperative

  • Functional core, imperative shell

Slide 29

Slide 29

IN THE LARGE β€œGOOD” ELIXIR Imperative Ξ»

  • Functional core, imperative shell

Slide 30

Slide 30

IN THE LARGE Imperative 3 - L AY E R πŸš€ Ξ»

  • Generalization of hexagonal/12-factor

Slide 31

Slide 31

IN THE LARGE Imperative 3 - L AY E R πŸš€ Semantic DSL / OO Ξ»

  • Generalization of hexagonal/12-factor

Slide 32

Slide 32

IN THE LARGE PROP + MODEL TEST

Slide 33

Slide 33

GOTO CONSIDERED HARMFUL

Slide 34

Slide 34

G OTO S C O N S I D E R E D H A R M F U L W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦢 πŸ”«

Slide 35

Slide 35

G OTO S C O N S I D E R E D H A R M F U L W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦢 πŸ”« β€’ GOTOs β€’ Low level instruction β€’ Literally how the machine is going to see it β€’ Extremely flexible β€’ Highly concrete β€’ Huge number of implicit states

Slide 36

Slide 36

G OTO S C O N S I D E R E D H A R M F U L W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦢 πŸ”« β€’ GOTOs β€’ Low level instruction Line 1 Line 2 β€’ Literally how the machine is going to see it Line 3 β€’ Extremely flexible Line 4 β€’ Highly concrete β€’ Huge number of implicit states L i n e 5 β€” G OTO Line 6

Slide 37

Slide 37

G OTO S C O N S I D E R E D H A R M F U L W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦢 πŸ”« β€’ GOTOs β€’ Low level instruction Line 1 Line 2 β€’ Literally how the machine is going to see it Line 3 β€’ Extremely flexible Line 4 β€’ Highly concrete β€’ Huge number of implicit states L i n e 5 β€” G OTO Line 6

Slide 38

Slide 38

G OTO S C O N S I D E R E D H A R M F U L W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦢 πŸ”« β€’ GOTOs β€’ Low level instruction Line 1 Line 2 β€’ Literally how the machine is going to see it Line 3 β€’ Extremely flexible Line 4 β€’ Highly concrete β€’ Huge number of implicit states L i n e 5 β€” G OTO Line 6

Slide 39

Slide 39

G OTO S C O N S I D E R E D H A R M F U L W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦢 πŸ”« β€’ GOTOs β€’ Low level instruction Line 1 Line 2 β€’ Literally how the machine is going to see it Line 3 β€’ Extremely flexible Line 4 β€’ Highly concrete β€’ Huge number of implicit states L i n e 5 β€” G OTO Line 6 πŸ’₯

Slide 40

Slide 40

G OTO S C O N S I D E R E D H A R M F U L STRUCTURED PROGRAMMING while

Slide 41

Slide 41

G OTO S C O N S I D E R E D H A R M F U L STRUCTURED PROGRAMMING β€’ Subroutines β€’ Loops β€’ Switch/branching β€’ Named routines while

Slide 42

Slide 42

G OTO S C O N S I D E R E D H A R M F U L T H E N E X T G E N E R AT I O N πŸš€

Slide 43

Slide 43

G OTO S C O N S I D E R E D H A R M F U L T H E N E X T G E N E R AT I O N πŸš€ β€’ Functions β€’ Map β€’ Reduce β€’ Filter β€’ Constraint solvers

Slide 44

Slide 44

G OTO S C O N S I D E R E D H A R M F U L TRADEOFFS

Slide 45

Slide 45

G OTO S C O N S I D E R E D H A R M F U L TRADEOFFS β€’ Exchange granular control for structure β€’ Meaning over mechanics β€’ More human than machine β€’ Safer!

Slide 46

Slide 46

G OTO S C O N S I D E R E D H A R M F U L TRADEOFFS β€’ Exchange granular control for structure β€’ Spectrum β€’ Meaning over mechanics β€’ Turing Tarpit β€’ More human than machine β€’ Church Chasm β€’ Safer! β€’ Haskell Fan Fiction

Slide 47

Slide 47

COMPLEXITY ACTO R A BY S S πŸ•³

Slide 48

Slide 48

COMPLEXITY ACTO R A BY S S πŸ•³ 1. Each step is very simple 2. Reasoning about dynamic organisms is hard 1. Remember to store your data for crash recovery 2. Called collaborator may not be there 3. Complexity grows faster than linear 4. Find common factors β€” your abstraction

Slide 49

Slide 49

COMPLEXITY ACTO R A BY S S πŸ•³ 1. Each step is very simple 2. Reasoning about dynamic organisms is hard 1. Remember to store your data for crash recovery 2. Called collaborator may not be there 3. Complexity grows faster than linear 4. Find common factors β€” your abstraction

Slide 50

Slide 50

250 G OTO S C O N S I D E R E D H A R M F U L PAY O F F Structured Unstructured

Slide 51

Slide 51

250 G OTO S C O N S I D E R E D H A R M F U L COMPLEXITY PAY O F F Structured Unstructured TIME

Slide 52

Slide 52

G OTO S C O N S I D E R E D H A R M F U L PAY O F F 1000 COMPLEXITY 750 500 Unstructured Structured 250 TIME

Slide 53

Slide 53

G OTO S C O N S I D E R E D H A R M F U L PAY O F F 1000 COMPLEXITY 750 500 Unstructured Structured 250 TIME

Slide 54

Slide 54

G OTO S C O N S I D E R E D H A R M F U L PAY O F F 1000 COMPLEXITY 750 500 Unstructured Structured 250 TIME

Slide 55

Slide 55

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 56

Slide 56

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 57

Slide 57

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 58

Slide 58

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 59

Slide 59

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 60

Slide 60

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 61

Slide 61

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 62

Slide 62

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 63

Slide 63

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 64

Slide 64

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 65

Slide 65

COMPLEXITY ORTHOGONAL COMPLECTING πŸ•

Slide 66

Slide 66

COMPLEXITY ORTHOGONAL COMPLECTING πŸ• Structures: 4

Slide 67

Slide 67

COMPLEXITY ORTHOGONAL COMPLECTING πŸ• Structures: 4 Results: effectively limitless

Slide 68

Slide 68

ON ABSTRACTION & DSLS

Slide 69

Slide 69

ON ABSTRACTION & DSLS N O T G E T T I N G T R A P P E D I N T H E D E TA I L S

Slide 70

Slide 70

ABSTRACTION & DSLS COMMONALITIES

Slide 71

Slide 71

ABSTRACTION & DSLS COMMONALITIES

Slide 72

Slide 72

ABSTRACTION & DSLS COMMONALITIES β€’ They clearly have a similar structure β€’ NOT equally expressive β€’ Enumerable β€’ Always converted to List β€’ Witchcraft.Functor

Slide 73

Slide 73

ABSTRACTION & DSLS COMMONALITIES

Slide 74

Slide 74

ABSTRACTION & DSLS COMMONALITIES

Slide 75

Slide 75

ABSTRACTION & DSLS COMMONALITIES

Slide 76

Slide 76

ABSTRACTION & DSLS COMMONALITIES β€’ Different, but also have similar structure β€’ Not very pipeable because 2 paths β€’ …lots of duplicate code

Slide 77

Slide 77

ABSTRACTION & DSLS COMMONALITIES β€’ Different, but also have similar structure β€’ Not very pipeable because 2 paths β€’ …lots of duplicate code β€’ Why limit to only to two ways?

Slide 78

Slide 78

ABSTRACTION & DSLS S TA R T F R O M R U L E S

Slide 79

Slide 79

ABSTRACTION & DSLS S TA R T F R O M R U L E S β€’ Describe what the overall solution looks like β€” β€œfront end” interface

Slide 80

Slide 80

ABSTRACTION & DSLS S TA R T F R O M R U L E S β€’ Describe what the overall solution looks like β€” β€œfront end” interface β€’ Choose how it gets run contextually β€” β€œback end” runner

Slide 81

Slide 81

ABSTRACTION & DSLS TWO-PHASE

Slide 82

Slide 82

ABSTRACTION & DSLS TWO-PHASE β€’ Always a two-phase process β€’ Abstract, then concrete β€’ Do concretion at application boundary

Slide 83

Slide 83

ABSTRACTION & DSLS TWO-PHASE β€’ Always a two-phase process β€’ Abstract, then concrete β€’ Do concretion at application boundary

Slide 84

Slide 84

ABSTRACTION & DSLS TWO-PHASE d n e t n Fro β€’ Always a two-phase process β€’ Abstract, then concrete β€’ Do concretion at application boundary B d n e k c a

Slide 85

Slide 85

ABSTRACTION & DSLS IMPROVING Kernel

Slide 86

Slide 86

ABSTRACTION & DSLS IMPROVING Kernel β€’ Fallback keys β€’ Bang-functions

Slide 87

Slide 87

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S

Slide 88

Slide 88

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity

Slide 89

Slide 89

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition

Slide 90

Slide 90

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition

Slide 91

Slide 91

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition

Slide 92

Slide 92

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition β€’ Let’s abstract default values!

Slide 93

Slide 93

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition β€’ Let’s abstract default values!

Slide 94

Slide 94

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition β€’ Let’s abstract default values!

Slide 95

Slide 95

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition β€’ Let’s abstract default values!

Slide 96

Slide 96

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition β€’ Let’s abstract default values! πŸ”

Slide 97

Slide 97

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition β€’ Let’s abstract default values! β€’ More focused (does one thing) πŸ”

Slide 98

Slide 98

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition β€’ Let’s abstract default values! β€’ More focused (does one thing) β€’ More general (works everywhere) πŸ”

Slide 99

Slide 99

ABSTRACTION & DSLS I M P R O V I N G K e r n e l β€” FA L L B A C K K E Y S β€’ Composition is at the heart of modularity β€’ Orthogonality is at the heart of composition β€’ Let’s abstract default values! β€’ More focused (does one thing) β€’ More general (works everywhere) β€’ Ad hoc function extension πŸ”

Slide 100

Slide 100

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS

Slide 101

Slide 101

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS

Slide 102

Slide 102

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS πŸ’£

Slide 103

Slide 103

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS πŸ’£

Slide 104

Slide 104

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS πŸ’£ Abstracted out πŸ’£ foo!/* from foo/*

Slide 105

Slide 105

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS πŸ’£ Abstracted out πŸ’£ foo!/* from foo/*

Slide 106

Slide 106

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS πŸ’£ Abstracted out πŸ’£ foo!/* from foo/* πŸ†— ⏩

Slide 107

Slide 107

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS πŸ’£ Abstracted out πŸ’£ foo!/* from foo/* πŸ†— ⏩ πŸ’£

Slide 108

Slide 108

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS πŸ’£ Works everywhere Any data Any error struct Abstracted out πŸ’£ foo!/* from foo/* πŸ†— ⏩ πŸ’£ Any flow (esp. pipes) Super easy to test

Slide 109

Slide 109

ABSTRACTION & DSLS IMPROVING Kernel β€” BANG FUNCTIONS πŸ’£ Works everywhere Any data Any error struct Abstracted out πŸ’£ foo!/* from foo/* πŸ†— ⏩ πŸ’£ Any flow (esp. pipes) Super easy to test BONUS Disambiguate between nil value and actual errors

Slide 110

Slide 110

ABSTRACTION STO RY T E L L I N G πŸ“š

Slide 111

Slide 111

ABSTRACTION STO RY T E L L I N G πŸ“š

  1. Your code read like a story 2. We even see this in high-level goals of (e.g.) Phoenix 3. Go make some DSLs!

Slide 112

Slide 112

ABSTRACTION STO RY T E L L I N G πŸ“š

  1. Your code read like a story 2. We even see this in high-level goals of (e.g.) Phoenix 3. Go make some DSLs!

Slide 113

Slide 113

FIGHTING GenSoup

Slide 114

Slide 114

FIGHTING GenSoup πŸš«πŸ²βš”

Slide 115

Slide 115

FIGHTING GenSoup G O O D I N T E R FA C E S ! = G O O D A B S T R A C T I O N S

Slide 116

Slide 116

FIGHTING GenSoup G O O D I N T E R FA C E S ! = G O O D A B S T R A C T I O N S β€’ GenServer & co are actually pretty low level β€’ Add some semantics! β€’ Don’t reinvent the wheel every time 🎑 β€’ Let’s look at a very common example

Slide 117

Slide 117

FIGHTING GenSoup A B S T R A C T I O N β€” I N T E R FA C E / F R O N T E N D

Slide 118

Slide 118

FIGHTING GenSoup A B S T R A C T I O N β€” I N T E R FA C E / F R O N T E N D

Slide 119

Slide 119

FIGHTING GenSoup SIMPLE SYNCHRONOUS CASE (BACK END)

Slide 120

Slide 120

FIGHTING GenSoup A S Y N C C A S E β€” U N D E R LY I N G M E C H A N I C S

Slide 121

Slide 121

FIGHTING GenSoup A S Y N C C A S E β€” I M P L E M E N TAT I O N ( B A C K E N D )

Slide 122

Slide 122

FIGHTING GenSoup W H AT D I D W E G E T ?

Slide 123

Slide 123

FIGHTING GenSoup W H AT D I D W E G E T ? β€’ Common interface β€’ Encapsulate the detail β€’ Don’t have to think about mechanics anymore

Slide 124

Slide 124

FIGHTING GenSoup ABSTRACTION = FOCUS/ESSENCE

Slide 125

Slide 125

FIGHTING GenSoup ABSTRACTION = FOCUS/ESSENCE

Slide 126

Slide 126

FIGHTING GenSoup ABSTRACTION = FOCUS/ESSENCE πŸ™ˆ

Slide 127

Slide 127

LE T ’S DO SOME THING WILD

Slide 128

Slide 128

LE T ’S DO SOME THING WILD ⚑πŸ”₯ POWER UP πŸŒͺ🌊

Slide 129

Slide 129

POWER UP EXPLICIT ASSUMPTIONS

Slide 130

Slide 130

POWER UP EXPLICIT ASSUMPTIONS β€’ Parallel pipes

Slide 131

Slide 131

POWER UP EXPLICIT ASSUMPTIONS β€’ Parallel pipes β€’ Concurrency = partial order

Slide 132

Slide 132

POWER UP EXPLICIT ASSUMPTIONS β€’ Parallel pipes β€’ Concurrency = partial order t

Slide 133

Slide 133

POWER UP EXPLICIT ASSUMPTIONS β€’ Parallel pipes β€’ Concurrency = partial order t

Slide 134

Slide 134

POWER UP EXPLICIT ASSUMPTIONS β€’ Parallel pipes β€’ Concurrency = partial order t

Slide 135

Slide 135

POWER UP EXPLICIT ASSUMPTIONS β€’ Parallel pipes β€’ Concurrency = partial order t

Slide 136

Slide 136

POWER UP EXPLICIT ASSUMPTIONS β€’ Parallel pipes β€’ Concurrency = partial order t

Slide 137

Slide 137

POWER UP EXPLICIT ASSUMPTIONS β€’ Parallel pipes β€’ Concurrency = partial order β€’ Monotonic t

Slide 138

Slide 138

POWER UP EXPLICIT ASSUMPTIONS β€’ Parallel pipes β€’ Concurrency = partial order β€’ Monotonic β€’ Properties β€’ Serial composition β€’ Parallel composition β€’ Explicit evaluation strategy t

Slide 139

Slide 139

POWER UP PIPES++

Slide 140

Slide 140

POWER UP PIPES++

Slide 141

Slide 141

POWER UP PIPES++

Slide 142

Slide 142

POWER UP PIPES++

Slide 143

Slide 143

POWER UP P ROTO C O L / β€œ F RO N T E N D ”

Slide 144

Slide 144

POWER UP CLEANUP

Slide 145

Slide 145

POWER UP CLEANUP

Slide 146

Slide 146

POWER UP C A R R I E R D ATA

Slide 147

Slide 147

POWER UP C A R R I E R D ATA

Slide 148

Slide 148

POWER UP C A R R I E R D ATA

Slide 149

Slide 149

POWER UP C A R R I E R D ATA

Slide 150

Slide 150

POWER UP C A R R I E R D ATA

Slide 151

Slide 151

POWER UP SIMPLE CASE BACK END

Slide 152

Slide 152

POWER UP SIMPLE CASE BACK END

Slide 153

Slide 153

POWER UP SIMPLE CASE BACK END

Slide 154

Slide 154

POWER UP ASYNC BACK END

Slide 155

Slide 155

POWER UP ASYNC BACK END

Slide 156

Slide 156

POWER UP ASYNC BACK END

Slide 157

Slide 157

POWER UP ASYNC BACK END

Slide 158

Slide 158

POWER UP U P S H OT

Slide 159

Slide 159

POWER UP U P S H OT β€’ Higher semantic density (focused on meaning not mechanics)

Slide 160

Slide 160

POWER UP U P S H OT β€’ Higher semantic density (focused on meaning not mechanics) β€’ Declarative, configurable data flow 🀯

Slide 161

Slide 161

POWER UP U P S H OT β€’ Higher semantic density (focused on meaning not mechanics) β€’ Declarative, configurable data flow 🀯 β€’ Extremely extensible β€’defimpl Dataflow, for: %Stream{} β€’defimpl Dataflow, for: %Distributed{} β€’defimpl Dataflow, for: %Broadway{}

Slide 162

Slide 162

POWER UP U P S H OT β€’ Higher semantic density (focused on meaning not mechanics) β€’ Declarative, configurable data flow 🀯 β€’ Extremely extensible β€’defimpl Dataflow, for: %Stream{} β€’defimpl Dataflow, for: %Distributed{} β€’defimpl Dataflow, for: %Broadway{} β€’ Model-testable

Slide 163

Slide 163

POWER UP U P S H OT β€’ Higher semantic density (focused on meaning not mechanics) β€’ Declarative, configurable data flow 🀯 β€’ Extremely extensible β€’defimpl Dataflow, for: %Stream{} β€’defimpl Dataflow, for: %Distributed{} β€’defimpl Dataflow, for: %Broadway{} β€’ Model-testable β€’ Composable with other pipes and change evaluation strategies

Slide 164

Slide 164

A CALL FOR LIBRARIES

Slide 165

Slide 165

A CALL FOR LIBRARIES πŸ“£

Slide 166

Slide 166

A CALL FOR LIBRARIES EXTEND RAILROAD PROGRAMMING

Slide 167

Slide 167

A CALL FOR LIBRARIES EXTEND RAILROAD PROGRAMMING Happy Path (Continue) Error Case (Skip) No Effect (Afterwards)

Slide 168

Slide 168

A CALL FOR LIBRARIES EXTEND RAILROAD PROGRAMMING Happy Path (Continue) Error Case (Skip) No Effect (Afterwards)

Slide 169

Slide 169

A CALL FOR LIBRARIES EXTEND RAILROAD PROGRAMMING Happy Path (Continue) Error Case (Skip) No Effect (Afterwards)

Slide 170

Slide 170

A CALL FOR LIBRARIES S U R P R I S I N G N U M B E R O F FA C T O R S

Slide 171

Slide 171

A CALL FOR LIBRARIES S U R P R I S I N G N U M B E R O F FA C T O R S Log Program

Slide 172

Slide 172

A CALL FOR LIBRARIES S U R P R I S I N G N U M B E R O F FA C T O R S Log Program

Slide 173

Slide 173

SUMMARY

Slide 174

Slide 174

SUMMARY KEEP IN MIND

Slide 175

Slide 175

SUMMARY KEEP IN MIND 1. Protocols-for-DDD 2. Add a semantic layer 3. How do you locally test your distributed system? Look at the properties! 4. Under which conditions does your code work? What are your assumptions? 5. Prop testing is useful for structured abstractions 6. You should be able to code half-asleep

Slide 176

Slide 176

https://fission.codes https://talk .fission.codes https://tools.fission.codes 🌍 THANK YOU, INTERNE T πŸŽ‰ brooklyn@fission.codes g i t h u b . c o m /e x p e d e @expede