4 ms·

Erlang's strings might be widely considered awful, but probably not by people who actually have a clue – the numbers thing is ugly, but overall it's a very nice

by patrec 9y ago

Erlang's strings might be widely considered awful, but probably not by people who actually have a clue – the numbers thing is ugly, but overall it's a very nice design and has very nice features that are pretty much unique to Erlang. Erlang has 3 types of strings: 1. the list of integers thing, which you should mostly avoid 2. binary strings (like python2 str or go) 3. iolists: a list or element of either of 1, 2 or 3. This is the nice part – it basically means erlang has ropes. And all the "egress" functions (sending udp or tcp packets or writing to stdout or files or sockets etc.) take iolists. So you can avoid a lot of pointless copying and write text or binary data very efficiently; I know of no other (non-BEAM) language that has similarly good support for this, do you? See http://www.evanmiller.org/elixir-ram-and-the-template-of-doom.html http://www.evanmiller.org/elixir-ram-and-the-template-of-doo... for more details.

masklinn 9y ago
> Erlang's strings might be widely considered awful, but probably not by people who actually have a clue – the numbers thing is ugly, but overall it's a very nice design It is nice in a theoretical sense, in the same way Haskell's [Char] is nice, in a practical sense it's awful. > 2. binary strings (like python2 str or go) AKA not actually strings, I don't remember Erlang having much if any string-manipulation API for working on bytes. > 3. iolists: a list or element of either of 1, 2 or 3. This is the nice part – it basically means erlang has ropes. And all the "egress" functions (sending udp or tcp packets or writing to stdout or files or sockets etc.) take iolists. This is only for output, so they're not actually ropes. > So you can avoid a lot of pointless copying and write text or binary data very efficiently; I know of no other (non-BEAM) language that has similarly good support for this, do you? Most mutable languages will use buffered output streams and possibly some sort of string sequence (even C has iovecs), so while iolists are a good fit for Erlang they make sense in few other languages.
- patrec 9y ago
  > It is nice in a theoretical sense, in the same way Haskell's [Char] is nice, in a practical sense it's awful. Haskell's list of Char is awful in both a theoretical and practical sense whereas in erlang's case you can think of it as just a degenerate iolist. > I don't remember Erlang having much if any string-manipulation API for working on bytes Elixir is better but erlang certainly has string manipulation functionality for binaries: pattern matching, regular expressions, search, splitting and joining etc. > This is only for output, so they're not actually ropes. Not true, lots of non-output functions also accept iolists, e.g. the re module.

by patrec 9y ago

masklinn 9y ago

> Erlang's strings might be widely considered awful, but probably not by people who actually have a clue – the numbers thing is ugly, but overall it's a very nice design It is nice in a theoretical sense, in the same way Haskell's [Char] is nice, in a practical sense it's awful. > 2. binary strings (like python2 str or go) AKA not actually strings, I don't remember Erlang having much if any string-manipulation API for working on bytes. > 3. iolists: a list or element of either of 1, 2 or 3. This is the nice part – it basically means erlang has ropes. And all the "egress" functions (sending udp or tcp packets or writing to stdout or files or sockets etc.) take iolists. This is only for output, so they're not actually ropes. > So you can avoid a lot of pointless copying and write text or binary data very efficiently; I know of no other (non-BEAM) language that has similarly good support for this, do you? Most mutable languages will use buffered output streams and possibly some sort of string sequence (even C has iovecs), so while iolists are a good fit for Erlang they make sense in few other languages.

patrec 9y ago
> It is nice in a theoretical sense, in the same way Haskell's [Char] is nice, in a practical sense it's awful. Haskell's list of Char is awful in both a theoretical and practical sense whereas in erlang's case you can think of it as just a degenerate iolist. > I don't remember Erlang having much if any string-manipulation API for working on bytes Elixir is better but erlang certainly has string manipulation functionality for binaries: pattern matching, regular expressions, search, splitting and joining etc. > This is only for output, so they're not actually ropes. Not true, lots of non-output functions also accept iolists, e.g. the re module.