3 ms·

Erlang isn't bleeding edge at all. In fact, it's a battle-hardened and conservatively evolving platform dating back to 1986, which is one of its selling points

Erlang isn't bleeding edge at all. In fact, it's a battle-hardened and conservatively evolving platform dating back to 1986, which is one of its selling points amongst all the technical benefits.

nostrademons 12y ago
Depends on your problem domain. It absolutely is battle-hardened and conservatively evolving, but it grew up in the telecom industry, and most of its "mainstream" uses (Facebook chat, Whatsapp) are in messaging. Erlang strings, for example, are lists of bytes, which will blow up your memory requirements and algorithmic complexity if you do any serious string parsing. You're shut out of common libraries like protobufs. There are libraries available for things like HTML parsing, MySQL, Postgres, and even Apple Push Notifications/Google Cloud Messaging, but many of them are some guy's personal project on GitHub rather than something that's gotten widespread use & testing and has plenty of StackOverflow posts for help.
- vezzy-fnord 12y ago
  Lists of Unicode points (integers), specifically. That said, most real world string manipulation is done by passing them as binaries. It really isn't much of an issue, nowhere near as much as is the hell that is NULL-terminated character arrays in C, which, mind you, power most of our software nonetheless. Erlang does have a good Protocol Buffers library, by the way: https://github.com/basho/erlang_protobuffs https://github.com/basho/erlang_protobuffs. Even if it didn't, you'd use a more native serialization format like BERT. As for abandoned projects and library sprawl, that is true. However, I'd say that this is far more bearable in Erlang than in other languages. For one, the module system makes deducing how to use a program's API from source code much easier even if there is no explicit documentation - every Erlang program basically gets a user interface for free just by virtue of being a module. In addition, if the library in question is a properly structured OTP application or if it uses vanilla process primitives efficiently, I can have relative confidence that it is less likely to blow up in my face than, e.g. a random Java library. Even still, there's all sorts of libraries despite the small community. If you're doing web development and there's some RESTful API that has no Erlang bindings, those are relatively trivial to roll yourself.
yellowapple 12y ago
Elixir, on the other hand, is still a bit bloody on the edges (and the MVC-ish frameworks for it are very much bleeding edge), but because it's built on the same foundations as Erlang, it ends up getting a lot of its benefits (and a lot of the existing ecosystem), which puts it uniquely in-between "boring" and "shiny".

Erlang isn't bleeding edge at all. In fact, it's a battle-hardened and conservatively evolving platform dating back to 1986, which is one of its selling points amongst all the technical benefits.

nostrademons 12y ago

Depends on your problem domain. It absolutely is battle-hardened and conservatively evolving, but it grew up in the telecom industry, and most of its "mainstream" uses (Facebook chat, Whatsapp) are in messaging. Erlang strings, for example, are lists of bytes, which will blow up your memory requirements and algorithmic complexity if you do any serious string parsing. You're shut out of common libraries like protobufs. There are libraries available for things like HTML parsing, MySQL, Postgres, and even Apple Push Notifications/Google Cloud Messaging, but many of them are some guy's personal project on GitHub rather than something that's gotten widespread use & testing and has plenty of StackOverflow posts for help.

vezzy-fnord 12y ago
Lists of Unicode points (integers), specifically. That said, most real world string manipulation is done by passing them as binaries. It really isn't much of an issue, nowhere near as much as is the hell that is NULL-terminated character arrays in C, which, mind you, power most of our software nonetheless. Erlang does have a good Protocol Buffers library, by the way: https://github.com/basho/erlang_protobuffs https://github.com/basho/erlang_protobuffs. Even if it didn't, you'd use a more native serialization format like BERT. As for abandoned projects and library sprawl, that is true. However, I'd say that this is far more bearable in Erlang than in other languages. For one, the module system makes deducing how to use a program's API from source code much easier even if there is no explicit documentation - every Erlang program basically gets a user interface for free just by virtue of being a module. In addition, if the library in question is a properly structured OTP application or if it uses vanilla process primitives efficiently, I can have relative confidence that it is less likely to blow up in my face than, e.g. a random Java library. Even still, there's all sorts of libraries despite the small community. If you're doing web development and there's some RESTful API that has no Erlang bindings, those are relatively trivial to roll yourself.

yellowapple 12y ago

Elixir, on the other hand, is still a bit bloody on the edges (and the MVC-ish frameworks for it are very much bleeding edge), but because it's built on the same foundations as Erlang, it ends up getting a lot of its benefits (and a lot of the existing ecosystem), which puts it uniquely in-between "boring" and "shiny".