Live data from Hacker News

Erlang is at long last getting the break it deserves.

scaleordie.com

11–18 of 18 posts

Re: Erlang is at long last getting the break it deserves.

#11

Erlang may be getting the "recognition" it deserves, but... the "break" it deserves? Really? Come on guys, give Erlang a break.

Also... "deserves" ?

Erlang deserves nothing. Its just another language - one which I happen to think has filthy syntax, and will probably never use for that reason.

Re: Erlang is at long last getting the break it deserves.

#12
post #7

Earlier quoted context omitted.

Erlang is best for software that works like telco switches, i.e., you have the need to route thousands of messages in real-time. Chat, IM, SMS, message queues, etc. are all well-suited for Erlang. Tasks that involves lots of I/O and parsing, not so much.

So you're suggesting that IM, Chat, SMS and message queues aren't about Parsing and I/O? Erlang has weaknesses, but certainly those are not it. Basically, Erlang excells at writing servers. Take a look at YAWS ( http://yaws.hyber.org/ ) for a web server written in Erlang that can actually outperform more traditional web servers in very realistic scenarios. If I had to name a weakness or two of erlang offhand: 1. Inte…

Representing strings as lists can be very efficient depends on what you're trying to do. Incidentally, Haskell does the same thing.

I think the "Erlang sucks for strings" argument is overblown, and it's rarely if ever backed by real world experience and/or data. Erlang is fine for most string handling tasks you'll find in a typical (web) application.

Re: Erlang is at long last getting the break it deserves.

#13
post #2

Yeah, it's got some visibility. The question is: will they be able to run with it? Erlang does some stuff really well, and other things not so well. Will it remain the right tool for a specific job, or something people also use for a variety of tasks? Despite knowing and liking Erlang, my guess is that the first is likelier to occur: http://journal.dedasys.com/articles/2007/09/22/erlang

Erlang is great for writing high-availability, low latency server-based applications -- including web applications.

What people will use it for is up to their imagination. Wings3d (http://www.wings3d.com/) is a good example of using Erlang outside of its "intended" domain.

Don't forget that when Java came out, it was only "good" for writing applets...

Re: Erlang is at long last getting the break it deserves.

#15
post #12

Earlier quoted context omitted.

So you're suggesting that IM, Chat, SMS and message queues aren't about Parsing and I/O? Erlang has weaknesses, but certainly those are not it. Basically, Erlang excells at writing servers. Take a look at YAWS ( http://yaws.hyber.org/ ) for a web server written in Erlang that can actually outperform more traditional web servers in very realistic scenarios. If I had to name a weakness or two of erlang offhand: 1. Inte…

Representing strings as lists can be very efficient depends on what you're trying to do. Incidentally, Haskell does the same thing. I think the "Erlang sucks for strings" argument is overblown, and it's rarely if ever backed by real world experience and/or data. Erlang is fine for most string handling tasks you'll find in a typical (web) application.

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.

Re: Erlang is at long last getting the break it deserves.

#16
post #12

Earlier quoted context omitted.

Representing strings as lists can be very efficient depends on what you're trying to do. Incidentally, Haskell does the same thing. I think the "Erlang sucks for strings" argument is overblown, and it's rarely if ever backed by real world experience and/or data. Erlang is fine for most string handling tasks you'll find in a typical (web) application.

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 Erl…

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.

Re: Erlang is at long last getting the break it deserves.

#17
post #16

Earlier quoted context omitted.

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 Erl…

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 slu…

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).

Re: Erlang is at long last getting the break it deserves.

#18
post #7
post #3

I've not tried it yet, but we have to do a particular distributed crawler app for something and it's been recommended to look at it. For me if a language is amazing at something then it would be prudent to focus on that. I often use more than one language in my projects - the best language for the particular job.

Erlang is best for software that works like telco switches, i.e., you have the need to route thousands of messages in real-time. Chat, IM, SMS, message queues, etc. are all well-suited for Erlang. Tasks that involves lots of I/O and parsing, not so much.

I have done quite a bit of work in Erlang over the past 4 or so years. I even wrote an anti-spam engine hat was heavy on parsing.

The best thing Erlang has going in the parsing area is the binary pattern matching, which if you convert a string to a binary works wonders and is much faster. IN fact switching a string to a binary, doing your parsing with binary pattern matching and switching it back to a string CAN be faster in Erlang than using Erlang's string functions.

I won't go into comparisons to other languages, mostly because my personal opinion is that Erlang has so many other great features that not being good at string processing is a minor issue.

Post reply on HN