5 ms·

This. It's amazing and powerful if you need 1m+ client connections per server. Outside of the epic scale engineering problems of facebook, twitter, google, amaz

by timje1 13y ago

This. It's amazing and powerful if you need 1m+ client connections per server. Outside of the epic scale engineering problems of facebook, twitter, google, amazon, whatsapp... It's very difficult to get anything done with Erlang. If you have fewer than a million people using your application at a time, you're probably better off writing it in a more normal language.

IsTom 13y ago
I disagree. Erlang is great for even small applications, as long as they're never turned off.
Jtsummers 13y ago
I'd say it works for small scale as well. The concurrency is awesome, but (and this may just be from limited experience) I've yet to see another language that handles binary matching and manipulation as well. I tried to sell my current office on erlang for one project. Take a dozen mutually incompatible protocols (used by systems that can't be updated easily to a new or common protocol, that's actually been tried and is why there are a dozen protocols now) and create a proxy/translator server for all of them. In essence we have a dozen networks that can't talk to each other, but send the same information using their own formats. Writing a translator from one protocol to another (or my suggestion of one protocol to intermediate representation to second protocol, need only 24 translation modules instead of 12! translation modules) was trivial for my proof of concept sytem. The concurrency was really just a nice bonus, in this case.
davidw 13y ago
That's the hype, but if you ask the people who built it, it's actually more about fault tolerance than scaling. And indeed, I'm using it for a semi-embedded system where stability is important, something that Go and Node.js, for instance, didn't seem quite ready for when we evaluated them a year ago. Erlang is pretty rock solid and is something that we'll be happy to have running without worries.
erichocean 13y ago
It's amazing and powerful if you need 1m+ client connections per server. It's pretty dang easy to do that today with LuaJIT/C, and you don't get any of the other baggage (weird syntax, sub-standard string handling, lack of libs, etc.). I'm literally building something that is right in Erlang's wheelhouse—exactly what is is designed for, and I'm not using it, despite knowing that, because it's easier for me to get exactly what I want in LuaJIT/C today. I get garbage collection when I want it. I get arena allocation when I want it, too. I get custom JIT-compiled functions when I want them (DynASM), but I also get JIT-compiled methods in Lua when performance matters less. I can talk directly to my network hardware with a driver written in Lua. That's likely possible in Erlang, but I have no idea how and no time to learn, either. I also know how to solve anything I'm likely to encounter in C. With Erlang, I'd have to learn a new way to solve it. Who knows how long that would take to do well? I really do like Erlang at the conceptual level, but not enough to endure all of the other things I don't like about it. I'm also far less concerned about C than I was 10 years ago. The tooling around C these days is really quite incredible for people who want to do safety-critical systems, or high-availability systems, or whatever. You can get as much assurance about your code as you want with a reasonable amount of effort.
- rvirding 13y ago
  Yes, and you will end up reimplementing a lot of what is already in Erlang and most likely not as well either. Virding's 1st rule.
  - hapless 13y ago
    This is true, but it misses the point: Erlang is missing enough things that this fellow would rather rewrite OTP in Lua than deal with Erlang. e.g. string handling
    - rvirding 13y ago
      From personal experience implementing the string handling is trivial compared to implementing the system side of Erlang. Get real.
banachtarski 13y ago
There are plenty of applications that would benefit from massive low latency concurrency. Connections is too specific a problem.

by timje1 13y ago

IsTom 13y ago

I disagree. Erlang is great for even small applications, as long as they're never turned off.

Jtsummers 13y ago

I'd say it works for small scale as well. The concurrency is awesome, but (and this may just be from limited experience) I've yet to see another language that handles binary matching and manipulation as well. I tried to sell my current office on erlang for one project. Take a dozen mutually incompatible protocols (used by systems that can't be updated easily to a new or common protocol, that's actually been tried and is why there are a dozen protocols now) and create a proxy/translator server for all of them. In essence we have a dozen networks that can't talk to each other, but send the same information using their own formats. Writing a translator from one protocol to another (or my suggestion of one protocol to intermediate representation to second protocol, need only 24 translation modules instead of 12! translation modules) was trivial for my proof of concept sytem. The concurrency was really just a nice bonus, in this case.

davidw 13y ago

That's the hype, but if you ask the people who built it, it's actually more about fault tolerance than scaling. And indeed, I'm using it for a semi-embedded system where stability is important, something that Go and Node.js, for instance, didn't seem quite ready for when we evaluated them a year ago. Erlang is pretty rock solid and is something that we'll be happy to have running without worries.

erichocean 13y ago

It's amazing and powerful if you need 1m+ client connections per server. It's pretty dang easy to do that today with LuaJIT/C, and you don't get any of the other baggage (weird syntax, sub-standard string handling, lack of libs, etc.). I'm literally building something that is right in Erlang's wheelhouse—exactly what is is designed for, and I'm not using it, despite knowing that, because it's easier for me to get exactly what I want in LuaJIT/C today. I get garbage collection when I want it. I get arena allocation when I want it, too. I get custom JIT-compiled functions when I want them (DynASM), but I also get JIT-compiled methods in Lua when performance matters less. I can talk directly to my network hardware with a driver written in Lua. That's likely possible in Erlang, but I have no idea how and no time to learn, either. I also know how to solve anything I'm likely to encounter in C. With Erlang, I'd have to learn a new way to solve it. Who knows how long that would take to do well? I really do like Erlang at the conceptual level, but not enough to endure all of the other things I don't like about it. I'm also far less concerned about C than I was 10 years ago. The tooling around C these days is really quite incredible for people who want to do safety-critical systems, or high-availability systems, or whatever. You can get as much assurance about your code as you want with a reasonable amount of effort.

rvirding 13y ago
Yes, and you will end up reimplementing a lot of what is already in Erlang and most likely not as well either. Virding's 1st rule.
- hapless 13y ago
  This is true, but it misses the point: Erlang is missing enough things that this fellow would rather rewrite OTP in Lua than deal with Erlang. e.g. string handling
  - rvirding 13y ago
    From personal experience implementing the string handling is trivial compared to implementing the system side of Erlang. Get real.

banachtarski 13y ago

There are plenty of applications that would benefit from massive low latency concurrency. Connections is too specific a problem.