My understanding is most string functions (e.g. .charAt()) need by done "by-hand" by converting to bytes and then doing operations on those bytes, or, of course, using some sort of utility library.
I understand some choices in Solidity are for safety -- for example not supporting float for now.
Is the choice for poor string support a conscious choice for some sort of safety reason? Or is this just an evolution of the language not yet complete?
String functions are inherently computationally expensive, because strings are naturally immutable.
Solidity, recognizing this, is likely discouraging programmers and contract writers from including their string manipulation in solidity and instead providing a forcing-function for programmers to write their complex string functions in DAPP's or other solidity consumer applications.
As mentioned by others, string operations are very costly. The root of this is the fact that UFT-8 codepoints (the building blocks of a UTF-8 string) can be between 1 and 4 bytes in size. This means that you cannot simply index a string, or naively iterate over its elements. This adds a non-trivial computational overhead when you pay for computation on a per-opcode basis. For this reason, complex string operations are not very desirable for smart contracts.
In some situations, the choice is made to expand all UTF-8 codepoints to 4 bytes. This can increase the memory footprint of a string up to 4x, but it does simplify indexing and iteration. Given that memory reads/writes are the most expensive part of EVM computation, this isn't particularly ideal either.
