The folks calling Erlang functions that return “strings” that wouldn’t be readable.
I provide a detailed breakdown of the reasoning behind this feature and how to alter the behavior in Livebookisms. Here’s an exert:
JEG2
Author of Designing Elixir Systems with OTP
polovy
I think what is really confusing to a newbie is that the function will return either the listo OR charlist, depending on the values supplied. This has confused me more than the return of the charlist.
0
dimitarvp
sbuttgereit
To expand on what @dimitarvp said. A charlist is just a list:
iex(2)> [64,65,66] === ~c"@AB"
true
The only thing that differentiates any list from a charlist is this definition (Binaries, strings, and charlists — Elixir v1.20.2):
A charlist is a list of integers where all the integers are valid code points.
Once you have a defined list of integers which matches that definition you have both a list of integers and a valid charlist. At that point they’re indistinguishable… which is why they can be confusing and why any display in a REPL will catch someone up… the REPL can only (reasonably) display one representation. If chosen representation doesn’t match your intent/expectation you might very well think it’s returning the wrong thing when it’s just an unexpected representation: not a “different thing” at all.
1
LostKobrakai
It doesn’t even need to be an erlang function directly. E.g. Application.started_applications/0 or Application.loaded_applications/1 return [{atom, charlist, charlist}]. Also many error tuples include charlists, especially around e.g. gen_tcp/ssl.
1
dimitarvp
None of which is so important for actual production development – we’re talking inspecting stuff in iex. Whoever truly needs it should opting in for lists to be shown as charlists. IMO Elixir got the setting the wrong way around: lists should have been lists regardless if they are printable or not.
Some of us here, yourself included, are around for a long time and it’s been apparent that this is something newcomers regularly get confused of.
1
LostKobrakai
I’d not just iex. The inspect protocol is used in all manner ot places to turn arbitrary data into a string representation. That includes logs, tracing, error handling system and yes you iex shell. I would consider those very much important for production usage. And no I don’t want to need to transform a list of integersin my error tracking to a string to be able to figure out what the error is about.
I also don’t consider changing a subset of those places to different defaults. That would be even more confusing.
3
dimitarvp
I have solved this for myself with helpers that convert charlists to strings at the edges. 
From then on it’s business as usual. Charlists are an Erlang relic and the rest of the arguments in their favor I view as post-hoc rationalization.
Regardless of my opinion however, people like myself have made their own inspect wrappers and put them in the right places and we have no surprising visual outputs. I still wonder however: since it’s been obvious for a long time that this is tripping up newcomers, why was it not deemed important enough to reverse the default? Are people’s businesses going to crash and burn if 1% of their inspected values in logs suddenly don’t show strings but lists of integers?
1
LostKobrakai
In my experience lists with integers in valid ascii range are much rarer that seeing charlists around code interacting with erlang. Also I consider the information lost for a string not being represented as a string larger than the information lost for a very specific subsets of lists, which would be represented as a charlist.
In the end I also don’t think changing the default would mean new people are no longer tripped up by charlists. It’ll just happen in different circumstances.
1