KotlinConf 2019: The Power of Types by Danny Preussler

[@kaustubhpatange]

The guy wants to drink water 26:20 26:50 27:20 30:14 32:18 but is so immersed in the talk just forgets about it! Edit: Finally drinks after the talk ended! This guy is a real showman.

[@PairingWithDuncan]

One of the best talks from the conference, and the type system is one of the best features of Kotlin.

[@zhou7yuan]

What is a Type? [2:15] A type is a concise, formal description of the behavior of a program fragment The History of Types [2:49] Kotlin and Types [11:18] Primitive Obsession [11:50] Don't put in name what can be in type [14:00] (example price) [17:07] (Soundcloud URN example) [18:16] Costs [25:01] Memory Costs [27:55] Garbage Costs [30:13] Sum Up [31:09]

[@dansadventures5514]

Great talk. 5 corrections/clarifications: 1. The object header is actually 16 bytes on 64bit JVMs. 2. Objects are padded to be a multiple of 8 bytes after adding the size of all the fields to the object header size. 3. Extra wrapper objects are cheap only if they are temporary such that at any given point in time you have a small number of live/reachable objects. Otherwise, they would be promoted into the survivor spaces potentially causing full garbage collections (instead of just quick incremental GCs). Also, although they can be cheap to allocate taking about 10 cycles, 10 cycles is never as fast as 0 cycles so they're not free by any means. 4. The memory overhead can quickly add up without noticing. For example, the proposed TimeDelta class uses 7 times more memory than the primitive version on a 64bit JVM (16 byte TimeDelta header + 8 bytes for the value reference + 16 bytes Time header + 8 bytes for the time duration + 8 bytes for the TimeUnit reference = 56 bytes vs. 8 for the primitive long. 5. There is an extra cost that wasn't mentioned which is the indirection caused by pointer chasing and the negative impacts arising from cache misses. The team that is working on adding value types to the JVM (project Valhalla) measured a 12X speedup by eliminating wrapper objects in certain benchmarks. The takeaway point is that defining stronger types is great and we should strive to use them more but we should be aware of the impacts. We definitely shouldn't make blanket statements about using them for absolutely everything as they can severely impact performance & scalability in certain scenarios such as in computation-heavy workloads.

[@dentjoener]

Small correction on number one, when using Compressed OOPS, they're actually 12, even on 64 bit. This is enabled by default for Xmx under about 30GiB, so the rest of your values might be off. Yes the pointer chasing is a cost, but I'd rather have the clarity first, and then if it becomes a problem (verified by benchmarking) I'll refactor it later. Code has three priorities: simplicity, correctness, speed, and yes in that order.

[@dansadventures5514]

​@@dentjoener, although I really like the direction that the presenter is suggesting with stronger types (as mentioned in my initial comment), the main criticism is that the presenter dismissed any performance considerations based on incorrect facts. The video claims that the object header is 8 bytes when that hasn't been true for a long time since everyone uses a 64-bit runtime these days (along with other incorrect statements about memory amounts such as for booleans etc.). The video doesn't consider the effects of cache misses due to increased indirection etc. etc. In fact, most of the section on performance has incorrect statements or suggestions hence the need for my comment. Note that I'm not saying that performance is the most important aspect. The important point is that when convincing another developer about the value of using stronger types, I also acknowledge the memory and performance implications. This advice should not be followed universally without being aware of these costs since there are some scenarios where this would actually be bad advice (for example for intensive data-science computations, constrained environments such as Arduino, high-frequency trading, etc.). You have the priority order not quite right since correctness is definitely more important than simplicity most of the time (imagine trying to explain that a feature doesn't work correctly because the code was a tiny bit simpler this way). The truth is that there is no simple answer that applies in all scenarios since correctness is sometimes sacrificed if a scenario is expected to be extremely rare and the cost of addressing that is too high. Sometimes performance is more important than simplicity when response times are important such as emergency avoidance systems etc. Sometimes performance is even more important than correctness when the cost of determining the correct answer exceeds the required response times so we end up with approximations. There are times when we do the most amount of work possible in a specified amount of time and then stop it short presenting our best solution so depending on the importance of these solutions (eg. perhaps airline travel optimizations etc.) then making the code more performant can have a meaningful impact on the business to get improved solutions and these optimizations or improved algorithms typically reduce simplicity. The other common pitfall that many developers fall into is to completely ignore any performance considerations until it becomes a problem and only after benchmarking. This is a flawed view based on a misinterpretation from a quote from Donald Knuth as he was referring to low-level optimizations that usually aren't available in today's high-level languages (eg. pointer manipulations). Donald Knuth was a strong proponent of efficient algorithms and properly engineered solutions. For example, it's an accepted industry standard that we should use a StringBuilder instead of concatenating strings in a loop and this is expected of a good engineer. We shouldn't wait for concatenating strings to become a problem when we start dealing with non-trivial data-sets as that would be a silly approach. If an engineer replaces code that concatenates strings in a loop with a StringBuilder, we shouldn't ask them to benchmark it first as that would also be silly since we can logically reason about it. So even though string builders are strictly there for performance reasons, they are expected to be used from the beginning when appending strings in a loop. The bottom line is that when making a statement that a certain approach should always be used, it should actually apply to all scenarios or caveats should be mentioned instead of dismissed based on incorrect facts. If the cost of objects was as meaningless as the presenter suggests then Oracle wouldn't be devoting hundreds of combined man-years into project Valhala to try to avoid these costs.

[@DomainObject]

Fantastic talk. Thank you. Spread the word!

[@jaya-surya-t]

This is awesome!, more on this topic please.

[@KirillKhalitov]

In 1998, Gilad Bracha (Smalltalk), Martin Odersky (Scala), David Stoutamire and Philip Wadler (Haskell) created Generic Java, an extension to the Java language to support generic types. homepages.inf.ed.ac.uk/wadler/gj/

[@alexwhb122]

Fantastic talk. I learned a lot! Thank you.

[@CharlenoPires]

This talk open my mind!

[@juanrada1040]

Great conference, I wondering why speaker did not emphasize in kotlin inline classes as the perfect trade off between strongly typed/safe apis and memory usage.

[@PairingWithDuncan]

I think that Inline classes were still experimental at the time

[@eliseumds]

Great practical examples of domain types. It should be a breeze to express that in Typescript when nominal types arrive (if they do).

[@nikitapustovoi8987]

Great talk!

[@KirillKhalitov]

Furthermore Didier Rémy is co-inventor of OCaml OOP features.

[@brianodisho2435]

Great talk, thank you!

[@alexneeky7920]

really like this talk

[@34adse3]

Scala went too far with types. I like Kotlin and its pragmatic type system.

[@JobvanderZwan]

In Scala's defense, it is also a research language so it was somewhat "supposed" to go a little too far in exploring its ideas ;)

[@protaties]

Haskell went way too far. Scala went back a little, and Kotlin went back to the most comfortable point.

[@abdullatifalshriaf130]

Hold my Haskell!

[@harry50650]

At 25:00, if you really want to be typesafe, just change its constructor to id: NonEmptyString and skip the function constructors, invoke() etc. all that. Would be better I think.

[@marko-lazic]

What about annoying casting?

[@seancpp]

[heavy breathing]

[@coderinthewoods]

What is he trying to say?

[@marzuraanmarzuraan1226]

23:02 Shouldn't it be?: class UserUrn private constructor(id: String): SoundCloudUrn(id) { }

[@feggak]

So this is what they do at SoundCloud all day instead of creating a working mobile page...

[@Krushard]

lmao, so true

[@hamzabenkhaldoun]

All of this talk about types, type inference and not a single mention of ML-family languages ?? come on

[@KirillKhalitov]

OCaml is the best! It has the most powerful type inference of all production ready languages.

[@dysdurtyobjkyivxcvud9871]

14:35 quoting linus in support of kotlin is cognitive dissonance, he has a lot of impatient opinions and expressions. condemning c++ when Bjarne stroustrup was roughly in the top 3 of c language's design, especially his favorite ENUM feature, is also cognitive dissonance