Go Docs are good, but not enough!

I believe programming language standard library documentation should mention the time and space complexity of every operation. Currently, Go docs only explain how to use data structures, but nothing more. This is unacceptable. I need to know how much time it takes to initialize an array of size n without reading the source code. One might argue that abstraction should be completely separate from the implementation, but since that almost never happens in the real world, I need to know what is done in the underlying layer. For example, in some languages, iterating over a row in a 2D array is faster than iterating over a column. You can’t hide the implementation from abstraction regardless of how much you try (read more about leaky abstractions12). When you initialize a map, you need to know exactly how memory is allocated. You need to know if the map is implemented using a hash table, what the hash function is, and what the properties of the hash function are. In cases where you know the upper bound of the number of elements in a hash map, you can create a more optimal hash map (it really matters to know the capacity for a map3). I can go on and on, like needing to know the time complexity of appending two strings without digging into the source code of strings library.

Don’t get me wrong, Go docs are concise, to the point, and helpful, but in my humble opinion, there should be at least two versions of the docs: one about how to use the library and the other about assumptions and specifications.

It’s not required to show the importance of knowing the time complexity of data structure operations, but anyway, I want to show you an example. Look at this problem4: It gives you a list of numbers and wants you to write code to tell if the numbers can be partitioned into two subsets where the sums of the partitions are equal or not. I solved it in one way using three different data structures to compare time and memory usage. The solution is to compute the possible absolute sum differences of the numbers and see if 0 is possible or not. Here you can compare how different data structures perform in practice:

Using a map to store the possible difference values
Using a slice to store the possible difference values
Using a fixed-size array to store the possible difference values
  1. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ ↩︎
  2. https://en.wikipedia.org/wiki/Leaky_abstraction ↩︎
  3. https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html ↩︎
  4. https://leetcode.com/problems/partition-equal-subset-sum/description/ ↩︎