The Next Step for Generics
I&#x27;ve been writing a lot of Rust lately after writing Go for 7 years now (unrelated, but that is incredibly odd for me to write out. It still feels like that funny new language that came out of Google). I&#x27;ve always said that generics is overhyped (in Go), but I find that I write a lot of generic stuff in Rust that is somewhat surprising. For example we have a JSON API that returns data in the format &#x27;{&quot;ok&quot;: bool, &quot;data&quot;:...}&#x27;. In Go I might do something with json.RawMessage and pay for decoding twice, or annotate every struct with Ok&#x2F;Data. But in Rust I can just have a type ApiResponse&lt;T&gt;. Then I can have functions that operate just on ApiResponse, or ApiResponse&lt;T=Users&gt;. This problem is solvable in Go, but in a different way and with less guarantees. However that power comes at a mental cost, that creeps in C++ as well. I spent more time playing type system golf trying to come up with the optimal type for whatever usecase. In Go I might just &quot;do the work&quot;, but in Rust I&#x27;ve turned 5 minute functions into 30 minute api design thought exercises.  The jury is out if thats is a good thing or a bad thing.<p>That said, the only feature I&#x27;d steal from Rust is sum types and getting rid of null. `nil` interfaces are the only language feature to actually cost me money and Option&lt;T&gt; is just better in every aspect, and Result&lt;T&gt; is much better than err == nil. I&#x27;d be perfectly happy with compiler blessed Option and Result types even if the larger language didn&#x27;t support generics.