3 ms·

do you need to do much "rich" string processing in erlang? it certainly is not designed for that usecase. you _can_ do quiet a bit of string processing in erla

by ibotty 13y ago

do you need to do much "rich" string processing in erlang? it certainly is not designed for that usecase. you _can_ do quiet a bit of string processing in erlang's bytestrings (note: not unicode-aware), see e.g. cowboy (which has nice to read sourcecode). as to why erlang does not have a haskell-like ByteString, i guess, it's because haskell has very fast (but potentially unsafe) c-bindings. erlang's ports are too slow to use them for something that small-grained. i'm not sure, why no BIFs were introduced to bring somthing similar, honestly.

lobster_johnson 13y ago
> it certainly is not designed for that usecase. That's a misleading statement, I think; it's like saying Python was not designed for web application development (which is true but also misleading). It's more correct to say that Erlang was designed without much thought given to string processing. Erlang was designed as a fairly general-purpose language, only one with non-encoding-aware strings; the real problem is that it hasn't caught up, even though Unicode has existed since 1991 and has long been incorporated into most languages and most software by now. Instead of adapting, Erlang seems to be stagnating in one area that users are frequently complaining about. In this day and age, I would argue that string processing is quite important for the things that Erlang can, or should, be used for. Anecdotally, when I first tried Erlang I tried to create a naive, parallel log processor which read lines and spawned off lines to a pool of workers. As a newbie I was quickly stumped because Erlang's file I/O is abysmally designed. I eventually gave up the project, and later I found that Tim Bray, also an Erlang noob, had struggled with the exact same issue [1][2]. You would think that this is something Erlang would excel at, but apparently it's not. I have been disappointed with Haskell's string support, too -- it's all over the place (String vs. Text types, the weird Data.Encoding module, horrible regexp library, etc.) -- but at least it's fully Unicode-aware and it has a fast ByteString type. [1] https://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang https://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang [2] https://www.tbray.org/ongoing/When/200x/2007/09/21/Erlang https://www.tbray.org/ongoing/When/200x/2007/09/21/Erlang
- davidw 13y ago
  I like Erlang a lot, and am currently working on a project that utilizes Chicago Boss, but there's a lot of truth in what you write. Erlang is somewhat strange for a language in that it got put to use in some very important critical systems before it got big. Things like Ruby, Tcl and Python slowly got popular and changed along the way. Doing an Erlang 2.0 that improves on some of the warts is probably not so easy...
  - lobster_johnson 13y ago
    That's a good observation. I don't know much about Erlang's history beyond what is on Wikipedia, but I suspect that the number of people that used Erlang before it was open source was relatively small and limited to the technical community within Ericsson. That small, focused user group explains the language's weird and weirdly antiquated style and feature set, but it doesn't quite explain why the language has not been evolved to become more modern. (Of course, the fact that something as ingenious could come out of such a small community is also very impressive and wonderful.)
  - lobster_johnson 13y ago
    If you are interested in the history of Erlang, this is fascinating: https://docs.google.com/viewer?url=http%3A%2F%2Fwebcem01.cem.itesm.mx%3A8005%2Ferlang%2Fcd%2Fdownloads%2Fhopl_erlang.pdf https://docs.google.com/viewer?url=http%3A%2F%2Fwebcem01.cem...
- jlouis 13y ago
  Unicode is a big thing in R16 and R17 where more of the system will use the unicode support we do have. Erlang modules will use utf-8 encoding and so on. As for a built-in bstring() type, it is being discussed, but there are other things more important to get into the language, maps for instance. Erlang is rather conservative in the speed with which we add stuff to the language. Erlang has some of the fastest I/O in a runtime. But it is not easy to use correctly. The same goes for string processing. Erlang can be blinding fast at that, but you must understand how to make it fast.

by ibotty 13y ago

lobster_johnson 13y ago

> it certainly is not designed for that usecase. That's a misleading statement, I think; it's like saying Python was not designed for web application development (which is true but also misleading). It's more correct to say that Erlang was designed without much thought given to string processing. Erlang was designed as a fairly general-purpose language, only one with non-encoding-aware strings; the real problem is that it hasn't caught up, even though Unicode has existed since 1991 and has long been incorporated into most languages and most software by now. Instead of adapting, Erlang seems to be stagnating in one area that users are frequently complaining about. In this day and age, I would argue that string processing is quite important for the things that Erlang can, or should, be used for. Anecdotally, when I first tried Erlang I tried to create a naive, parallel log processor which read lines and spawned off lines to a pool of workers. As a newbie I was quickly stumped because Erlang's file I/O is abysmally designed. I eventually gave up the project, and later I found that Tim Bray, also an Erlang noob, had struggled with the exact same issue [1][2]. You would think that this is something Erlang would excel at, but apparently it's not. I have been disappointed with Haskell's string support, too -- it's all over the place (String vs. Text types, the weird Data.Encoding module, horrible regexp library, etc.) -- but at least it's fully Unicode-aware and it has a fast ByteString type. [1] https://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang https://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang [2] https://www.tbray.org/ongoing/When/200x/2007/09/21/Erlang https://www.tbray.org/ongoing/When/200x/2007/09/21/Erlang

davidw 13y ago
I like Erlang a lot, and am currently working on a project that utilizes Chicago Boss, but there's a lot of truth in what you write. Erlang is somewhat strange for a language in that it got put to use in some very important critical systems before it got big. Things like Ruby, Tcl and Python slowly got popular and changed along the way. Doing an Erlang 2.0 that improves on some of the warts is probably not so easy...
- lobster_johnson 13y ago
  That's a good observation. I don't know much about Erlang's history beyond what is on Wikipedia, but I suspect that the number of people that used Erlang before it was open source was relatively small and limited to the technical community within Ericsson. That small, focused user group explains the language's weird and weirdly antiquated style and feature set, but it doesn't quite explain why the language has not been evolved to become more modern. (Of course, the fact that something as ingenious could come out of such a small community is also very impressive and wonderful.)
- lobster_johnson 13y ago
  If you are interested in the history of Erlang, this is fascinating: https://docs.google.com/viewer?url=http%3A%2F%2Fwebcem01.cem.itesm.mx%3A8005%2Ferlang%2Fcd%2Fdownloads%2Fhopl_erlang.pdf https://docs.google.com/viewer?url=http%3A%2F%2Fwebcem01.cem...
jlouis 13y ago
Unicode is a big thing in R16 and R17 where more of the system will use the unicode support we do have. Erlang modules will use utf-8 encoding and so on. As for a built-in bstring() type, it is being discussed, but there are other things more important to get into the language, maps for instance. Erlang is rather conservative in the speed with which we add stuff to the language. Erlang has some of the fastest I/O in a runtime. But it is not easy to use correctly. The same goes for string processing. Erlang can be blinding fast at that, but you must understand how to make it fast.