[elangoc]

What you're not realizing, though, is that each time you use the string "like" as a key for a map/dictionary, you're allocating a new object on the heap. So what if you have many keys, and they're all strings? What if you have many maps that share the same keys? That's a lot of memory to allocate, and strings are an extremely inefficient way to implement what is essentially a unique identifier to address map values. Instead, use an integer as a unique identifier.

That's basically what keywords do -- they are human-readable and compile down (prob. using some hash) into some integer, and the integer is stored globally only once. The biggest savings in memory comes when using maps, and that's how & why keywords get their name.

[asynchrony]

Javascript strings are immutable and literals are almost certainly preallocated and stored in a table of constants. Why should using a string keys cause heap allocations?

[arohner]

If you have a VM where strings are immutable and interned, you're right. Java doesn't guarantee that strings are interned (though you can ask the VM to intern it), so Clojure treats them differently.

Also, Java declared java.lang.String as final, so Strings can't be extended to implement clojure interfaces to get nice behavior, like IFn and IKeywordLookup.