Hacker News new | past | comments | ask | show | jobs | submit login

My personal experience has had erlang very poor at handling and manipulating large strings. By poor, let me be clear: slow and spending far too much memory.

We have to be honest identifying our tool's weaknesses, Yariv, even if we like them. EEP-009 (http://www.erlang.org/eeps/eep-0009.html) and EEP-010 (http://www.erlang.org/eeps/eep-0010.html) are extremely important for the continued growth and adoption of Erlang.




I'm curious -- what kind of string processing tasks did you try to use it for? Did you compare its performance to other languages? Also, did you try to use binaries?

Erlang may not be optimal for applications that do heavy string processing, but the significance of that statement is overblown. Take typical webapps for example. What kind of string processing do they do? Very light stuff. They spend of their cycles slurping binary data from the database and sending it down a socket. Erlang is excellent for this usage. They occasionally take form inputs from a user, in which case they do some simple processing to ensure the input is properly escaped. Erlang handles that just fine.

Most of the "Erlang sucks for strings" arguments remind me of the "Ruby/Java is slow" arguments. They're sort-of true, but they just don't matter for most applications.


Why not contact me personally if you'd like more details via Twitter or AIM (this name). The short story: An attempt at a distributed web crawler showed that Erlang's default string type was not suitable for large strings.

Please don't confuse this sentiment with any anti-erlangism or any assertion that Erlang isn't fantastic. I just want to be realistic, and I'd love to have faster string processing to make faster routing code for Fuzed (http://github.com/KirinDave/fuzed/tree/master).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: