Stream: ideas

Topic: Rename *.len to *.size

Isaac Van Doren (Feb 01 2025 at 17:28):

Right now we have List.len, Set.len, and Dict.len. I propose we rename these functions to List.size, Set.size, and Dict.size.

For me, outside of the context of programming and a particular implementation, sets do not intuitively have a length. They are often represented as amorphous blobs that are very much unordered. Dictionaries having length also feels somewhat strange because I often think of them as a set of key value pairs. len is arguably slightly less discoverable because of this, and because of it being an abbreviation.

All three collections do however have a size. Size is not a property that depends on the collection being ordered in any way. Finally, size is not an abbreviation and yet it is still very short, which is nice.

Some languages use count instead of length or size. While it is nice that count identifies the element-wise aspect, it sounds to me like the function is literally iterating over the collection and counting the elements which is not the case and something I do not want to communicate.

jan kili (Feb 01 2025 at 17:30):

I have no strong opinion, just a note - I wonder if size connotes capacity / memory footprint to some people.

Richard Feldman (Feb 01 2025 at 17:30):

can we do a breakdown of which mainstream languages use which terms? that would give us a sense of what different people coming from different backgrounds would be used to.

Isaac Van Doren (Feb 01 2025 at 17:40):

Here's a list generated by Claude (could be some errors, but it seems correct)

Java:
List: size()
Set: size()
Dict: size()

Go:
List: len()
Set: len()
Dict: len()

C#:
List: Count
Set: Count
Dict: Count

Rust:
List: len()
Set: len()
Dict: len()

Python:
List: len()
Set: len()
Dict: len()

Zig:
List: len()
Set: count()
Dict: count()

Ruby:
List: length or size
Set: length or size
Dict: length or size

JavaScript:
List: length
Set: size
Dict: size

Elm:
List: length
Set: size
Dict: size

C++:
List: size()
Set: size()
Dict: size()

Haskell:
List: length
Set: size
Dict: size

OCaml:
List: length
Set: cardinal
Dict: cardinal

Isaac Van Doren (Feb 01 2025 at 17:41):

(FYI @JanCVanB in case your :hourglass: reaction meant you were also compiling a list)

Richard Feldman (Feb 01 2025 at 17:45):

len still seems like the way to go based on this list :big_smile:

Isaac Van Doren (Feb 01 2025 at 17:47):

Length definitely is the favorite for lists, but there are several instances of set and dict having different names than list which I think is telling

Isaac Van Doren (Feb 01 2025 at 17:48):

len still seems like the way to go based on this list :big_smile:

What makes you say that? The list seems mixed enough to me that it could go either way

jan kili (Feb 01 2025 at 17:50):

Actually, that list seems fair. Minor amendments:

• C (not above) seems to use sizeof for arrays and strlen for strings
• Java does use size for lists, but it uses length for arrays and strings
• Julia (not above) seems to use length for single-dimensional and size for N-dimensional
• Lua (not above) seems to use # for any and also len for strings
• Ruby's size is apparently an alias for length, but idk which people use more
• Rust has size_of too, but it's "the offset in bytes between successive elements in an array with that item type including alignment padding"

I didn't check all languages for the string function's name.

jan kili (Feb 01 2025 at 17:51):

We should consider strings in this discussion.

Isaac Van Doren (Feb 01 2025 at 17:52):

There's enough use of size that I think we are free to make the decision based on what seems best independent of what would be maximally familiar to the most people

Isaac Van Doren (Feb 01 2025 at 17:52):

We should consider strings in this discussion.

Is this still important with Roc not having a function for string length?

jan kili (Feb 01 2025 at 17:55):

Just good to note that we currently call it have count_utf8_bytes- the thing other languages call len(gth)/size, and what most people look for

Brendan Hansknecht (Feb 01 2025 at 18:13):

As an extra note, our dicts and sets both are ordered. Which may make length a more natural property.

I dont think many people mix up size and capacity, but I totally see the argument that size should be about the amount of actual memory used.

I do like that size is a full word unlike len.

Overall, I think either is fine as long as it is consistent so you don't have to think of a name per container type.

Brendan Hansknecht (Feb 01 2025 at 18:14):

I do think from a maths perspective size is almost certainly the right choice

Richard Feldman (Feb 01 2025 at 18:49):

some thoughts:

• Among these languages, only Java and C++ use "size" for lists/arrays, whereas Go, Rust, Python, Zig,, JS, Elm, Haskell, and OCaml all use "length" - that's why it seems clear to me that we should use "length" for list
• In general, "you have to remember which one to use in which circumstance, but there's no programming benefit to the names being different" is a red flag to me. It's better to not make people remember something that doesn't matter. (To be direct about it: I think the languages that chose different names for these made a mistake.) So even if it's more familiar to people to have different names, I think we're fixing a mistake by using the same name across the board.
• Since we should pick one name for all of these, I think we should conform to the name for list (so, "length") because lists come up way more often. If we choose "size" then it's going to come up way more often that you're tripping over the name you didn't expect.

Richard Feldman (Feb 01 2025 at 18:50):

that's why my conclusion is that we should stick with "length," and len makes more sense to me than length because we've had a lot of success with abbreviating names that you write a lot (e.g. Str, Num, etc.)

Richard Feldman (Feb 01 2025 at 18:51):

there's similar reasoning behind it being Set.insert instead of Set.add

Richard Feldman (Feb 01 2025 at 18:51):

(even though a lot of languages use add)

Richard Feldman (Feb 01 2025 at 18:52):

namely that it obviously should be Dict.insert (I don't think any mainstream languages use Dict.add; that would be a strange naming choice) and it seems like a needless hassle to have people need to remember that it's insert when it's a Dict but it's a different name when it's a Set instead

Richard Feldman (Feb 01 2025 at 18:53):

in contrast, I do think there's value in having Result use map_ok instead of map, namely that it's really common for a Result to be in a pipeline of calls that also involves collections (which have map), and in the static dispatch world, having .map_ok and .map have different names gives you a clue as to when an operation has returned a Result (which isn't always obvious from the function's name)

Richard Feldman (Feb 01 2025 at 18:53):

if it were common to have pipelines involving sets/dicts/lists where it was important to know which was which, I could see an argument for different names for some of these operations

Richard Feldman (Feb 01 2025 at 18:54):

but that doesn't really come up in the way that Result intermingling with collections does

Richard Feldman (Feb 01 2025 at 18:55):

(also .insert() with 1 argument tells you it's a Set as opposed to a Dict, and if you're calling .len() in a pipeline, it's almost certainly at the very end, and you probably don't care what the collection type was at that point, since all you're doing is getting its length anyway!)

Isaac Van Doren (Feb 01 2025 at 19:29):

Good points! It does seem right to prioritize list as it is so common

Ben (Feb 03 2025 at 05:00):

len is probably the right choice, however I'd be curious to hear thoughts on one other option that is rarely used: count. I believe it's used by Kotlin, C#, Objective-C

pros:

• clearer to beginners compared to len/size
• generalizes well to non-contiguous collections (trees, graphs, sets, dicts)
• not an abbreviation
• makes sense for iterators / lazy collections

• least ambiguous
  cons:

• unlike most other languages people are familiar with

• Can be interpreted as a verb, making it sound like it will perform an operation, vs len/size being clear nouns
• more characters to type vs len or size

I dislike size, I often have to ask if that is size in bytes / some other unit. In general I dislike abbreviations but I think it's okay for very common things: Str, Num, len

jan kili (Feb 03 2025 at 07:05):

:plus:1 to count generalizing best to collections for which len(gth) makes little/no sense. By choosing len, we might be setting ourselves up for something like graph+tree+list pipelines that mix 3rd-party HisGraph.node_count + 3rd party HerTree.total_count + 1st-party List.len.

jan kili (Feb 03 2025 at 07:06):

Here's something cute: What's List.count_if without an if condition? List.count

Eli Dowling (Feb 03 2025 at 14:49):

I object strongly to count, because it's a verb.

Through my whole time programming, I've always found the idea of invoking a "count" function suggests I'm somehow iterating the contents of the collection to count it up.

Particularly as a beginner, I found this confusing. C# uses count for lists and length for arrays, i always found the distinction made me think count must be doing "work".

Ben (Feb 03 2025 at 14:56):

Count can also be interpreted as a noun. "What's the count?"

Ben (Feb 03 2025 at 14:57):

if you asked the general public for a single word noun for the number of items in a bag, I wonder what the top answer would be

Ben (Feb 03 2025 at 15:01):

I'm pretty sure size and length wouldn't be in the top 5 :sweat_smile:

Hannes (Feb 04 2025 at 09:16):

I've always interpreted count as a noun, and read count(apples) as "Get the count of apples", although it's pretty rare to hear count as a noun in daily conversation :shrug:

Eli Dowling (Feb 04 2025 at 11:19):

Sure, but I'd say most functions are more verby than nouny.
Console.log() doesn't get you the log, it does the logging.
Properties are nouns.
It immediately raises the question "if this isn't doing work, why isn't it a property?"

The word would be "items" I think @Ben I asked my GF next to me (who is a non programmer) and she also said items

Hannes (Feb 04 2025 at 11:41):

Length is a pretty noun-y noun :thinking: Count is the only verb-y option, unless you pick something wacky like "measure" or "tally"

Isaac Van Doren (Feb 04 2025 at 13:22):

+100 for tally :laughing:

Jonathan (Feb 04 2025 at 14:02):

Eli Dowling said:

Particularly as a beginner, I found this confusing. C# uses count for lists and length for arrays, i always found the distinction made me think count must be doing "work".

For some more precedent that I don’t think has been mentioned in this discussion, that is the reasoning behind Elixir’s use of length and size, though to me it’s still not (quite) intuitive which way round is which.

Ben (Feb 04 2025 at 14:48):

Another cursed suggestion: quantity or qty. never seen that one

Kasper Møller Andersen (Feb 04 2025 at 18:57):

I'm personally on board with len, but if we really want to get the bikeshedding going, why do lists even have a length as opposed to a height? That's probably left-to-right biased! And it's also weird to think of these as having a capacity and a length at the same time. If capacity is what's actually room for, then the amount of elements would be something like utilization :grinning_face_with_smiling_eyes:

jan kili (Feb 04 2025 at 18:58):

This tempts me to create a joke fork of Roc with only the most dubious built-in names.
It can have BDFL governance - Bad Democracy For Lols.

Kasper Møller Andersen (Feb 04 2025 at 19:06):

Worst option wins! :big_smile:

jan kili (Feb 04 2025 at 19:09):

WrockML - Wrong Roc Fork Mad Libs

jan kili (Feb 04 2025 at 19:11):

Tone check: I love bikeshedding, I like all of the discussion above, and I trust us to pick the best name (for this and most things).

shua (Feb 04 2025 at 20:05):

CS can never be a branch of mathematics until they accept List::cardinality as the correct name.

Last updated: Jun 16 2026 at 16:19 UTC