3 ms·
No support for multi-core parallelism. Strings are sequences of 8-bit characters, so crappy Unicode support. Weak support for non-Unix OSes.
by bunderbunder 8y ago
No support for multi-core parallelism. Strings are sequences of 8-bit characters, so crappy Unicode support. Weak support for non-Unix OSes.
- int_19h 8y agoI'm curious as to why you'd consider them advantages in that specific line of work. I can see lack of threads as an advantage in that it doesn't let you write multithreaded code with shared state, and forces into some kind of multiprocessing with message passing. But why would you prefer strings as 8-bit-clean, or weak support for non-Unix?
- bunderbunder 8y agoMultithreading is the stronger positive. I'm guessing 8-bit strings is a minor positive, on the basis that you really don't need to deal with non-ASCII text in that kind of setting, and there's probably some performance benefit to not supporting it. Even if you stick to characters from 7-bit ASCII in your own data, if the strings are technically UTF-8 or UTF-16, then the fact that it's a variable-length encoding means that more string operations will involve costly branch instructions. And if UTF-32, your strings will be 4x as big as they need to be. Not working on non-Unix is neutral. There's no benefit to it, but nothing was going to be running on Windows, anyway, so there'd have been no harm in it, either.