The future is already here: http://erlangonxen.org/
Why Erlang Matters
11–20 of 210 posts
Re: Why Erlang Matters
#12I'm really tempted to use Erlang/Elixir for a project at work but unsure of its traction. Is it leading edge or trailing edge? I don't even know, but don't want to saddle the firm with a white elephant - even one that is impeccably fault-tolerant. Is Erlang too esoteric?
We've pushed a couple of Elixir apps in the past six months. There was definitely a bit of worry that no one would be able to maintain it, but I have to say that the code is very readable. So many languages integrate some functional aspects that the code doesn't look foreign in most cases.
Also, the Phoenix Framework (if you're building a web app) is really, really nice.
Re: Why Erlang Matters
#13I'm really tempted to use Erlang/Elixir for a project at work but unsure of its traction. Is it leading edge or trailing edge? I don't even know, but don't want to saddle the firm with a white elephant - even one that is impeccably fault-tolerant. Is Erlang too esoteric?
It depends on your location, I think.
Here in New York, it's not too hard to find Erlang enthusiasts, particularly ones that work on Wall Street.
That said, no one seemed to have even heard of the language in Dallas when I lived there.
So the long-story-short of this is that if you don't mind doing some remote-hiring, it's not too hard to find workers, and things like Ejabberd have a ton of tutorials on writing modules.
Re: Why Erlang Matters
#14I'm a very green Erlang noob, but given what I have seen from it I find articles like this kind of strange. Sure concurrent programming is difficult and we need to think hard about how to make programs run quickly in a multiprocessor environment, but the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing. It seems like a language that can scale much better, but has such…
> even strongly typed. A nit: Erlang is strongly typed. You cannot (ok, excluding numbers) almost transparently convert a string into a number into a tuple like you could in C, to which everything is merely memory so casting allows trivial but potentially erroneous conversions. Erlang is dynamically typed, not statically typed. Dialyzer + type annotations (and some inferred) allows for static analysis, but it's not d…
You've hit on the tradeoff though. By decentralizing your state, you've increased your inter-process synchronization requirements. In the worst case everything ends up being tightly bound and your application runs like a single threaded application because everything is always blocked waiting for the state update from a remote thread.
Huge parallelism is easy if your data and processes are largely independent, but the real world is rarely so kind.
Re: Why Erlang Matters
#15Linked article "power-wall" (http://daimi.au.dk/~zxr/papers/treewalls.pdf) seems to be unavailable.
Does anyone working link to this article?
Re: Why Erlang Matters
#16I'm a very green Erlang noob, but given what I have seen from it I find articles like this kind of strange. Sure concurrent programming is difficult and we need to think hard about how to make programs run quickly in a multiprocessor environment, but the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing. It seems like a language that can scale much better, but has such…
I don't see why it is confusing that applications for high concurrency would solve problems differently than big data.
I am also an Erlang noob, but I don't think pattern matching has to account for all parameters. To my understanding erlang pattern matching is very efficient, and anything you would pattern match on function parameters, you would have to do some type of logic in the function if you had no pattern matching, so I don't see how pattern matching would negatively effect performance.
ETS tables to share data between threads actually make a lot of sense if you think of your program with the idea that no matter what "x" is, this process should properly handle it, because you can't guarantee when the message you sent will be processed.
An ETS table is a DB, but you can replicate it by having a single genserver hold that data, and use calls to retrieve and manipulate it. It gives you one spot for your data to be. If you had that same data in messages or function call stacks, by the time the process executes it, it could be stale.
Its useful if you need one "true source" of individual pieces of data that needs to be synchronized. Its about decoupling data from processes.
Re: Why Erlang Matters
#17I'm really tempted to use Erlang/Elixir for a project at work but unsure of its traction. Is it leading edge or trailing edge? I don't even know, but don't want to saddle the firm with a white elephant - even one that is impeccably fault-tolerant. Is Erlang too esoteric?
Embedded systems programmer here. I'm learning Elixir and am very excited about the nerves project:
http://nerves-project.org/
https://www.youtube.com/watch?v=kpzQrFC55q4
Edit: There also seems to be a good Elixir/Erlang community here in Berlin Germany where I live at the moment.
Re: Why Erlang Matters
#18One word: ejabberd. That's why erlang matters to me :)
Re: Why Erlang Matters
#19One word: ejabberd. That's why erlang matters to me :)
Also, it has a great free book on it: http://learnyousomeerlang.com/
Re: Why Erlang Matters
#20I'm a very green Erlang noob, but given what I have seen from it I find articles like this kind of strange. Sure concurrent programming is difficult and we need to think hard about how to make programs run quickly in a multiprocessor environment, but the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing. It seems like a language that can scale much better, but has such…
Erlang may be useful for coordinating computation tasks, but, yes, even with HIPE it is not a good numerical language on its own. It would be interest to re-engineer a language today that tries to fit into Erlang's niche but has a stronger performance focus. Rust, Cloud Haskell, and Go all sort of cluster in the area I'm thinking about, but none are quite what I'm thinking of. Cloud Haskell is probably closest but wr…
This is an easily solved problem. You've been around so what I'm about to tell you is nothing new, but...
In the aughts Ruby and Python were really slow so if you had computational-heavy problems you had to drop into C.
It worked but C isn't great. The thing is - we have a lot of languages that can do computational problems easily now - Rust, Go, Nim, and the list goes on....
It becomes relatively trivial to create libraries which could wrap these languages for Erlang/Elixir. In the few cases where Elixir isn't fast enough, just drop down to something else. Write a small piece of code in Rust (you may as well call Elixir/Rust peanut butter and jelly). Optionally, you could create some kind of DSL which compiles down to another language in Elixir. I did the same with xjs (Elixir syntax, Javascript semantics) [0], and I must say, for a 200-line hack it works really well.
This isn't even considering the fact that a lot more work could be invested in Erlang's VM. Yes, Ericsson is its corporate sponsor but imagine if you had companies trying to make it fast the way they try with Ruby, Python, JS, or another of other more complicated languages.
I think this is relatively low-hanging fruit. You can't tell me that Erlang and Elixir are harder to make fast than other dynamic languages (in most contexts).