-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
1693 lines (1482 loc) · 108 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui"><title>Slow-Auto, Inconvenient-Semi</title><link rel="stylesheet" href="./reveal.js/dist/reset.css"><link rel="stylesheet" href="./reveal.js/dist/reveal.css"><link rel="stylesheet" href="./reveal.js/dist/theme/serif.css" id="theme"><!--This CSS is generated by the Asciidoctor reveal.js converter to further integrate AsciiDoc's existing semantic with reveal.js--><style type="text/css">.reveal div.right {
float: right
}
/* source blocks */
.reveal .listingblock.stretch > .content {
height: 100%
}
.reveal .listingblock.stretch > .content > pre {
height: 100%
}
.reveal .listingblock.stretch > .content > pre > code {
height: 100%;
max-height: 100%
}
/* auto-animate feature */
/* hide the scrollbar when auto-animating source blocks */
.reveal pre[data-auto-animate-target] {
overflow: hidden;
}
.reveal pre[data-auto-animate-target] code {
overflow: hidden;
}
/* add a min width to avoid horizontal shift on line numbers */
code.hljs .hljs-ln-line.hljs-ln-n {
min-width: 1.25em;
}
/* tables */
table {
border-collapse: collapse;
border-spacing: 0
}
table {
margin-bottom: 1.25em;
border: solid 1px #dedede
}
table thead tr th, table thead tr td, table tfoot tr th, table tfoot tr td {
padding: .5em .625em .625em;
font-size: inherit;
text-align: left
}
table tr th, table tr td {
padding: .5625em .625em;
font-size: inherit
}
table thead tr th, table tfoot tr th, table tbody tr td, table tr td, table tfoot tr td {
display: table-cell;
line-height: 1.6
}
td.tableblock > .content {
margin-bottom: 1.25em
}
td.tableblock > .content > :last-child {
margin-bottom: -1.25em
}
table.tableblock, th.tableblock, td.tableblock {
border: 0 solid #dedede
}
table.grid-all > thead > tr > .tableblock, table.grid-all > tbody > tr > .tableblock {
border-width: 0 1px 1px 0
}
table.grid-all > tfoot > tr > .tableblock {
border-width: 1px 1px 0 0
}
table.grid-cols > * > tr > .tableblock {
border-width: 0 1px 0 0
}
table.grid-rows > thead > tr > .tableblock, table.grid-rows > tbody > tr > .tableblock {
border-width: 0 0 1px
}
table.grid-rows > tfoot > tr > .tableblock {
border-width: 1px 0 0
}
table.grid-all > * > tr > .tableblock:last-child, table.grid-cols > * > tr > .tableblock:last-child {
border-right-width: 0
}
table.grid-all > tbody > tr:last-child > .tableblock, table.grid-all > thead:last-child > tr > .tableblock, table.grid-rows > tbody > tr:last-child > .tableblock, table.grid-rows > thead:last-child > tr > .tableblock {
border-bottom-width: 0
}
table.frame-all {
border-width: 1px
}
table.frame-sides {
border-width: 0 1px
}
table.frame-topbot, table.frame-ends {
border-width: 1px 0
}
.reveal table th.halign-left, .reveal table td.halign-left {
text-align: left
}
.reveal table th.halign-right, .reveal table td.halign-right {
text-align: right
}
.reveal table th.halign-center, .reveal table td.halign-center {
text-align: center
}
.reveal table th.valign-top, .reveal table td.valign-top {
vertical-align: top
}
.reveal table th.valign-bottom, .reveal table td.valign-bottom {
vertical-align: bottom
}
.reveal table th.valign-middle, .reveal table td.valign-middle {
vertical-align: middle
}
table thead th, table tfoot th {
font-weight: bold
}
tbody tr th {
display: table-cell;
line-height: 1.6
}
tbody tr th, tbody tr th p, tfoot tr th, tfoot tr th p {
font-weight: bold
}
thead {
display: table-header-group
}
.reveal table.grid-none th, .reveal table.grid-none td {
border-bottom: 0 !important
}
/* kbd macro */
kbd {
font-family: "Droid Sans Mono", "DejaVu Sans Mono", monospace;
display: inline-block;
color: rgba(0, 0, 0, .8);
font-size: .65em;
line-height: 1.45;
background: #f7f7f7;
border: 1px solid #ccc;
-webkit-border-radius: 3px;
border-radius: 3px;
-webkit-box-shadow: 0 1px 0 rgba(0, 0, 0, .2), 0 0 0 .1em white inset;
box-shadow: 0 1px 0 rgba(0, 0, 0, .2), 0 0 0 .1em #fff inset;
margin: 0 .15em;
padding: .2em .5em;
vertical-align: middle;
position: relative;
top: -.1em;
white-space: nowrap
}
.keyseq kbd:first-child {
margin-left: 0
}
.keyseq kbd:last-child {
margin-right: 0
}
/* callouts */
.conum[data-value] {
display: inline-block;
color: #fff !important;
background: rgba(0, 0, 0, .8);
-webkit-border-radius: 50%;
border-radius: 50%;
text-align: center;
font-size: .75em;
width: 1.67em;
height: 1.67em;
line-height: 1.67em;
font-family: "Open Sans", "DejaVu Sans", sans-serif;
font-style: normal;
font-weight: bold
}
.conum[data-value] * {
color: #fff !important
}
.conum[data-value] + b {
display: none
}
.conum[data-value]:after {
content: attr(data-value)
}
pre .conum[data-value] {
position: relative;
top: -.125em
}
b.conum * {
color: inherit !important
}
.conum:not([data-value]):empty {
display: none
}
/* Callout list */
.hdlist > table, .colist > table {
border: 0;
background: none
}
.hdlist > table > tbody > tr, .colist > table > tbody > tr {
background: none
}
td.hdlist1, td.hdlist2 {
vertical-align: top;
padding: 0 .625em
}
td.hdlist1 {
font-weight: bold;
padding-bottom: 1.25em
}
/* Disabled from Asciidoctor CSS because it caused callout list to go under the
* source listing when .stretch is applied (see #335)
* .literalblock+.colist,.listingblock+.colist{margin-top:-.5em} */
.colist td:not([class]):first-child {
padding: .4em .75em 0;
line-height: 1;
vertical-align: top
}
.colist td:not([class]):first-child img {
max-width: none
}
.colist td:not([class]):last-child {
padding: .25em 0
}
/* Override Asciidoctor CSS that causes issues with reveal.js features */
.reveal .hljs table {
border: 0
}
/* Callout list rows would have a bottom border with some reveal.js themes (see #335) */
.reveal .colist > table th, .reveal .colist > table td {
border-bottom: 0
}
/* Fixes line height with Highlight.js source listing when linenums enabled (see #331) */
.reveal .hljs table thead tr th, .reveal .hljs table tfoot tr th, .reveal .hljs table tbody tr td, .reveal .hljs table tr td, .reveal .hljs table tfoot tr td {
line-height: inherit
}
/* Columns layout */
.columns .slide-content {
display: flex;
}
.columns.wrap .slide-content {
flex-wrap: wrap;
}
.columns.is-vcentered .slide-content {
align-items: center;
}
.columns .slide-content > .column {
display: block;
flex-basis: 0;
flex-grow: 1;
flex-shrink: 1;
}
.columns .slide-content > .column > * {
padding: .75rem;
}
/* See #353 */
.columns.wrap .slide-content > .column {
flex-basis: auto;
}
.columns .slide-content > .column.is-full {
flex: none;
width: 100%;
}
.columns .slide-content > .column.is-four-fifths {
flex: none;
width: 80%;
}
.columns .slide-content > .column.is-three-quarters {
flex: none;
width: 75%;
}
.columns .slide-content > .column.is-two-thirds {
flex: none;
width: 66.6666%;
}
.columns .slide-content > .column.is-three-fifths {
flex: none;
width: 60%;
}
.columns .slide-content > .column.is-half {
flex: none;
width: 50%;
}
.columns .slide-content > .column.is-two-fifths {
flex: none;
width: 40%;
}
.columns .slide-content > .column.is-one-third {
flex: none;
width: 33.3333%;
}
.columns .slide-content > .column.is-one-quarter {
flex: none;
width: 25%;
}
.columns .slide-content > .column.is-one-fifth {
flex: none;
width: 20%;
}
.columns .slide-content > .column.has-text-left {
text-align: left;
}
.columns .slide-content > .column.has-text-justified {
text-align: justify;
}
.columns .slide-content > .column.has-text-right {
text-align: right;
}
.columns .slide-content > .column.has-text-left {
text-align: left;
}
.columns .slide-content > .column.has-text-justified {
text-align: justify;
}
.columns .slide-content > .column.has-text-right {
text-align: right;
}
.text-left {
text-align: left !important
}
.text-right {
text-align: right !important
}
.text-center {
text-align: center !important
}
.text-justify {
text-align: justify !important
}
.footnotes {
border-top: 1px solid rgba(0, 0, 0, 0.2);
padding: 0.5em 0 0 0;
font-size: 0.65em;
margin-top: 4em;
}
.byline {
font-size:.8em
}
ul.byline {
list-style-type: none;
}
ul.byline li + li {
margin-top: 0.25em;
}
</style><script>window.MathJax = {"tex":{"inlineMath":[["\\(", "\\)"]], "displayMath":[["\\[", "\\]"]], "processEscapes":false, "tags":"none"}, "options":{"ignoreHtmlClass":"nostem|nolatexmath"}, "asciimath":{"delimiters":[["\\$", "\\$"]]}, "loader":{"load":["input/asciimath", "output/chtml", "ui/menu"]}};</script><script async src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/3.2.0/es5/tex-mml-chtml.js"></script></head><body><div class="reveal"><div class="slides"><section class="title" data-state="title"><h1>Slow-Auto, Inconvenient-Semi</h1><div class="preamble"><div class="paragraph"><p><strong>escaping false dichotomy with sanely-automatic derivation</strong></p></div>
<hr>
<div class="paragraph"><p>Mateusz Kubuszok</p></div>
<aside class="notes"><div class="paragraph"><p>Most of you probably used some Scala library based on type class derivation.</p></div>
<div class="paragraph"><p>Most of you probably started with so-called automatic derivation, and at some point it bite you with long compilation times or hard to debuf errors.</p></div>
<div class="paragraph"><p>Some of you moved to moved to so-called semi-automatic derivation, which is much more clumsy, but tries to solve some of the issues with automatic derivation.</p></div>
<div class="paragraph"><p>In this presentation, I’ll try to show that all of these issues are not some inherent cost of using type class derivation, but that we all did it wrong.</p></div></aside></div></section>
<section id="_about_me"><h2>About me</h2><div class="slide-content"><div class="ulist"><ul><li class="fragment"><p>breaking things in Scala for 9 years</p></li><li class="fragment"><p>a little bit of open source - including co-authoring Chimney for over 7 years now</p></li><li class="fragment"><p>blog at <a href="https://kubuszok.com">Kubuszok.com</a></p></li><li class="fragment"><p>niche <a href="https://leanpub.com/jvm-scala-book">Things you need to know about JVM (that matter in Scala)</a> ebook</p></li></ul></div>
<aside class="notes"><div class="paragraph"><p>I’ve been working with Scala for over 9 years,</p></div>
<div class="paragraph"><p>and 7 of them I’ve been a maintainer of a library with rather complex metaprogramming.</p></div>
<div class="paragraph"><p>Additionally, I’ve been blogging, speaking at meetups and conferences like this one, and also wrote a book about Scala and JVM, so maybe I am not here by accident.</p></div>
<div class="paragraph"><p>But enough about me. Let’s see today’s game plan.</p></div></aside></div></section>
<section><section id="_agenda"><h2>Agenda</h2><div class="slide-content"><div class="ulist"><ul><li class="fragment"><p>what is a <strong>type class</strong></p></li><li class="fragment"><p>what is type class <strong>derivation</strong></p></li><li class="fragment"><p><strong>automatic</strong> and <strong>semi-automatic</strong> derivation a’la Circe</p></li><li class="fragment"><p>semi-automatic derivation a’la Jsoniter</p></li><li class="fragment"><p>sanely-automatic derivation a’la Chimney</p></li><li class="fragment"><p>does it matter to a <strong>library users</strong> how these approach differ</p></li></ul></div><aside class="notes"><div class="paragraph"><p>We’ll start with <em>briefly</em> saying what is a type-class, since <em>some</em> of you might not be familiar with the term.</p></div>
<div class="paragraph"><p>Then we explain what we mean by <em>type class derivation</em>, because it has nothing to do with integrals and calculus.</p></div>
<div class="paragraph"><p>Then we take a look at what people mean by automatic and semi-automatic derivation - in libraries which almost always followed Circe’s approach.</p></div>
<div class="paragraph"><p>Then we show that not all libraries follow this approach, when it comes to semi-automatic derivation.</p></div>
<div class="paragraph"><p>And some libraries have some improvements also when it comes to automatic derivation.</p></div>
<div class="paragraph"><p>Hopefully, by the end of this talk, you will understand that how the library’s author implement the whole mechanics, impacts you, the users.</p></div>
<div class="paragraph"><p>But I have to worn you, this is not Shapeless/Mirrors/Magnolia/or macros tutorial.</p></div></aside></div></section><section id="_examples"><h2>Examples</h2><div class="slide-content"><div class="imageblock"><img src="img/qr-code.png" alt="Link to examples" width="40%" height="40%"></div>
<div class="paragraph"><p><a href="https://github.com/MateuszKubuszok/derivation-benchmarks" class="bare">https://github.com/MateuszKubuszok/derivation-benchmarks</a></p></div>
<aside class="notes"><div class="paragraph"><p>We will be talking how these design choices of library’s authors affect you, the users.</p></div>
<div class="paragraph"><p>If you are curious about the code that generated the numbers or error messages, everything that we compare,
you can take a look at this link, and investigate the code at your own pace.</p></div>
<div class="paragraph"><p>As an excercise for the reader.</p></div>
<div class="paragraph"><p>So let’s start.</p></div></aside></div></section></section>
<section><section id="_type_class"><h2>Type class</h2><div class="slide-content"><div class="ulist"><ul><li class="fragment"><p>interface</p></li><li class="fragment"><p>with type paremeters</p></li><li class="fragment"><p>whose implementation can be automatically provided based on their type only</p></li></ul></div><aside class="notes"><div class="paragraph"><p>Type class, what it is?</p></div>
<div class="paragraph"><p>As far as I care it is an interface.</p></div>
<div class="paragraph"><p>But it’s an interface with some type parameter.</p></div>
<div class="paragraph"><p>So that each implementation,that we’d use, could be distinguished only by type, and we could let the compiler pass it around for us.</p></div>
<div class="paragraph"><p>For example.</p></div></aside></div></section><section><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">trait Encoder[A] {
def apply(a: A): Json // <-- JSON as data
}
object Encoder {
given encodeString: Encoder[String] = ...
given encodeInt: Encoder[Int] = ...
given encodeDouble: Encoder[Double] = ...
}</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">extension [A](value: A) {
def asJson(using encoder: Encoder[A]): Json = encoder(value)
}</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">"value".asJson // using Encoder.encodeString
1024.asJson // using Encoder.encodeInt
3.13.asJson // using Encoder.encodeDouble</code></pre></div></div>
<aside class="notes"><div class="paragraph"><p>We has some data type representing JSONs.</p></div>
<div class="paragraph"><p>We want to be able to encode our type, whatever it is, to JSON.</p></div>
<div class="paragraph"><p>For starters, we have implementation for the primitives.</p></div>
<div class="paragraph"><p>And some extension methods, so that the code would look nice.</p></div>
<div class="paragraph"><p>Then with the mechanism called <code>implicit</code> s or, on Scala 3, <code>using</code> and <code>given</code>, these implementations can be passed for us automatically.</p></div>
<div class="paragraph"><p>However, we only provided some implementations. (next slide)</p></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>What if nobody wrote the implementation explicitly for <strong>my type</strong>?</p></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">case class Address(value: String)
case class User(name: String, address: Address)</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">Address("Paper St. 19").asJson // ???
User("John Smith", Address("Paper St. 19")).asJson // ???</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true">No given instance of type Encoder[Address] was found for parameter encoder of
method asJson in object ...
No given instance of type Encoder[User] was found for parameter encoder of
method asJson in object ...</code></pre></div></div>
<aside class="notes"><div class="paragraph"><p>What if nobody wrote the implementation explicitly for <strong>my type</strong>?</p></div>
<div class="paragraph"><p>We can have, some <code>Address</code> and some <code>User</code> defined.</p></div>
<div class="paragraph"><p>What is going to happen when we try to encode them?</p></div>
<div class="paragraph"><p>The answer is that the compilation would fail. Because there are no implementations for these types.</p></div>
<div class="paragraph"><p>That’s where the derivation comes in.</p></div></aside></div></section></section>
<section><section id="_type_class_derivation"><h2>Type class derivation</h2><div class="slide-content"><div class="imageblock"><img src="img/derivation.png" alt="Derivation" width="100%" height="100%"></div><div class="paragraph small"><small>(If you don’t understand this diagram, you probably haven’t spend 600h on a topic that most sane people avoid.)</small></div><aside class="notes"><div class="paragraph"><p>Type class derivation.</p></div>
<div class="paragraph"><p>We’ll have several of these pictures, which you can study at your own pace at home.</p></div>
<div class="paragraph"><p>For now what I want you to remember:</p></div>
<div class="ulist"><ul><li><p>derivation is about picking the implementations for some parts of your type, and combining them together into the implementation for the whole type</p></li><li><p>for <code>case class</code> es, it means that you have to have an implementation for each field’s type</p></li><li><p>for <code>sealed trait</code> s and <code>enum</code> s, it means that you have to have implementation for each subtype</p></li><li><p>because it combines the implementations from bottom-up someone, usually, the library’s author have to provide implementations for the smallest blocks, usualy primitives</p></li><li><p>and, because there is no magic, someone has to define how these small blocks can be combined, usually that’s also the author of the library</p></li><li><p>and if that sounds confusing, it only because you haven’t spend way too much time on this subject</p></li></ul></div>
<div class="paragraph"><p>Maybe some example would help.</p></div></aside></div></section><section id="_derivation_ala_circe"><h2>Derivation a’la Circe</h2></section><section><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">trait Encoder[A] {
def apply(a: A): Json // <-- JSON as data
}</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">extension [A](value: A) {
def asJson(using encoder: Encoder[A]): Json = encoder(value)
}</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">case class Address(value: String)
case class User(name: String, address: Address)</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">Address("Paper St. 19")
// { "value": "Paper St. 19" }
User("John Smith", Address("Paper St. 19"))
// { "name": "John Smith", "address": { "value": "Paper St. 19" } }</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">import MagicImportOfSomethingThatCreatesEncoders.given
Address("Paper St. 19").asJson // generates Encoder[Address] on demand
User("John Smith", Address("Paper St. 19")).asJson // ditto but for User</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">import ImportOfSomethingThatLetsYouCreateEncoders.deriveEncoder
given addressEncoder: Encoder[Address] = deriveEncoder[Address]
given userEncoder: Encoder[User] = deriveEncoder[User]
Address("Paper St. 19").asJson // using addressEncoder
User("John Smith", Address("Paper St. 19")).asJson // using userEncoder</code></pre></div></div>
<aside class="notes"><div class="paragraph"><p>As a reminder, we have this <code>Encoder</code>, which should turn your <code>case class</code> into JSON.</p></div>
<div class="paragraph"><p>It has this nice extension method.</p></div>
<div class="paragraph"><p>And we want to encode these `case class`es.</p></div>
<div class="paragraph"><p>The library’s author has some assumption, like for instance, that each <code>case class</code> should be encoded as JSON object. Each field’s name would turn into that object’s key, and value, should be encoded, with the encoder for its type.</p></div>
<div class="paragraph"><p>Automatic derivation assumes that all the missing implementations, that you have not provided yourself have an automatic fallback, often enabled with an import. You add that import, fallback becomes available in the implicit scope, and everything works. (Sometimes, this is implemented in the compation objects and then it cannot be disabled).</p></div>
<div class="paragraph"><p>Semi-automatic derivation assumes that you want to define these implicits yourself, but you don’t want to write their implementation. It gives you some method, which would give you a new implementation, and even if there is implicit of a demanded type in scope, it ignores it. (So that you won’t end up with cyclical dependeny in the initialization).</p></div>
<div class="paragraph"><p>If you will not write thise implicits/givens yourself, you’ll keep on getting implicit not found.</p></div>
<div class="paragraph"><p>But let’s take a look a bit closer.</p></div></aside></div></section><section id="_automatic_derivation_of_address" class="small-h2"><h2>Automatic derivation of Address</h2><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">implicitly[Encoder[Address]] // <-- using Encoder[Address]</code></pre></div></div>
<div class="imageblock"><img src="img/automatic-derivation-of-Address.png" alt="Automatic Derivation of Address" width="100%" height="100%"></div>
<aside class="notes"><div class="paragraph"><p>What happens when we try to summon an instance with automatic derivation? Using <code>Address</code> as an example.</p></div>
<div class="paragraph"><p>(Reminder: this and the following diagrams are also something you can study at your own pace at home.)</p></div>
<div class="paragraph"><p>First of all, automatic derivation should be a fallback, so the compiler tries to find some existing implementation and failed.</p></div>
<div class="paragraph"><p>Then, it sees that we have a <code>case class</code>, and we just happen to have some mechanism implemented by authors which would</p></div>
<div class="ulist"><ul><li><p>obtain the implementation for each field</p></li><li><p>combine them together</p></li></ul></div>
<div class="paragraph"><p>Now, the semi-automatic.</p></div></aside></div></section><section id="_semi_automatic_derivation_of_address" class="small-h2"><h2>Semi-automatic derivation of Address</h2><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">deriveEncoder[Address] // <-- creates new Encoder[Address]</code></pre></div></div>
<div class="imageblock"><img src="img/semi-automatic-derivation-of-Address.png" alt="Semi-automatic Derivation of Address" width="100%" height="100%"></div>
<aside class="notes"><div class="paragraph"><p>Here, we can see that there is no, try-existing-then-use-fallback part. We moved directly into creating new instance.</p></div>
<div class="paragraph"><p>If it cannot be created, the compilation fails, even if such instance exist and is in scope.</p></div>
<div class="paragraph"><p>Is there any difference when you try these approach with <code>User</code>.</p></div></aside></div></section><section id="_automatic_derivation_of_user" class="small-h2"><h2>Automatic derivation of User</h2><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">implicitly[Encoder[User]] // <-- using Encoder[User]</code></pre></div></div>
<div class="imageblock"><img src="img/automatic-derivation-of-User.png" alt="Automatic Derivation of User" width="100%" height="100%"></div>
<aside class="notes"><div class="paragraph"><p>Well, there is, the diagram is much bigger. Why?</p></div>
<div class="paragraph"><p>Because, with automatic derivation in scope the compiler automatically, as a fallback, not only the implementation for the type we asked for, but also implementations for the types nested in this type.</p></div>
<div class="paragraph"><p>Here, it triggers the automatic derivation of <code>Address</code>.</p></div>
<div class="paragraph"><p>Is it try for semi-automatic derivation as well?</p></div></aside></div></section><section id="_semi_automatic_derivation_of_user" class="small-h2"><h2>Semi-automatic derivation of User</h2><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">deriveEncoder[User] // <-- creates new Encoder[User]</code></pre></div></div>
<div class="imageblock"><img src="img/semi-automatic-derivation-of-User.png" alt="Semi-automatic Derivation of User" width="100%" height="100%"></div>
<aside class="notes"><div class="paragraph"><p>No. If we haven’t imported automatic derivation next to semi-automatic, if we didn’t create that implicit <code>Encoder</code> of <code>Address</code>, the compilation would fail.</p></div>
<div class="paragraph"><p>Semi-automatic derivation in Circe, and libraries based on its approach, are not recursive.</p></div>
<div class="paragraph"><p>In case you look at all of this, and as yourself…​ <em>(next slide)</em></p></div></aside></div></section></section>
<section><section id="_ok_but_where_is_the_code"><h2>OK, but where is the code?</h2><div class="slide-content"><div class="paragraph"><p>Wouldn’t it be easier to understand with some examples?</p></div><aside class="notes"><div class="paragraph"><p>…​where is the code?</p></div>
<div class="paragraph"><p>Reminder: <em>(next slide)</em></p></div></aside></div></section><section id="_1_we_are_focusing_on_user_side_of_the_derivation_story"><h2>1. We are focusing on user-side of the derivation story</h2><div class="slide-content"><aside class="notes"><div class="paragraph"><p>One. Our goal is it see how something that we didn’t wrote but someone else affect us.</p></div></aside></div></section><section id="_2_code_is_in_the_link"><h2>2. Code is in the link</h2><div class="slide-content"><div class="imageblock"><img src="img/qr-code.png" alt="Link to examples" width="40%" height="40%"></div>
<div class="paragraph"><p><a href="https://github.com/MateuszKubuszok/derivation-benchmarks" class="bare">https://github.com/MateuszKubuszok/derivation-benchmarks</a></p></div>
<aside class="notes"><div class="paragraph"><p>Two. You can look at the code whenever you want.</p></div></aside></div></section><section id="_3_if_you_really_need_the_derivation_internals_explanation_experience" class="small-h2 columns"><h2>3. If you really need the derivation-internals-explanation-experience</h2><div class="slide-content"><div class="imageblock column fragment"><img src="img/3-hours-later.jpg" alt="3h later" width="80%" height="80%"></div>
<div class="imageblock column fragment"><img src="img/everyday-we-stray-further-from-god.png" alt="3h later" width="80%" height="80%"></div>
<aside class="notes"><div class="paragraph"><p>If we actually try to show it, and explain it during this presentation.</p></div>
<div class="paragraph"><p>It would take half the conference.</p></div>
<div class="paragraph"><p>The whole audience would be traumatised, and we would still not get to the point I’m trying to make.</p></div>
<div class="paragraph"><p>So, getting back to the main topic.</p></div></aside></div></section></section>
<section><section id="_why_people_bother_with_semi_automatic_derivation"><h2>Why people bother with semi-automatic derivation?</h2></section><section id="_1_they_want_to_make_sure_that_they_use_the_same_implementation_everywhere"><h2>1. They want to make sure that they use the same implementation everywhere</h2><div class="slide-content"><aside class="notes"><div class="paragraph"><p>We’re not going to question that use case. If you want to have the same implementation everywhere, you define it only once and reuse.</p></div></aside></div></section><section id="_2_speed"><h2>2. "Speed"</h2><div class="slide-content"><aside class="notes"><div class="paragraph"><p>But the other reason people have strong preference for semi is speed.</p></div>
<div class="paragraph"><p>There were a lot of horror stories about a single implicit compiling for several minutes. (I saw some myself).</p></div>
<div class="paragraph"><p>A lot of people did investigation - compiler benchmarks, flame graphs, time spend in different compilation phases - and found that the cause is automatic derivation.</p></div>
<div class="paragraph"><p>Semi-automatic derivation solved their problems.</p></div>
<div class="paragraph"><p>But is it still true today?</p></div></aside></div></section><section><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">// We're use Circe:
// trait Encoder[A] { ... } turns A -> Json
// trait Decoder[A] { ... } turns Json -> Either[Decoder.DecodingError, A]
case class Out(...) // <-- really big case class with nested case classes
// value -> Json -> value again
def roundTrip(out: Out): (Json, Either[Decoder.DecodingError, Out]) = {
val json = out.asJson // <-- encode as Json using Encoder[Out]
val parsed = json.as[Out] // <-- decode from Json using Decoder[Out]
json -> parsed
}</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">// Semi-automatic version will just have this:
implicit val in1Decoder: Decoder[In1] = deriveDecoder
implicit val in1Encoder: Encoder[In1] = deriveEncoder
implicit val in2Decoder: Decoder[In2] = deriveDecoder
implicit val in2Encoder: Encoder[In2] = deriveEncoder
implicit val in3Decoder: Decoder[In3] = deriveDecoder
implicit val in3Encoder: Encoder[In3] = deriveEncoder
implicit val in4Decoder: Decoder[In4] = deriveDecoder
implicit val in4Encoder: Encoder[In4] = deriveEncoder
implicit val in5Decoder: Decoder[In5] = deriveDecoder
implicit val in5Encoder: Encoder[In5] = deriveEncoder
implicit val outDecoder: Decoder[Out] = deriveDecoder
implicit val outEncoder: Encoder[Out] = deriveEncoder
// instead of automatic derivation import.</code></pre></div></div>
<div class="paragraph fragment"><p>This shouldn’t be hard on compiler?</p></div>
<aside class="notes"><div class="paragraph"><p>I defined some very mean nested case class. All you need to know that it’s 5 levels of nesting deep.</p></div>
<div class="paragraph"><p>I want to use Circe, both Encoder and Decoder, and do a round trip - encode this case class, and then decode it, for example to test if I get the same value or do some benchmarks.</p></div>
<div class="paragraph"><p>I try to do it once with automatic derivation, and once with semi-automatic approach.</p></div>
<div class="paragraph"><p>Both will be single-file modules which only generate a few codecs. How bad it can be?</p></div></aside></div></section><section><div class="slide-content"><div class="imageblock"><img src="img/json-compilation-times-1.png" alt="Json Compilation Times" width="80%" height="80%"></div>
<div class="paragraph small"><small>(less is better)</small></div>
<aside class="notes"><div class="paragraph"><p>On Scala 2.13, not so bad. The compilation times are quite close, not deserving the bad press.</p></div>
<div class="paragraph"><p>Of course, if we ignore the fact that both need at least 12 seconds on cold JVM to compile a single short file.</p></div>
<div class="paragraph"><p>But on Scala 3 with automatic we have 46 seconds to compile a single file on cold JVM! On the other hand semi-auto works much faster!</p></div>
<div class="paragraph"><p>What about runtime?</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true"> Scala 2 Scala 3 Units
compilation of cold hot cold hot
circeGenericAuto 14 4 46 16 s
circeGenericSemi 12 3 10 1 s
circeMagnoliaAuto 13 2 65 32 s
circeMagnoliaSemi 12 7 12 2 s
jsoniterScalaSanely - - 9 1 s
jsoniterScalaSemi 10 4 8 1 s</code></pre></div></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Scala 2.13.14</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] JsonRoundTrips.circeGenericAuto thrpt 10 7.319 ± 0.011 ops/ms
[info] JsonRoundTrips.circeGenericSemi thrpt 10 6.775 ± 0.013 ops/ms</code></pre></div></div>
<div class="paragraph"><p>Scala 3.3.3</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] JsonRoundTrips.circeGenericAuto thrpt 10 0.490 ± 0.432 ops/ms
[info] JsonRoundTrips.circeGenericSemi thrpt 10 4.607 ± 0.014 ops/ms</code></pre></div></div>
<div class="paragraph small"><small>(more is better)</small></div>
<aside class="notes"><div class="paragraph"><p>Scala 2.13 has very small differences between auto and semi in benchmarks as well.</p></div>
<div class="paragraph"><p>Scala 3 on the other hand…​ semi-automatic derivation 1/3rd slower than Scala 2.13!</p></div>
<div class="paragraph"><p>But the automatic derivation is a disaster - an order of magnitude slower than that.</p></div>
<div class="paragraph"><p>Can we example these results?</p></div></aside></div></section><section id="_auto_vs_semi_on_scala_2" class="small-h2"><h2>Auto vs Semi on Scala 2</h2><div class="slide-content"><div class="ulist small"><ul><li class="fragment"><p><a href="https://github.com/scala/scala/pull/5649">PR #5649</a> - <em>Faster compilation of inductive implicits</em> (closed)</p></li><li class="fragment"><p><a href="https://github.com/scala/scala/pull/6481">PR #6481</a> - <em>Topic/inductive implicits 2.13.x</em> (closed)</p></li><li class="fragment"><p><a href="https://github.com/scala/scala/pull/6580">PR #6580</a> - <em>Prune polymorphic implicits more aggressively</em> (merged)</p></li><li class="fragment"><p><a href="https://github.com/scala/scala/pull/7012">PR #7012</a> - <em>Speed up implicit resolution by avoiding allocations when traversing TypeRefs in core</em> (merged)</p></li><li class="fragment"><p>and more</p></li></ul></div>
<div class="listingblock small fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala"> 1) baseline - scalac 2.13.x 2) scalac 2.13.x with matchesPtInst
HList Size
50 4 3
100 7 3
150 15 4
200 28 4
250 48 5
300 81 6
350 126 8
400 189 11
450 322 13
500 405 16 Compile time in seconds</code></pre></div></div>
<aside class="notes"><div class="paragraph"><p>Autor of Shapeless spend a lot of time contributing to the compiler, to optimize the implici resolution. He made a whole series of PRs.</p></div>
<div class="paragraph"><p>2 of them got closed, but the 3rd one finally got merged and released as a part of 2.13.0-M5.</p></div>
<div class="paragraph"><p>And then there was another one.</p></div>
<div class="paragraph"><p>We can see that he was pretty happy with the result because we boasted how the compilation times went down.</p></div>
<div class="paragraph"><p>Some of that work was ported to Scala 3 but perhaps not everything, or maybe these opimization do not play well with how Mirrors work.</p></div>
<div class="paragraph"><p>And all the bad press that automatic derivation has comes probably from before these PRs. Or maybe people were deriving exactly the same implicit 50 times.</p></div>
<div class="paragraph"><p>Putting these optimizations aside <em>(next slide)</em></p></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Could something else improve performance?</p></div>
<aside class="notes"><div class="paragraph"><p>Before Scala 3, some people believed that yes. For instance replacing Shapeless.</p></div></aside></div></section></section>
<section><section id="_magnolia"><h2>Magnolia</h2><div class="slide-content"><div class="ulist"><ul><li class="fragment"><p>alternative to Shapeless/Mirrors</p></li><li class="fragment"><p>boasts about:</p><div class="ulist"><ul><li><p>better API</p></li><li><p>better performance</p></li><li><p>better compilation times</p></li><li><p>better error messages when derivation fail</p></li></ul></div></li></ul></div><aside class="notes"><div class="paragraph"><p>Was created as an alternative to Shapeless for the most common use cases,</p></div>
<div class="paragraph"><p>with better API, performance, compilation times, and error messages.</p></div>
<div class="paragraph"><p>Let’s start with the last claim.</p></div></aside></div></section><section id="_error_messages" class="small"><h2>Error messages</h2><div class="slide-content"><div class="paragraph"><p>Semi-automatic derivation</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">case class Street(name: Either[String, Nothing]) // <-- should not be able to derive name
case class Address(street: Street)
case class User(name: String, address: Address)</code></pre></div></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">implicit val streetEncoder: Encoder[Street] = deriveEncoder
implicit val addressEncoder: Encoder[Address] = deriveEncoder
implicit val userEncoder: Encoder[User] = deriveEncoder
user.asJson</code></pre></div></div>
<div class="paragraph"><p>Shapeless' errors</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">could not find Lazy implicit value of type DerivedAsObjectEncoder[Street]
implicit val streetEncoder: Encoder[Street] = deriveEncoder
^</code></pre></div></div>
<div class="paragraph"><p>Mirrors' errors</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala"> implicit val streetEncoder: Encoder[Street] = deriveEncoder
^^^^^^^^^^^^^
Failed to find an instance of Encoder[Either[String, Nothing]]</code></pre></div></div>
<div class="paragraph"><p>Magnolia’s errors</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">magnolia: could not find Encoder.Typeclass for type Either[String,Nothing]
in parameter 'name' of product type Street
implicit val streetEncoder: Encoder[Street] = EncoderSemi.derived
^</code></pre></div></div>
<aside class="notes"><div class="paragraph"><p>Here we have some nested case classes - <code>User</code> has <code>Address</code>, <code>Address</code> has <code>Street</code>,
where the last one stores <code>Nothing</code> in a field and cannot be encoded out of the box.</p></div>
<div class="paragraph"><p>What kind of errors we’ll get?</p></div>
<div class="paragraph"><p>Shapeless tells us that it cannot find implicit for the <code>Street</code> type.</p></div>
<div class="paragraph"><p>Mirrors tell us that it cannot find implicit for the type of bad field (without naming that field and which class has it, but at least we know the location).</p></div>
<div class="paragraph"><p>Magnolia tells us which field has a type that cannot be encoded, and in which case class this field is defined. Nice!</p></div>
<div class="paragraph"><p>But it’s semi-automatic derivation. What about automatic?</p></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Automatic derivation</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">case class Street(name: Either[String, Nothing])
case class Address(street: Street)
case class User(name: String, address: Address)
user.asJson</code></pre></div></div>
<div class="paragraph"><p>Shapeless/Mirrors/Magnolia</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">could not find implicit value for parameter encoder: Encoder[User]
user.asJson
^</code></pre></div></div>
<aside class="notes"><div class="paragraph"><p>Unfortunatelly, no matter which library we used, none of them could tell us anything useful: implicit not found for <code>User</code>.</p></div>
<div class="paragraph"><p>All of them are equaly unhelpful.</p></div>
<div class="paragraph"><p>Ok, so let’s take a look at the compilation times.</p></div></aside></div></section><section id="_round_trip_reminder"><h2>Round trip (reminder)</h2><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">// Out - the outerermost of a deep nested, nasty case class structure
def roundTrip(out: Out): (Json, Result[Out]) = {
val json = out.asJson // encode
val parsed = json.as[Out] // decode
json -> parsed
}</code></pre></div></div></div></section><section><div class="slide-content"><div class="imageblock"><img src="img/json-compilation-times-2.png" alt="Json Compilation Times" width="80%" height="80%"></div>
<div class="paragraph small"><small>(less is better)</small></div>
<aside class="notes"><div class="paragraph"><p>Perhaps at the times of Scala 2.12 the difference was bigger, but it seems that the compilation times on Scala 2.13 are close.</p></div>
<div class="paragraph"><p>The small spike on hot JVM might be an error.</p></div>
<div class="paragraph"><p>But something weird happens on Scala 3, Magnolia is <em>always</em> worse than Mirrors! Why?</p></div>
<div class="paragraph"><p>Because on Scala 3 it was implemented with Mirrors so it adds its own overhead on top of Mirrors.</p></div>
<div class="paragraph"><p>How about benchmarks?</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true"> Scala 2 Scala 3 Units
compilation of cold hot cold hot
circeGenericAuto 14 4 46 16 s
circeGenericSemi 12 3 10 1 s
circeMagnoliaAuto 13 2 65 32 s
circeMagnoliaSemi 12 7 12 2 s
jsoniterScalaSanely - - 9 1 s
jsoniterScalaSemi 10 4 8 1 s</code></pre></div></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Scala 2.13.14</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] JsonRoundTrips.circeGenericAuto thrpt 10 7.319 ± 0.011 ops/ms
[info] JsonRoundTrips.circeGenericSemi thrpt 10 6.775 ± 0.013 ops/ms
[info] JsonRoundTrips.circeMagnoliaAuto thrpt 10 7.689 ± 0.013 ops/ms
[info] JsonRoundTrips.circeMagnoliaSemi thrpt 10 7.838 ± 0.013 ops/ms</code></pre></div></div>
<div class="paragraph"><p>Scala 3.3.3</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] JsonRoundTrips.circeGenericAuto thrpt 10 0.490 ± 0.432 ops/ms
[info] JsonRoundTrips.circeGenericSemi thrpt 10 4.607 ± 0.014 ops/ms
[info] JsonRoundTrips.circeMagnoliaAuto thrpt 10 0.077 ± 0.039 ops/ms
[info] JsonRoundTrips.circeMagnoliaSemi thrpt 10 5.590 ± 0.013 ops/ms</code></pre></div></div>
<div class="paragraph small"><small>(more is better)</small></div>
<aside class="notes"><div class="paragraph"><p>There are some small differences on Scala 2.13, Magnolia is a bit faster, but still, results are very close.</p></div>
<div class="paragraph"><p>On Scala 3, semi-automatic Magnolia seem to doo better than semi-automatic Mirrors, curious, but automatic Magnolia is order or magnitude slower than even automatic Mirrors!</p></div>
<div class="paragraph"><p>I suspect that it might be about inlining, a bit too much inlining.</p></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Shapeless/Mirrors/Magnolia - different APIs, same approach.</p></div>
<div class="paragraph"><p>Did anyone try something else?</p></div>
<aside class="notes"><div class="paragraph"><p>It seems that Shapeless/Mirrors/Magnolia are offering mostly different APIs - we don’t care about that in this talk.</p></div>
<div class="paragraph"><p>They have slightly different errors with semi-automatic derivation.</p></div>
<div class="paragraph"><p>Sometimes ridiculous performance on Scala 3 with automatic derivation.</p></div>
<div class="paragraph"><p>But for us, users, it’s mostly the same DX.</p></div>
<div class="paragraph"><p>Did anyone try something else?</p></div></aside></div></section></section>
<section><section id="_jsoniter_scala"><h2>Jsoniter Scala</h2><div class="slide-content"><div class="ulist"><ul><li class="fragment"><p>prioritizes <strong>performance</strong></p></li><li class="fragment"><p><strong>no automatic</strong> derivation</p></li><li class="fragment"><p><strong>no need</strong> to derive <strong>intermediate</strong> instances</p></li></ul></div><div class="paragraph fragment"><p>How?</p></div><aside class="notes"><div class="paragraph"><p>Jsoniter Scala is a library which has performance at heart.</p></div>
<div class="paragraph"><p>It intentionally has no automatic derivation - why? Because intermediate type class instances can hurt performance.</p></div>
<div class="paragraph"><p>But how you can have no intermediate instances, for intermediate types? Apparently Jsoniter handles it somehow.</p></div>
<div class="paragraph"><p>How?</p></div></aside></div></section><section><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">// Yes, only 1 codec, no need to manually derive implicits for nested cases
implicit val outCodec: JsonValueCodec[Out] =
JsonCodecMaker.make(CodecMakerConfig.withAllowRecursiveTypes(true))
def roundTrip(out: Out): (String, Either[Throwable, Out]) = {
val str = writeToString(out)
val parsed = scala.util.Try(readFromString(str)).toEither
str -> parsed
}</code></pre></div></div>
<aside class="notes"><div class="paragraph"><p>Quite simply: its semiautomatic derivation is recursive and handles intermediate types in the same macro expansion.</p></div>
<div class="paragraph"><p>You tell it to derive an implicit and it will handle all the nested case classes, and so on, inside that implicit implementation.</p></div>
<div class="paragraph"><p>So the mechanism is a bit different to what we see in Circe-like libraries.</p></div></aside></div></section><section id="_recursive_semi_automatic_derivation" class="small-h2"><h2>Recursive semi-automatic derivation</h2><div class="slide-content"><div class="imageblock"><img src="img/recursive-macro-derivation.png" alt="Recursive Macro Derivation"></div>
<aside class="notes"><div class="paragraph"><p>If we look at this diagram it looks more complex.</p></div>
<div class="paragraph"><p>Why? Because everything that was delegated before on the compiler, typer and implicit search is now handled "manually" in the same macro, with if-elses, loop, or good old recursion.</p></div>
<div class="paragraph"><p>If we zoom out a bit…​ <em>(next slide)</em></p></div></aside></div></section><section id="_recursive_semi_automatic_derivation_2" class="small-h2 columns"><h2>Recursive semi-automatic derivation</h2><div class="slide-content"><div class="openblock column"><div class="content"><div class="imageblock"><img src="img/derivation.png" alt="Derivation"></div>
<div class="ulist small"><ul><li><p>delegates everything to implicit search</p></li><li><p>types supported OOTB are handled via implicits in companion object</p></li></ul></div></div></div>
<div class="openblock column"><div class="content"><div class="imageblock"><img src="img/recursive-macro-derivation.png" alt="Recursive Macro Derivation"></div>
<div class="ulist small"><ul><li><p>use implicit search only for overrides</p></li><li><p>types supported OOTB are handled by macro, implicit scope is empty by default</p></li></ul></div></div></div>
<aside class="notes"><div class="paragraph"><p>…​we might suspect why people prefer to develop things in the Circe style - it’s much easier for developer to now thing about these things!</p></div>
<div class="paragraph"><p>You write some implicits and it works, while with macros you have to deal manually write conditional code and create trees. <em>(next slide)</em></p></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>OK, but what does this gibberish mean for users?</p></div>
<aside class="notes"><div class="paragraph"><p>Probably you are asking yourself this question, so let’s get to the numbers.</p></div></aside></div></section><section><div class="slide-content"><div class="imageblock"><img src="img/json-compilation-times-3.png" alt="Json Compilation Times" width="80%" height="80%"></div>
<div class="paragraph small"><small>(less is better)</small></div>
<aside class="notes"><div class="paragraph"><p>Jsonier Scala beaten all of the other approaches: Shapeless, Mirrors, Magnolia,
whether automatic or semiautomatic. 10 seconds on cold JVM going down to 4 seconds on Scala 2.13.
8 seconds down to 1 on Scala 3. And we are only taking about the compilation time, not the actual performance!</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true"> Scala 2 Scala 3 Units
compilation of cold hot cold hot
circeGenericAuto 14 4 46 16 s
circeGenericSemi 12 3 10 1 s
circeMagnoliaAuto 13 2 65 32 s
circeMagnoliaSemi 12 7 12 2 s
jsoniterScalaSanely - - 9 1 s
jsoniterScalaSemi 10 4 8 1 s</code></pre></div></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Scala 2.13.14</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] JsonRoundTrips.circeGenericAuto thrpt 10 7.319 ± 0.011 ops/ms
[info] JsonRoundTrips.circeGenericSemi thrpt 10 6.775 ± 0.013 ops/ms
[info] JsonRoundTrips.circeMagnoliaAuto thrpt 10 7.689 ± 0.013 ops/ms
[info] JsonRoundTrips.circeMagnoliaSemi thrpt 10 7.838 ± 0.013 ops/ms
[info] JsonRoundTrips.jsoniterScalaSemi thrpt 10 20.081 ± 0.151 ops/ms</code></pre></div></div>
<div class="paragraph"><p>Scala 3.3.3</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] JsonRoundTrips.circeGenericAuto thrpt 10 0.490 ± 0.432 ops/ms
[info] JsonRoundTrips.circeGenericSemi thrpt 10 4.607 ± 0.014 ops/ms
[info] JsonRoundTrips.circeMagnoliaAuto thrpt 10 0.077 ± 0.039 ops/ms
[info] JsonRoundTrips.circeMagnoliaSemi thrpt 10 5.590 ± 0.013 ops/ms
[info] JsonRoundTrips.jsoniterScalaSemi thrpt 10 21.480 ± 0.070 ops/ms</code></pre></div></div>
<div class="paragraph small"><small>(more is better)</small></div>
<aside class="notes"><div class="paragraph"><p>In benchmarks, it was 3 times faster than the fastest Circe result.</p></div>
<div class="paragraph"><p>And have to admit: I am cheating, Jsoniter parses and writes to String while, Circe parses and writes to Json AST.
If Circe was first: parsing from String to Json and then Json to case class…​ I suspect it would be even worse.</p></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>But can it be automatic?</p></div>
<aside class="notes"><div class="paragraph"><p>Jsoniter’s approach, while promising, still is not as easy for newcomers as automatic derivation, it requires some ceremony after all.</p></div>
<div class="paragraph"><p>Can we get rid of it?</p></div></aside></div></section></section>
<section><section id="_automatic_derivation_ala_chimney" class="small"><h2>Automatic derivation a’la Chimney</h2><div class="slide-content"><div class="paragraph fragment"><p>Similar problem:</p></div><div class="ulist"><ul><li class="fragment"><p>derivation should be recursive</p></li><li class="fragment"><p>macro should only use implicits for overrides</p></li></ul></div><div class="paragraph fragment"><p>But:</p></div><div class="ulist"><ul><li class="fragment"><p>automatic derivation should be available without breaking the 2 above</p></li></ul></div><aside class="notes"><div class="paragraph"><p>This is exactly the question I had when I was developing newer version of Chimney. We had a similar problem:</p></div>
<div class="paragraph"><p>(read points)</p></div>
<div class="paragraph"><p>Of course, we found a solution.</p></div></aside></div></section><section id="_solution" class="small-h2"><h2>Solution</h2><div class="slide-content"><div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">trait TypeClass[A] extends TypeClass.AutoDerived[A] { ... }
object TypeClass {
// semi-automatic derivation of TypeClass[A]
inline def derived[A]: TypeClass[A] = ${ derivedImpl[A] }
trait AutoDerived[A] { ... }
object AutoDerived extends AutoDerivedLowPriorityImplicits
trait AutoDerivedLowPriorityImplicits {
// automatic derivation of TypeClass.AutoDerived[A]
inline given derived[A]: AutoDerived[A] = ${ derivedImpl[A] }
}
}</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">extension [A](value: A)
// uses TypeClass[A] defined by user manually or with TypeClass.derived,
// falling back on automatic derivation
def method(using TypeClass.AutoDerived[A]) = ...</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">// allowed to try summoning TypeClass[Sth].
// NOT allowed to try summoning TypeClass.AutoDerived[Sth]!
def derivedImpl[A: Type]: Expr[TypeClass[A]] = ...</code></pre></div></div>
<div class="paragraph small fragment"><small>(Disclaimer: understanding this code is <strong>not</strong> necessary to understand its implications on the next slides)</small></div>
<div class="paragraph small fragment"><small>(Solutions for <a href="https://www.scala-lang.org/2024/08/19/given-priority-change-3.7.html"><em>New Prioritization of Givens in Scala 3.7</em></a> available at the checkout)</small></div>
<aside class="notes"><div class="paragraph"><p>We have 2 separate types: one is intended to be used by the /Users/dev, and one used only for automatic derivation.</p></div>
<div class="paragraph"><p>Extension methods and other summoning should try to use the one we exposed to user, and then fallback on automatic derivation.</p></div>
<div class="paragraph"><p>Both automatic and semiautomatic derivation can only use the type intended for users, so a macro never calls itself.</p></div>
<div class="paragraph"><p>If you don’t get it, don’t worry, it’s enough if you just understand the implications.</p></div>
<div class="paragraph"><p>If you have questions about givens and 3.7 we can talk about it later.</p></div>
<div class="paragraph"><p>(In case I forgot: <code>summonFrom</code> for ordering the summons the old way + <code>opaque type</code> for the result of such ordered summoning.)</p></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Can we test it outside Chimney?</p></div>
<div class="paragraph fragment"><p>Yes.</p></div>
<aside class="notes"><div class="paragraph"><p>I know that it works in Chimney, but we are using JSON examples for now.</p></div>
<div class="paragraph"><p>The answer is "yes".</p></div></aside></div></section><section id="_sanely_automatic_derivation" class="small-h2"><h2>Sanely-automatic derivation</h2><div class="slide-content"><div class="paragraph"><p>I implemented wrapper around Jsoniter (on Scala 3-only) which works like this:</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">import jsonitersanely.* // <-- 1 import, like with std automatic derivation
def roundTrip(out: Out): (String, Either[Throwable, Out]) = {
val str = write(out)
val parsed = scala.util.Try(read[Out](str)).toEither
str -> parsed
}</code></pre></div></div>
<aside class="notes"><div class="paragraph"><p>The approach, which I named sanely-automatic as opposed to semi-automatic, is something I implemented for Jsoniter.</p></div>
<div class="paragraph"><p>Since I couldn’t just edit the Jsoniter code, I made a wrapper, and only for Scala 3 because it was easier for me.</p></div>
<div class="paragraph"><p>As you can see, it’s used just like automatic derivation on Circe.</p></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>How does it compare to Circe or normal Jsoniter Scala?</p></div>
<aside class="notes"><div class="paragraph"><p>Did we managed to avoid all of the issues of automatic derivation without the ceremony of semi-automatic derivation?</p></div></aside></div></section><section><div class="slide-content"><div class="imageblock"><img src="img/json-compilation-times-4.png" alt="Json Compilation Times" width="80%" height="80%"></div>
<div class="paragraph small"><small>(less is better)</small></div>
<aside class="notes"><div class="paragraph"><p>I would say "yes". Sanely-automatic derivation has amost the same compilation times as Jsoniter,
much, much faster than Circe, no matter which apporach.</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true"> Scala 2 Scala 3 Units
compilation of cold hot cold hot
circeGenericAuto 14 4 46 16 s
circeGenericSemi 12 3 10 1 s
circeMagnoliaAuto 13 2 65 32 s
circeMagnoliaSemi 12 7 12 2 s
jsoniterScalaSanely - - 9 1 s
jsoniterScalaSemi 10 4 8 1 s</code></pre></div></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Scala 2.13.14</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] JsonRoundTrips.circeGenericAuto thrpt 10 7.319 ± 0.011 ops/ms
[info] JsonRoundTrips.circeGenericSemi thrpt 10 6.775 ± 0.013 ops/ms
[info] JsonRoundTrips.circeMagnoliaAuto thrpt 10 7.689 ± 0.013 ops/ms
[info] JsonRoundTrips.circeMagnoliaSemi thrpt 10 7.838 ± 0.013 ops/ms
[info] JsonRoundTrips.jsoniterScalaSemi thrpt 10 20.081 ± 0.151 ops/ms</code></pre></div></div>
<div class="paragraph"><p>Scala 3.3.3</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] JsonRoundTrips.circeGenericAuto thrpt 10 0.490 ± 0.432 ops/ms
[info] JsonRoundTrips.circeGenericSemi thrpt 10 4.607 ± 0.014 ops/ms
[info] JsonRoundTrips.circeMagnoliaAuto thrpt 10 0.077 ± 0.039 ops/ms
[info] JsonRoundTrips.circeMagnoliaSemi thrpt 10 5.590 ± 0.013 ops/ms
[info] JsonRoundTrips.jsoniterScalaSemi thrpt 10 21.480 ± 0.070 ops/ms
[info] JsonRoundTrips.jsoniterScalaSanely thrpt 10 21.408 ± 0.070 ops/ms</code></pre></div></div>
<div class="paragraph small"><small>(more is better)</small></div>
<aside class="notes"><div class="paragraph"><p>Benchmarks are virtually the same. We the fastest compilation, with the fastest bytecode, and no manually written implicits!</p></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>But <strong>Jsoniter parsing <code>String</code> s</strong> vs <strong>Circe parsing <code>Json</code></strong> might be apples vs oranges.</p></div>
<div class="paragraph"><p>Can we have some more <strong>fair</strong> comparison?</p></div>
<aside class="notes"><div class="paragraph"><p>However, you can remind me: these libraries have different philosophies, designs, etc.</p></div>
<div class="paragraph"><p>The results might be the artifact of something else than just the way they implemented the derivation.</p></div>
<div class="paragraph"><p>And you would be right which is why I also implemented something else.</p></div></aside></div></section></section>
<section><section id="_more_fair_comparison"><h2>More fair comparison</h2></section><section><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">trait FastShowPretty[A] {
def showPretty(
value: A,
sb: StringBuilder,
indent: String = " ",
nesting: Int = 0
): StringBuilder
}
implicit class FastShowPrettyOps[A](private val value: A) {
def showPretty(indent: String = " ", nesting: Int = 0)(
implicit fsp: FastShowPretty[A]
): String =
fsp.showPretty(value, new StringBuilder, indent, nesting).toString()
}</code></pre></div></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">case class Street(name: String)
case class Address(street: Street)
case class User(name: String, address: Address)
println(User("John", Address(Street("Paper St"))).showPretty())</code></pre></div></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true">User(
name = "John",
address = Address(
street = Street(
name = "Paper St"
)
)
)</code></pre></div></div>
<aside class="notes"><div class="paragraph"><p>Some of you might be familiar with <code>Show</code> type class - it’s basically toString but "better".</p></div>
<div class="paragraph"><p>It also has a <code>ShowPretty</code> variant, which adds some nice indents.</p></div>
<div class="paragraph"><p>I decided to use that pretty variant, but instead of concatenating Strings, like in the original, I decided I would be appending them to StringBuilder.</p></div>
<div class="paragraph"><p>This is how I’d like to use that type class, and what kind of output I’d like to see.</p></div></aside></div></section><section><div class="slide-content"><div class="ulist"><ul><li class="fragment"><p>automatic and semi-automatic derivation using <strong>Shapeless</strong> (Scala 2)</p></li><li class="fragment"><p>automatic and semi-automatic derivation using <strong>Mirror</strong> s (Scala 3)</p></li><li class="fragment"><p>automatic and semi-automatic derivation using <strong>Magnolia</strong> (Scala 2 & 3)</p></li><li class="fragment"><p>sanely-automatic derivation with macros and <strong>Chimney macro commons</strong> (Scala 2 & 3)</p></li></ul></div>
<aside class="notes"><div class="paragraph"><p>Then I implemented it for</p></div>
<div class="paragraph"><p>Shapeless on Scala 2</p></div>
<div class="paragraph"><p>Mirrors on Scala 3</p></div>
<div class="paragraph"><p>Magnolia on both 2 and 3</p></div>
<div class="paragraph"><p>Sanely-automatic derivation with macros on both 2 and 3</p></div>
<div class="paragraph"><p>For startes I implemented sanely-automatic derivation in naive way - inlining everything.</p></div>
<div class="paragraph"><p>Then I run numbers for my evil, nested case class.</p></div></aside></div></section><section><div class="slide-content"><div class="imageblock"><img src="img/show-compilation-times-1.png" alt="Show Compilation Times" width="80%" height="80%"></div>
<div class="paragraph small"><small>(less is better)</small></div>
<aside class="notes"><div class="paragraph"><p>It seems that some results are the same like with JSONs experiments.</p></div>
<div class="paragraph"><p>Scala 2.13 approaches are close.</p></div>
<div class="paragraph"><p>Semi-automatic results on Scala 3 are slightly better.</p></div>
<div class="paragraph"><p>Automatic results on Scala 3 are much worse.</p></div>
<div class="paragraph"><p>Naive macro implementation, isn’t very bad, especially considering how convenient it is, but it seems that it’s slower to compile than semi-automatic.</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true"> Scala 2 Scala 3 Units
compilation of cold hot cold hot
showGenericProgrammingAuto 15 5 53 29 s
showGenericProgrammingSemi 10 2 10 2 s
showMagnoliaAuto 10 1 43 15 s
showMagnoliaSemi 10 2 9 1 s
showSanely 14 4 16 5 s</code></pre></div></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Scala 2.13.14</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] ShowOutputs.showGenericProgrammingAuto thrpt 10 2.651 ± 0.012 ops/ms
[info] ShowOutputs.showGenericProgrammingSemi thrpt 10 2.829 ± 0.033 ops/ms
[info] ShowOutputs.showMagnoliaAuto thrpt 10 3.621 ± 0.017 ops/ms
[info] ShowOutputs.showMagnoliaSemi thrpt 10 3.745 ± 0.028 ops/ms
[info] ShowOutputs.showSanely thrpt 10 2.202 ± 0.359 ops/ms</code></pre></div></div>
<div class="paragraph"><p>Scala 3.3.3</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] ShowOutputs.showGenericProgrammingAuto thrpt 10 0.156 ± 0.013 ops/ms
[info] ShowOutputs.showGenericProgrammingSemi thrpt 10 3.492 ± 0.013 ops/ms
[info] ShowOutputs.showMagnoliaAuto thrpt 10 0.090 ± 0.023 ops/ms
[info] ShowOutputs.showMagnoliaSemi thrpt 10 3.918 ± 0.012 ops/ms
[info] ShowOutputs.showSanely thrpt 10 2.204 ± 0.396 ops/ms</code></pre></div></div>
<div class="paragraph small"><small>(more is better)</small></div>
<aside class="notes"><div class="paragraph"><p>Similarly benchmarks, our naive sanely-automatic derivation isn’t terrible, but probably you would prefer anything else (other than automatic derivation on Scala 3).</p></div>
<div class="paragraph"><p>So was it a failed experiment?</p></div></aside></div></section><section><div class="slide-content"><div class="paragraph fragment"><p>But wait.</p></div>
<div class="paragraph fragment"><p>Jsoniter had one more trick. It "caches" subroutines as <code>def</code> s.</p></div>
<aside class="notes"><div class="paragraph"><p>If you need to handle the same type, you wouldn’t derive code for it again, but just call that def you defined when you handled it the first time.</p></div></aside>
<div class="paragraph fragment"><p>Would that make a difference?</p></div></div></section><section><div class="slide-content"><div class="imageblock"><img src="img/show-compilation-times-2.png" alt="Show Compilation Times" width="80%" height="80%"></div>
<div class="paragraph small"><small>(less is better)</small></div>
<aside class="notes"><div class="paragraph"><p>It seems that caching results of the derivation, inside the same macro, is not that difficult, and 1 non-invasive PR later, we run the numbers again.</p></div>
<div class="paragraph"><p>We beat all the other approaches. It’s the fasted thing to compile. How about benchmarks?</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true"> Scala 2 Scala 3 Units
compilation of cold hot cold hot
showGenericProgrammingAuto 15 5 53 29 s
showGenericProgrammingSemi 10 2 10 2 s
showMagnoliaAuto 10 1 43 15 s
showMagnoliaSemi 10 2 9 1 s
showSanely 6 1 7 1 s</code></pre></div></div></aside></div></section><section><div class="slide-content"><div class="paragraph"><p>Scala 2.13.14</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] ShowOutputs.showGenericProgrammingAuto thrpt 10 2.651 ± 0.012 ops/ms
[info] ShowOutputs.showGenericProgrammingSemi thrpt 10 2.829 ± 0.033 ops/ms
[info] ShowOutputs.showMagnoliaAuto thrpt 10 3.621 ± 0.017 ops/ms
[info] ShowOutputs.showMagnoliaSemi thrpt 10 3.745 ± 0.028 ops/ms
[info] ShowOutputs.showSanely thrpt 10 4.811 ± 0.026 ops/ms</code></pre></div></div>
<div class="paragraph"><p>Scala 3.3.3</p></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">[info] Benchmark Mode Cnt Score Error Units
[info] ShowOutputs.showGenericProgrammingAuto thrpt 10 0.156 ± 0.013 ops/ms
[info] ShowOutputs.showGenericProgrammingSemi thrpt 10 3.492 ± 0.013 ops/ms
[info] ShowOutputs.showMagnoliaAuto thrpt 10 0.090 ± 0.023 ops/ms
[info] ShowOutputs.showMagnoliaSemi thrpt 10 3.918 ± 0.012 ops/ms
[info] ShowOutputs.showSanely thrpt 10 4.800 ± 0.042 ops/ms</code></pre></div></div>
<div class="paragraph small"><small>(more is better)</small></div>
<aside class="notes"><div class="paragraph"><p>Again, the fastest! The code that required as little ceremony as a single import is both the fastest to compile and the fastest to run!</p></div>
<div class="paragraph"><p>But we haven’t talked about debugging these macros, did we?</p></div></aside></div></section><section id="_bonus_debugging" class="small"><h2>Bonus: debugging</h2><div class="slide-content"><div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-scala hljs" data-noescape="true" data-lang="scala">case class Street(name: Either[String, Nothing]) // <-- this should fail the derivation
case class Address(street: Street)
case class User(name: String, address: Address)
// scalacOptions += "-Xmacro-settings:fastshowpretty.logging=true"
def printObject(out: User): String = out.showPretty()</code></pre></div></div>
<div class="listingblock"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true">[error] .../ShowSanely.scala:12:54: Failed to derive showing for value : example.ShowSanely.User:
[error] No build-in support nor implicit for type scala.Nothing
[error] def printObject(out: User): String = out.showPretty()
[error] ^</code></pre></div></div>
<div class="listingblock fragment"><div class="content"><pre class="highlightjs highlight"><code class="language-none hljs" data-noescape="true">[info] .../ShowSanely.scala:12:54: Logs:
[info] - Started derivation for value : example.ShowSanely.User
[info] - Attempting rule ImplicitRule
[info] - Skipped summoning example.showmacros.FastShowPretty[example.ShowSanely.User]
[info] - Attempting rule CachedDefRule
[info] - Attempting rule BuildInRule
[info] - Attempting rule ProductRule
[info] - Checking if def for example.ShowSanely.User exists
[info] - Started deriving def for example.ShowSanely.User
[info] - Started derivation for string : java.lang.String
[info] - Attempting rule ImplicitRule
[info] - Attempting rule CachedDefRule
[info] - Attempting rule BuildInRule
[info] - Successfully shown java.lang.String: sb.append("\"").append(string).append("\"")
[info] - Started derivation for address : example.ShowSanely.Address
[info] - Attempting rule ImplicitRule
[info] - Attempting rule CachedDefRule
[info] - Attempting rule BuildInRule
[info] - Attempting rule ProductRule
[info] - Checking if def for example.ShowSanely.Address exists
[info] - Started deriving def for example.ShowSanely.Address
[info] - Started derivation for street : example.ShowSanely.Street
[info] - Attempting rule ImplicitRule
[info] - Attempting rule CachedDefRule
[info] - Attempting rule BuildInRule
[info] - Attempting rule ProductRule
[info] - Checking if def for example.ShowSanely.Street exists
[info] - Started deriving def for example.ShowSanely.Street
[info] - Started derivation for either : scala.util.Either[java.lang.String, scala.Nothing]
[info] - Attempting rule ImplicitRule
[info] - Attempting rule CachedDefRule
[info] - Attempting rule BuildInRule
[info] - Attempting rule ProductRule
[info] - Attempting rule SumTypeRule
[info] - Checking if def for scala.util.Either[java.lang.String, scala.Nothing] exists
[info] - Started deriving def for scala.util.Either[java.lang.String, scala.Nothing]
[info] - Started derivation for left : scala.util.Left[java.lang.String, scala.Nothing]
[info] - Attempting rule ImplicitRule
[info] - Attempting rule CachedDefRule
[info] - Attempting rule BuildInRule
[info] - Attempting rule ProductRule
[info] - Checking if def for scala.util.Left[java.lang.String, scala.Nothing] exists
[info] - Started deriving def for scala.util.Left[java.lang.String, scala.Nothing]
[info] - Started derivation for string : java.lang.String
[info] - Attempting rule ImplicitRule
[info] - Attempting rule CachedDefRule
[info] - Attempting rule BuildInRule
[info] - Successfully shown java.lang.String: sb.append("\"").append(string).append("\"")
[info] - Cached result of def for scala.util.Left[java.lang.String, scala.Nothing]
[info] - Successfully shown scala.util.Left[java.lang.String, scala.Nothing]: show_nothing$u005D(left, nesting)
[info] - Started derivation for right : scala.util.Right[java.lang.String, scala.Nothing]
[info] - Attempting rule ImplicitRule
[info] - Attempting rule CachedDefRule
[info] - Attempting rule BuildInRule
[info] - Attempting rule ProductRule
[info] - Checking if def for scala.util.Right[java.lang.String, scala.Nothing] exists
[info] - Started deriving def for scala.util.Right[java.lang.String, scala.Nothing]