Ask HN: Why isn't Erlang more popular?
243 comments
Erlang is a very specialised language. It does one thing well (scalability) at the expense of not really being a general purpose language.
The syntax is just weird, not only in a paradigm-way (pattern matching is not huge in most languages, but, hey, that's the way of doing stuff in functional programming), but on strange places ("read" lines ending on dot, semicolon takes time, it does not share any common syntax definitions with the languages used by 99% of the programmers). That sets a high bar in approaching the language, so it's difficult to "play around" with it (at least compared with other languages)
While I like some of the advantages of Erlang, the lack of general support for a lot of common operations (and yes, string manipulation is a huge deal) and the fact that it is designed with a very very particular problem in mind makes it "a silver bullet". Not in the usual meaning, but in the way that's only useful for killing a werewolf. For every other task is too expensive and just not the proper tool. I was involved in a project that used Erlang for something not well suited for it, and it was absolutely awful, you have to wrestle with it to perform common stuff that in other languages is done by the standard library. Again, you win something, but only in a very very VERY specific problem.
(I've used it in another project when it was the proper tool, and, in that case, it's still not the most pleasant experience, but you're getting a clear win)
The syntax is just weird, not only in a paradigm-way (pattern matching is not huge in most languages, but, hey, that's the way of doing stuff in functional programming), but on strange places ("read" lines ending on dot, semicolon takes time, it does not share any common syntax definitions with the languages used by 99% of the programmers). That sets a high bar in approaching the language, so it's difficult to "play around" with it (at least compared with other languages)
While I like some of the advantages of Erlang, the lack of general support for a lot of common operations (and yes, string manipulation is a huge deal) and the fact that it is designed with a very very particular problem in mind makes it "a silver bullet". Not in the usual meaning, but in the way that's only useful for killing a werewolf. For every other task is too expensive and just not the proper tool. I was involved in a project that used Erlang for something not well suited for it, and it was absolutely awful, you have to wrestle with it to perform common stuff that in other languages is done by the standard library. Again, you win something, but only in a very very VERY specific problem.
(I've used it in another project when it was the proper tool, and, in that case, it's still not the most pleasant experience, but you're getting a clear win)
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.
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.
I disagree. Erlang is great for even small applications, as long as they're never turned off.
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.
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.
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.
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.
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.
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
e.g. string handling
From personal experience implementing the string handling is trivial compared to implementing the system side of Erlang. Get real.
For those following along at home, rvirding is one of the inventors of Erlang.
Robert - one of the things that occasionally bothers me about Erlang is that if something like string handling is so trivial, then it should be made available as a more extensive library, rather than an exercise that leaves the reader wishing they were using another language that handles boring stuff like that. It may well not be trivial for the person just get started with it, and you've lost a user if they give up in frustration.
Here's one of the other inventors of the language asking for help about splitting a string, for instance:
http://erlang.org/pipermail/erlang-questions/2014-February/0...
Robert - one of the things that occasionally bothers me about Erlang is that if something like string handling is so trivial, then it should be made available as a more extensive library, rather than an exercise that leaves the reader wishing they were using another language that handles boring stuff like that. It may well not be trivial for the person just get started with it, and you've lost a user if they give up in frustration.
Here's one of the other inventors of the language asking for help about splitting a string, for instance:
http://erlang.org/pipermail/erlang-questions/2014-February/0...
Well not quite splitting a string, using regexs. Regexs are The language Satan communicates with his minions in...
Someone implemented a DSL lua on Erlang VM already.
That'll be Robert Virding (see comment below) lol
Yes, that's me. Where is the "comment below"? Couldn't find it.
I just want to point out that I don't dislike Lua at all, it is a small neat language with some very nice features. It just isn't something on which I would base a parallel system as it has too much sharing and other things which don't go parallel easily. Using it as plugin to erlang for doing "business" logic works quite well, either by communicating with a Lua system or doing like Luerl and implementing it Erlang. This means that Luerl meshes completely with Erlang.
I just want to point out that I don't dislike Lua at all, it is a small neat language with some very nice features. It just isn't something on which I would base a parallel system as it has too much sharing and other things which don't go parallel easily. Using it as plugin to erlang for doing "business" logic works quite well, either by communicating with a Lua system or doing like Luerl and implementing it Erlang. This means that Luerl meshes completely with Erlang.
HN reorders comments on the fly - so your comment floated up...
There are plenty of applications that would benefit from massive low latency concurrency. Connections is too specific a problem.
I haven't looked at Erlang before, so I thought I give it a quick look. Google led me to the Erlang home page[1], which has "What is Erlang" (sounds good) and "What is OTP" (which doesn't bother to define what O, T, and P stand for.)
Following the Erlang Quickstart [2] link, I get a page that doesn't really tell me anything about the language. It demonstrates a program that implements a factorial function, then tells me to go write games. Other than "Burn the CPU", I'm not sure what kind of games I can write with what I learned here.
The first link to more documentation at the bottom of the page goes to a book's website, so that's a dead end. The second link goes to an online reference guide [3] which seems more promising, until I read the introduction [4]. Under "Things Left Out" is "How to communicate with the outside world". Hrm...
So, what I have so far is that Erlang is a functional language, and that the online reference doesn't cover interaction with anything outside of your program. Based on this I'm guessing that Erlang is one of those functional languages that are great for mathematical proof-like software development but not practical for solving actual problems because the world is mutable and the language constructs are not. Yes, I'm making a big inference here, but that definitely seems like where I'm heading.
So I'm going to stop here, and do some real work in a pragmatic language.
[1] http://www.erlang.org
[2] http://www.erlang.org/static/getting_started_quickly.html
[3] http://www.erlang.org/doc/getting_started/users_guide.html
[4] http://www.erlang.org/doc/getting_started/intro.html#id62800
Following the Erlang Quickstart [2] link, I get a page that doesn't really tell me anything about the language. It demonstrates a program that implements a factorial function, then tells me to go write games. Other than "Burn the CPU", I'm not sure what kind of games I can write with what I learned here.
The first link to more documentation at the bottom of the page goes to a book's website, so that's a dead end. The second link goes to an online reference guide [3] which seems more promising, until I read the introduction [4]. Under "Things Left Out" is "How to communicate with the outside world". Hrm...
So, what I have so far is that Erlang is a functional language, and that the online reference doesn't cover interaction with anything outside of your program. Based on this I'm guessing that Erlang is one of those functional languages that are great for mathematical proof-like software development but not practical for solving actual problems because the world is mutable and the language constructs are not. Yes, I'm making a big inference here, but that definitely seems like where I'm heading.
So I'm going to stop here, and do some real work in a pragmatic language.
[1] http://www.erlang.org
[2] http://www.erlang.org/static/getting_started_quickly.html
[3] http://www.erlang.org/doc/getting_started/users_guide.html
[4] http://www.erlang.org/doc/getting_started/intro.html#id62800
> Based on this I'm guessing that Erlang is one of those functional languages that are great for mathematical proof-like software development but not practical for solving actual problems because the world is mutable and the language constructs are not.
It was actually designed to solve actual problems. Specifically, extremely high reliability in some of Ericsson's core networking gear.
I'd recommend Learn You Some Erlang[0] if you intend to look at it again. It explains the language, then OTP (the Open Telephony Platform - a framework for defining Erlang process trees and failure modes), then basic outside communication and disk storage.
[0] http://learnyousomeerlang.com/
It was actually designed to solve actual problems. Specifically, extremely high reliability in some of Ericsson's core networking gear.
I'd recommend Learn You Some Erlang[0] if you intend to look at it again. It explains the language, then OTP (the Open Telephony Platform - a framework for defining Erlang process trees and failure modes), then basic outside communication and disk storage.
[0] http://learnyousomeerlang.com/
You misunderstand his point. He isn't saying that Erlang is a toy language, he is saying that documentation makes Erlang look like a toy language.
i.e. showing him how his thought was wrong doesn't change the fact that many other people will probably make a similar thoughts.
i.e. showing him how his thought was wrong doesn't change the fact that many other people will probably make a similar thoughts.
No, I understood the OP's point, I just decided to point them towards a better resource in the case that they do want to learn more about it at some point. I agree that the Erlang site is utterly dreadful.
Fair enough, just misunderstood your tone, my apologies.
Yessum, it is indeedy...
Ffs, you're not looking at some small product that an unknown company built. You're looking at something that is really well-known. What does the website of Google convey? Do you really decide whether you'd learn a language by looking at its website?
> "that the online reference doesn't cover interaction with anything outside of your program" This does NOT mean it does not teach you IO. The full bullet point is
> "How to communicate with the outside world and/or software written in other languages (ports). There is however a separate tutorial for this, Interoperability Tutorial"
It means it won't teach you FFI in a tutorial.
> "guessing that Erlang is one of those functional languages that are great for mathematical proof-like software development but not practical for solving actual problems because the world is mutable and the language constructs are not."
I don't know how you got to this dumb conclusion when "What is Erlang?" on the main page clearly states:
> Erlang is a programming language used to build massively scalable soft real-time systems with requirements on high availability. Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance.
> "that the online reference doesn't cover interaction with anything outside of your program" This does NOT mean it does not teach you IO. The full bullet point is
> "How to communicate with the outside world and/or software written in other languages (ports). There is however a separate tutorial for this, Interoperability Tutorial"
It means it won't teach you FFI in a tutorial.
> "guessing that Erlang is one of those functional languages that are great for mathematical proof-like software development but not practical for solving actual problems because the world is mutable and the language constructs are not."
I don't know how you got to this dumb conclusion when "What is Erlang?" on the main page clearly states:
> Erlang is a programming language used to build massively scalable soft real-time systems with requirements on high availability. Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance.
> Do you really decide whether you'd learn a language by looking at its website?
I certainly could see myself doing that. It's usually indicative of the leadership and community that's associated with the language. In Erlang's case I understand that it's pretty niche in the big scheme of things, and that might be the reason. In terms of languages if the information presented isn't on the level of Java, PHP, Ruby, Python and others it comes off as sub-par. That may not be the reality but it's the perception IMO.
I certainly could see myself doing that. It's usually indicative of the leadership and community that's associated with the language. In Erlang's case I understand that it's pretty niche in the big scheme of things, and that might be the reason. In terms of languages if the information presented isn't on the level of Java, PHP, Ruby, Python and others it comes off as sub-par. That may not be the reality but it's the perception IMO.
> You're looking at something that is really well-known. What does the website of Google convey?
The Google comparison is comical. You are wildly over-estimating how well known Erlang is, even in the dev community.
> Do you really decide whether you'd learn a language by looking at its website?
Most devs learn a new language when it helps them solve a problem. Anyone who needs to solve the problems that Erlang addresses has already at least looked at Erlang.
This thread was also directed at those who have never used Erlang. Starting with the Erlang website makes eminent sense.
Specific example :
Compare the Erland and Rust websites. I've never used Rust or Erlang. I can confidently say that the Rust website does a better job of familiarizing a new user with the language. It's not just a matter of the Rust syntax being C-derived, either. It's simply harder to find any useful information on the Erlang website.
Rust :
The Google comparison is comical. You are wildly over-estimating how well known Erlang is, even in the dev community.
> Do you really decide whether you'd learn a language by looking at its website?
Most devs learn a new language when it helps them solve a problem. Anyone who needs to solve the problems that Erlang addresses has already at least looked at Erlang.
This thread was also directed at those who have never used Erlang. Starting with the Erlang website makes eminent sense.
Specific example :
Compare the Erland and Rust websites. I've never used Rust or Erlang. I can confidently say that the Rust website does a better job of familiarizing a new user with the language. It's not just a matter of the Rust syntax being C-derived, either. It's simply harder to find any useful information on the Erlang website.
Rust :
* code sample on landing page
* comprehensive tutorial linked directly from landing page
* no code on landing page
* "quick start guide" which is basically a link to a non-free book
* Getting to actual code requires 3-4 clicks from the landing page
* e.g. Documentation -> Course -> Sequential Programming
> Starting with the Erlang website makes eminent sense
Of course it does. But stopping at the Erlang website because of the website makes much less sense. Find some other way to know more about the language and then decide whether you'll use it or not.
Of course it does. But stopping at the Erlang website because of the website makes much less sense. Find some other way to know more about the language and then decide whether you'll use it or not.
Remember that the title of this thread is "Why isn't Erlang more popular?", not "Why Erlang is so great you'll try multiple times to seek out documentation for it".
>You are wildly over-estimating how well known Erlang is, even in the dev community
Well, it's pretty well known in the competent dev community. Some guy doing CRUD apps for some enterprise might not know it, true.
Well, it's pretty well known in the competent dev community. Some guy doing CRUD apps for some enterprise might not know it, true.
lol. This silly elitism needs to die.
Why, because all programming endeavours are equally hard or important, and all programmers have equal skills?
In this make believe scenario, the world is divided neatly into opposing camps of "competent devs" and "enterprise CRUD devs". It's dismissive, cheap analysis at its best. It's a straw man whose only real purpose is to embolden us with a smug sense of superiority.
It's also empirically correct.
I've worked for enterprise.
Also I didn't say it is divided "neatly". Why do people always assume that when you talk about a group of people being Y, all of them must be Y?
It's enough that the statistical majority of them be Y (e.g 90% of enterprise developers not really knowing about the wider world outside enterprise software practices). That there will be exceptions it's obvious -- there are exceptions everywhere.
I've worked for enterprise.
Also I didn't say it is divided "neatly". Why do people always assume that when you talk about a group of people being Y, all of them must be Y?
It's enough that the statistical majority of them be Y (e.g 90% of enterprise developers not really knowing about the wider world outside enterprise software practices). That there will be exceptions it's obvious -- there are exceptions everywhere.
Imagine you know nothing about Erlang, as the poster was pretending. How do you decide if it's worth your time to learn more about that language/platform? Certainly what the official website tells you factors into that largely.
You seem to be looking into this from the perspective that everyone must already know what Erlang is all about, so there doesn't need to be an effort to reach out to new users - which would contradict the questions the OP is asking.
You seem to be looking into this from the perspective that everyone must already know what Erlang is all about, so there doesn't need to be an effort to reach out to new users - which would contradict the questions the OP is asking.
I'm not saying that Erlang shouldn't reach out to new users. I'm saying that new users should look past the website and put in a little effort to know about Erlang. Dismissing a language because of the its website is not just right.
Come on! I am writing LuvvieScript a compile-to-javascript dialect of Erlang.
This is a list of compile-to-javascript languages: https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
Is any developer going to give every language on that list the same consideration?
No. Not possible.
This is a list of compile-to-javascript languages: https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
Is any developer going to give every language on that list the same consideration?
No. Not possible.
"Do you really decide whether you'd learn a language by looking at its website?"
Kind of! Irrespective of Erlang's site, a well-maintained, informative, and newbie friendly website is often a signal. Maybe it's not a very accurate signal. But it's a signal which suggests that, for lack of a better term, the community exists and has its act together.
There are enough other things to occupy programmers' time. People adopt heuristics like these — "how professional/modern does the website look?" — as a way to save time.
Kind of! Irrespective of Erlang's site, a well-maintained, informative, and newbie friendly website is often a signal. Maybe it's not a very accurate signal. But it's a signal which suggests that, for lack of a better term, the community exists and has its act together.
There are enough other things to occupy programmers' time. People adopt heuristics like these — "how professional/modern does the website look?" — as a way to save time.
> (which doesn't bother to define what O, T, and P stand for.)
It obviously stands for Outlaw Techno Psychobitch ;).
http://www.youtube.com/watch?feature=player_detailpage&v=rRb... (Erlang The Movie II)
It obviously stands for Outlaw Techno Psychobitch ;).
http://www.youtube.com/watch?feature=player_detailpage&v=rRb... (Erlang The Movie II)
> The first link to more documentation at the bottom of the page goes to a book's website, so that's a dead end.
Why are you saying a link to Learn You Some Erlang for Great Good [1] is a dead end? Have you missed the "Read it online" button?
[1] http://www.learnyousomeerlang.com
Why are you saying a link to Learn You Some Erlang for Great Good [1] is a dead end? Have you missed the "Read it online" button?
[1] http://www.learnyousomeerlang.com
>The first link to more documentation at the bottom of the page goes to a book's website, so that's a dead end.
Well, you can read the book online, so how's that a dead end?
>So I'm going to stop here, and do some real work in a pragmatic language.
Well, $16B for WhatsApp, for a company with like 40 engineers, proves that Erlang can be quite pragmatic itself.
Well, you can read the book online, so how's that a dead end?
>So I'm going to stop here, and do some real work in a pragmatic language.
Well, $16B for WhatsApp, for a company with like 40 engineers, proves that Erlang can be quite pragmatic itself.
Come on. Not exactly a good faith effort, is it? Why type in a rant like this, when you could have found a wonderful tutorial on Google in one tenth of the time it took you to write this?
100% of erlang tutorials are for fibonnaci.
I once challenged Scott Fritchie to give an Erlang talk at our local ruby group (rum.mn) without implementing Eratosthenes' sieve, and sure enough he did, using elevators of all things.
I was so impressed with Erlang that i'm still banging my head on it nearly 10 (half-hearted) years later.
I was so impressed with Erlang that i'm still banging my head on it nearly 10 (half-hearted) years later.
I never understood why every language has a plethora of fibonnaci tutorials. "DO THE FIBONNACI IN X USING Z PROGRAMMING PARADIGM" ok thanks, no more please.
Because you already:
1. Know what the Fibonnaci numbers are.
2. How to compute them.
3. Said computation is straight-forward, but it requires some form of looping (either recursion or iteration) and some form of arithmetic.
The combination of those traits means that if I present code to compute the Fibonnaci number for an arbitrary number in some random programming language, you can infer a lot about that programming language. In other words, the only variable in that situation is the programming language itself, which allows you to use the other information you already know to learn about that language relatively quickly.
1. Know what the Fibonnaci numbers are.
2. How to compute them.
3. Said computation is straight-forward, but it requires some form of looping (either recursion or iteration) and some form of arithmetic.
The combination of those traits means that if I present code to compute the Fibonnaci number for an arbitrary number in some random programming language, you can infer a lot about that programming language. In other words, the only variable in that situation is the programming language itself, which allows you to use the other information you already know to learn about that language relatively quickly.
I don't think so.
He's doing this in good faith because I, the original poster, asked him too. This is the best answer on the page (for me).
But this doesn't tell you anything, other than that someone who's not interested and pressed for time won't put any effort into it. It's a trivial result.
Well, if the question is "Why isn't Erlang more popular?" then I would think that pointing out that "someone who's not interested and pressed for time won't put any effort into it" is a perfectly fine answer. The clear implication is that the resources currently available for would-be Erlang adopters require an unrealistic level of interest and time to get them over the hump. It tells an Erlang evangelist precisely what she needs to do: do more to sell the language to people who have little time or inclination to rally dig into a language they otherwise know nothing about. (Of course, while it may be a useful answer, it is not very interesting for the rest of us.)
> the resources currently available for would-be Erlang adopters require an unrealistic level of interest and time to get them over the hump.
The person who can't be bothered to even find 'Learn You Some Erlang' also won't have the motivation to learn Erlang. It does take effort, but there now are many good resources available (unlike the situation just a few years ago).
The person who can't be bothered to even find 'Learn You Some Erlang' also won't have the motivation to learn Erlang. It does take effort, but there now are many good resources available (unlike the situation just a few years ago).
I believe you missed the point. When I first heard about Go, I went to the official website and I was immediately presented with a few code examples. The go tour was fascinatingly good introductory material. Furthermore, the documentation and language specification are very concise, clear and full of examples.
What am I trying to say? Put effort into presenting your language and I will put effort into going through the material.
Give me two shit and that's how much interest you will get from me.
However, I put my own effort into finding more resources. I tried Erlang, it was OK, but I wasn't very comfortable working with the syntax. I've never needed any special feature in Erlang that I couldn't accomplish in another language.
What am I trying to say? Put effort into presenting your language and I will put effort into going through the material.
Give me two shit and that's how much interest you will get from me.
However, I put my own effort into finding more resources. I tried Erlang, it was OK, but I wasn't very comfortable working with the syntax. I've never needed any special feature in Erlang that I couldn't accomplish in another language.
No, I get the point, but I don't agree with it, at least not to that extent.
> Put effort into presenting your language and I will put effort into going through the material. Give me two shit and that's how much interest you will get from me.
See, I really don't think it's worth courting people who have that attitude. If your motivation is _that_ low, it's probably not for you anyway. At this point, even people who don't have a real need for Erlang/OTP, but who still enjoy learning for the sake of learning, can find great introductory material.
> Put effort into presenting your language and I will put effort into going through the material. Give me two shit and that's how much interest you will get from me.
See, I really don't think it's worth courting people who have that attitude. If your motivation is _that_ low, it's probably not for you anyway. At this point, even people who don't have a real need for Erlang/OTP, but who still enjoy learning for the sake of learning, can find great introductory material.
Lots of people enjoy learning for the sake of learning, but there is an infinite amount of things out there for people to learn. If you don't spend some effort to convince people "Hey, this thing there is really worth learning!" then they won't - even if they are not lazy. No one - even non-lazy people - has the time to learn about everything.
> See, I really don't think it's worth courting people who have that attitude.
What attitude? Someone goes to a website out of curiosity, but it isn't very helpful so they leave. (Who hasn't done this?)
Erlang might be EXACTLY the thing they need, but on the subject of why Erlang isn't more popular--subpar marketing is more than relevant.
What attitude? Someone goes to a website out of curiosity, but it isn't very helpful so they leave. (Who hasn't done this?)
Erlang might be EXACTLY the thing they need, but on the subject of why Erlang isn't more popular--subpar marketing is more than relevant.
The person who can't be bothered to find something they don't know exists. Seriously?
It tells you that the primary route to finding out about Erlang for someone who knots nothing about it (ie Google it and have a nosey) its no bloody good.
If someone tells me to try out a new language I generally give it about 10-15 minutes. If I'm not running hello world by then I'm not interested in something I'd be taking a casual interest in. The only time I'm giving it more than 15 minutes is when I have a real business need for it or want to enhance my resume with something that has a lot of businesses seeking that skill. Python, for example, I was easily able to get up and running in under 15 minutes with a hello world and now I use it regularly for lots of little tasks. I can't be fussed to toy around something that takes too much work/infrastructure to get up and running. There's other options out there I can be more productive in faster.
My theory: writing network servers that are not web servers is a relatively uncommon problem to have these days.
One of the hardest parts about learning a new language is coming up with a learning project that showcases the unique strengths of the language without being intimidating to a newcomer or too contrived to actually be useful. This is difficult in any language, but it's especially so in Erlang.
Obviously "it's different; people don't like things that are different" has a lot to do with it, but we've seen other FP languages experiencing faster growth recently, so I don't think that can be the only cause.
I've been using it for a few months, for what it's worth.
Edit: obviously there are lots of people who need to write concurrent network server clusters, but I'd argue that the benefits of the Erlang approach are difficult to grasp before you've actually deployed something written in Erlang; simple toy projects (which are a prerequisite to learning a language) don't usually play to its strengths. A language that's really good at web apps is going to grow more quickly simply because its advantages are easier to appreciate from the start.
One of the hardest parts about learning a new language is coming up with a learning project that showcases the unique strengths of the language without being intimidating to a newcomer or too contrived to actually be useful. This is difficult in any language, but it's especially so in Erlang.
Obviously "it's different; people don't like things that are different" has a lot to do with it, but we've seen other FP languages experiencing faster growth recently, so I don't think that can be the only cause.
I've been using it for a few months, for what it's worth.
Edit: obviously there are lots of people who need to write concurrent network server clusters, but I'd argue that the benefits of the Erlang approach are difficult to grasp before you've actually deployed something written in Erlang; simple toy projects (which are a prerequisite to learning a language) don't usually play to its strengths. A language that's really good at web apps is going to grow more quickly simply because its advantages are easier to appreciate from the start.
that's exactly what was my thinking also.
I've tried using Erlang once or twice. I inherited an open source project written in it, wanted to maintain it a bit but I couldn't make head nor tail of it, and I'm a good programmer (but very busy with other things). There were too many things to learn to get started working with the Erlang ecosystem and I didn't really have the time.
I didn't find any good tools.
The error messages were obtuse.
I didn't understand how simple shit like configuration files worked. I couldn't find any place where the file was 'opened' from code. I chalked it up to the magic of the underlying framework or whatever.
I didn't find any good tools.
The error messages were obtuse.
I didn't understand how simple shit like configuration files worked. I couldn't find any place where the file was 'opened' from code. I chalked it up to the magic of the underlying framework or whatever.
Are you a good programmer in imperative languages only by any chance?
No - I've done a number of FP projects, but certainly spent less time with it than imperative languages. Here are some FP projects I've done --
* Compiler for a scheme-like language in Haskell
* simple webapp in Haskell using Yesod
* small 2d game in Clojure
* racket-based little language that compiles to openscad
* lots of academic programming-languages projects in Racket
(garbage collector, type checker, prolog, etc)I tried it for approximately 6 months (a few years ago). I translated some slow python into fairly idiomatic (IMHO) erlang and got some pretty significant speedups. I had vary little functional programming experience before that, so my comments here come with that caveat.
My hangups:
- lack of easy-to-use string libraries. far and away the biggest pain point. working in bioinformatics, I deal with a lot of poorly-formatted text.
- installing erlang itself was fine, but installing (and finding) any other packages was a PITA.
- documentation could have been better. I can't remember what specifically I disliked but remember being frustrated trying to find info about builtin nuances.
- syntax. this one seems silly from the outside, but the whole commas-here-but-definitely-not-there and other idiosyncracies really made tweaking code and debugging a pain. Go has similar pains around the "unused variable" errors so I know this type of thing isn't particular to erlang.
My hangups:
- lack of easy-to-use string libraries. far and away the biggest pain point. working in bioinformatics, I deal with a lot of poorly-formatted text.
- installing erlang itself was fine, but installing (and finding) any other packages was a PITA.
- documentation could have been better. I can't remember what specifically I disliked but remember being frustrated trying to find info about builtin nuances.
- syntax. this one seems silly from the outside, but the whole commas-here-but-definitely-not-there and other idiosyncracies really made tweaking code and debugging a pain. Go has similar pains around the "unused variable" errors so I know this type of thing isn't particular to erlang.
Popularity is probably the worst metric for a programming language. Programmers conflate popular for good pretty often. They line up often, but they are orthogonal. The original question is loaded. Why not ask "What usually increases a language's popularity? How can these effects be applied to Erlang?"
Now the answers are a bit more useful, a bit more constructive:
* write more, better docs (Erlang for Java programmers, .. for JS devs, .. Ruby, etc)
* polish the websites, improve search rankings for helpful links (the standard library, etc)
* write at least one good O'Reilly book
* write lots of libraries, especially web frameworks
* integrate seamlessly with other platforms (possible with Clojure, maybe not Erlang)
* upload screencasts "15 Minutes in Erlang", etc
* ...use your imagination
Lisp is another prototypical "our language is awesome, why is it dying?". FreeBSD used to get joked on, too. Well la-dee-da, Erlang on FreeBSD can be a winning combination! These technologies will remain good, but they won't magically make themselves popular. It's not if-you-build-it-they-will-come anymore. There are too many programming languages to get acquainted with even 20% of them. Languages need to be more competitive to be more popular.
Now the answers are a bit more useful, a bit more constructive:
* write more, better docs (Erlang for Java programmers, .. for JS devs, .. Ruby, etc)
* polish the websites, improve search rankings for helpful links (the standard library, etc)
* write at least one good O'Reilly book
* write lots of libraries, especially web frameworks
* integrate seamlessly with other platforms (possible with Clojure, maybe not Erlang)
* upload screencasts "15 Minutes in Erlang", etc
* ...use your imagination
Lisp is another prototypical "our language is awesome, why is it dying?". FreeBSD used to get joked on, too. Well la-dee-da, Erlang on FreeBSD can be a winning combination! These technologies will remain good, but they won't magically make themselves popular. It's not if-you-build-it-they-will-come anymore. There are too many programming languages to get acquainted with even 20% of them. Languages need to be more competitive to be more popular.
Marty DeBergi: I was just wondering, does this mean uh...the popularity of the group is waning?
Ian Faith: Oh, no, no, no, no, no, not at all. I just think that their appeal is becoming more selective.
Ian Faith: Oh, no, no, no, no, no, not at all. I just think that their appeal is becoming more selective.
I wrote the question and I agree that popularity isn't a good metric (on its own). But it is a valid metric, in the round. Making a language more popular has to start with people who don't use it though, so no apologies for being a bit populist in my phrasing...
You are right: it is a valid metric.
It's the quality of the language that counts, but it's the popularity that matters.
It's the quality of the language that counts, but it's the popularity that matters.
Fun fact: I did a co-op at Ericsson in second year. I asked my interviewer (later boss) if they used Erlang at all, and she'd never heard of it. Some of the hackers in the company had a limited degree of familiarity with it, but none of the PMs/managers seemed to know what it was.
If you search for Erlang on their jobs page you get 17 results, most which are in China and India. In comparison Java gets 183 results.
http://jobs.ericsson.com/search/?q=erlang
http://jobs.ericsson.com/search/?q=java
http://jobs.ericsson.com/search/?q=erlang
http://jobs.ericsson.com/search/?q=java
It was even banned internally for a couple of years and Armstrong left Ericsson as a result.
I know it gets some use within Ericsson for running quickcheck tests against C-code.
I know it gets some use within Ericsson for running quickcheck tests against C-code.
Something Erlang fans rarely mention: only one generation of equipment used the OTP.
In other words, it was stillborn.
In other words, it was stillborn.
Not exactly true. As I know, it is used in all sorts of mobile network equipment, including LTE nodes.
I think the majority of programmers are very conservative about language, they use whatever they already know, be it Java, C#, C++, ruby, etc.
A minority are more fashion-driven - if something seems like the hot new trend they'll jump on it, scoffing at the old-fashioned crap their coworkers are using. Erlang unfortunately is not fashionable, and it's hard to predict or control fashion.
A smaller minority are driven by some concept of technical merit. However, once you've strayed from the safety of Java/C#/etc., it seems like you might as well go all the way and get into Haskell, which is pretty widely seen as the most advanced, mind-expanding, powerful, futuristic programming language right now, and for good reason.
A minority are more fashion-driven - if something seems like the hot new trend they'll jump on it, scoffing at the old-fashioned crap their coworkers are using. Erlang unfortunately is not fashionable, and it's hard to predict or control fashion.
A smaller minority are driven by some concept of technical merit. However, once you've strayed from the safety of Java/C#/etc., it seems like you might as well go all the way and get into Haskell, which is pretty widely seen as the most advanced, mind-expanding, powerful, futuristic programming language right now, and for good reason.
"once you've strayed from the safety of Java/C#/etc., it seems like you might as well go all the way and get into Haskell"
This is exactly what has led me to Haskell. I was doing Python but got interested in Go for Channels and Static Typing. It turned out Go's static typing was a little to weak for me, so it's unsurprising that I came across Haskell shortly thereafter.
This is exactly what has led me to Haskell. I was doing Python but got interested in Go for Channels and Static Typing. It turned out Go's static typing was a little to weak for me, so it's unsurprising that I came across Haskell shortly thereafter.
Pierre Fenoll has provided a link to an extensive list of links (and summarised them) about why it has not taken off:
https://github.com/fenollp/kju/blob/master/criticisms.md
If you skip the syntax part and the "query" pet peevy, it is as if he was reading my mind! Spot on
The string part specially... will have to check out his binary string code.
The string part specially... will have to check out his binary string code.
I haven't used or looked at Erlang, but bear with me.
* no package manager
This is _huge_. For example: I currently work very heavily with node.js. I understand all of the many, many problems with javascript. NPM single-handedly makes up for all of them put together, in my eyes.
Which is to say - an amazing package manager can make a poor language. A decent package manager (pip, for example) allows a nice language to shine, but won't make or break it. Lack of a package manager could probably kill just about any new languages these days (and Erlang - correct me if I'm wrong - appears to have the popularity of a pretty early-stage language right now).
* no package manager
This is _huge_. For example: I currently work very heavily with node.js. I understand all of the many, many problems with javascript. NPM single-handedly makes up for all of them put together, in my eyes.
Which is to say - an amazing package manager can make a poor language. A decent package manager (pip, for example) allows a nice language to shine, but won't make or break it. Lack of a package manager could probably kill just about any new languages these days (and Erlang - correct me if I'm wrong - appears to have the popularity of a pretty early-stage language right now).
This is a really good point. There's an attempt to tackle this with Elixir: http://expm.co/
This. I work at a big Erlang shop and the "dependency handling" is either git submodules or rebar which is glorified submodules. I think this is due to packaging not being sexy enough to work on, much more fun to think about the internals of the Erlang VM.
And old language that looks like a young one... hmm, interesting...
It's just not suited for what I do. At work, I do number crunching. Essentially a bunch of simple calculations in a for loop. C++ is excellent for this. I use a lot of Python for rapid prototyping, and as glue code. When I need to do concurrency, it's usually the easiest thing to run multiple instances in parallel, or to submit jobs to a cluster. There is already a well-tested infrastructure in place, and I don't need all the fancy stuff erlang has in this area.
Second, but more important, my colleagues know C++ (good enough at least). If I started to use something else, we couldn't collaborate. We're physicists, not computer scientists or professional programmers.
Then, I often find myself writing GUI code. I wouldn't know how to start writing a GUI in Erlang, but it's trivial in Python or C++.
If anything, I would need a language centered around mutability, so almost the opposite of erlang. A language where everything is mutable, where you can databind to any object. Where you can just make an array of objects and bind it to a graphical widget, and get create, edit, update, delete operations for free. You never have to write `listview.insert(...)`. Maybe the command pattern is part of the language and it is trivial to write an undo function. And finally, it would include multithreading, with only a simple syncronization primitive, the transaction. The goal of concurrency here would not be speed, but GUI responsiveness.
So, I have two very different use cases, for one I can use C++, for the other the ideal language has not been invented (but C# and Python are both not bad). I just don't know what to do with Erlang (and Haskell, Clojure, and all the other hip languages).
Second, but more important, my colleagues know C++ (good enough at least). If I started to use something else, we couldn't collaborate. We're physicists, not computer scientists or professional programmers.
Then, I often find myself writing GUI code. I wouldn't know how to start writing a GUI in Erlang, but it's trivial in Python or C++.
If anything, I would need a language centered around mutability, so almost the opposite of erlang. A language where everything is mutable, where you can databind to any object. Where you can just make an array of objects and bind it to a graphical widget, and get create, edit, update, delete operations for free. You never have to write `listview.insert(...)`. Maybe the command pattern is part of the language and it is trivial to write an undo function. And finally, it would include multithreading, with only a simple syncronization primitive, the transaction. The goal of concurrency here would not be speed, but GUI responsiveness.
So, I have two very different use cases, for one I can use C++, for the other the ideal language has not been invented (but C# and Python are both not bad). I just don't know what to do with Erlang (and Haskell, Clojure, and all the other hip languages).
Mathematica is expensive and several kinds of weird (it gets better once you figure out that it's trying to camouflage the fact that it's a Lisp), but especially the newer version seem to have very nice visualization tools as well as a large collection of mathematical-ish functions.
(It's not "C++ fast", of course.)
(It's not "C++ fast", of course.)
I've posted these before[1]:
* No public bug tracker
* epmd's security (or lack thereof)
* Can't insist that epmd be started separately (`erl -no_epmd` won't start epmd but it also won't start epmd's gen_server)
* Can't swap out epmd because while `erl -epmd_module foo` is there, `net_kernel:epmd_module()` is barely used. (Although I don't think its interface is documented anyway)
* No built-in way to hook UNIX signals
* While the documentation itself is pretty good, it's presentation is lacking and it's difficult to quickly correct mistakes as you run into them
* It can be difficult to reason about when a shared binary will be garbage collected
* OS packaging (I'm thinking of Debian/Ubuntu) of Erlang and Erlang apps tends to be more harmful than helpful (old packages, namespace conflicts, etc)
To them I'd add:
* No agreed upon build tool (rebar while prevalent isn't universally accepted)
* Community libraries often have no support for upgrades or aren't packaged properly for releases
* Can't upgrade SSL if you're using it as a carrier
* No standard code format tool like gofmt (yes I know about erl_tidy, no it doesn't provide the same functionality as gofmt or it'd see similar use)
* Not enough infrastructure around built around edoc; where's the godoc or godoc.org work-a-likes? (yes I know about erldocs.com, it's no godoc.org)
[1] https://news.ycombinator.com/item?id=5801706
* No public bug tracker
* epmd's security (or lack thereof)
* Can't insist that epmd be started separately (`erl -no_epmd` won't start epmd but it also won't start epmd's gen_server)
* Can't swap out epmd because while `erl -epmd_module foo` is there, `net_kernel:epmd_module()` is barely used. (Although I don't think its interface is documented anyway)
* No built-in way to hook UNIX signals
* While the documentation itself is pretty good, it's presentation is lacking and it's difficult to quickly correct mistakes as you run into them
* It can be difficult to reason about when a shared binary will be garbage collected
* OS packaging (I'm thinking of Debian/Ubuntu) of Erlang and Erlang apps tends to be more harmful than helpful (old packages, namespace conflicts, etc)
To them I'd add:
* No agreed upon build tool (rebar while prevalent isn't universally accepted)
* Community libraries often have no support for upgrades or aren't packaged properly for releases
* Can't upgrade SSL if you're using it as a carrier
* No standard code format tool like gofmt (yes I know about erl_tidy, no it doesn't provide the same functionality as gofmt or it'd see similar use)
* Not enough infrastructure around built around edoc; where's the godoc or godoc.org work-a-likes? (yes I know about erldocs.com, it's no godoc.org)
[1] https://news.ycombinator.com/item?id=5801706
Interesting set of comments...
Honestly, I think what kills it is that it's not an Algol-descended language [1]. If Erlang was written with an Algol-esque syntax it would have taken off years ago. But instead it has this weird syntax, which it then doesn't really do that much with. What do I mean by that? Haskell has a radically different syntax, but it does things with that syntax and its pervasive currying to enable a powerful succinctness that one can not imagine being translated back into the Algol-esque framework. Lisp does things with its bizarre syntax, making it obvious how to write correct macros and being homoiconic, which translates poorly back into Algol-esque infix languages. It's almost inconceivable that one could translate a concatenative program back into Algol-esque syntax [2]. But Erlang really doesn't do anything that couldn't be in Algol-esque syntax. (Near existance proof: Go. Yes, there are significant differences, but the two are inter-transliterable to a much greater degree than any pairing of any of the previous sets of language families.)
If it had an Algol syntax, and performed the SSA transform behind the scene, it would probably be very, very big now.
Bear in mind as I say this that I'm not necessarily advocating for those changes. For instance, this would require some tweaks to the semantics of pattern matching, too, which aren't necessarily for the better... in the abstract. However, they probably would be for the better in terms of usage.
I'm pretty sure Go is going to eat Erlang. Erlang programmers will 100% absolutely correctly complain that OTP can't be translated without loss into Go, and almost nobody will care. Again, I'm not necessarily advocating for this, because the Erlang advocates will be right, you just can't quite get it fully expressed in Go and that saddens me, it's just what's going to happen, I think.
In fact I'm doing it myself; the Erlang core of my system is getting pulled out and replaced by Go for a variety of reasons, and one is despite the fact my team is fairly adventurous over all, we're still better off finding people to work on Go than Erlang. (In the next couple of months I hope to release my first release of "reign", "Rewrite Erlang In Go Nicely", which brings some of the Erlang stuff into Go for the purpose of porting existing programs. I've been pulled into other fire fighting so I'm not on it this second, but I'll be getting back to it soon. That implements Erlang-like mailboxes and network clustering, and I've got a supervisor tree implementation on deck for Github too. Subscribe to https://github.com/thejerf to see when those come out in the next couple of months.)
By the way, Erlang advocates, bear in mind that trying to argue me out of this position is a waste of time. I've been programming in Erlang for 7 years now. I get the syntax just fine, even if I still don't like it. The problem is that you have to argue the greater programming community out of this position, and I don't think you have, and I really doubt you can. For better or worse, being non-Algol seems to put a hard limit on your general-purpose programming acceptance. (In my opinion, that is for the worse, but here we are. Again, please don't mistake this opinion as celebration of any of these facts. My opinion is that Erlang deserves better. My belief is that it won't get it.)
[1]: That's pretty much every modern mainstream language today: C(/++/#), Java, Python, Javascript, etc. Not all those languages come from the same semantic heritage (scripting vs. conventional OO manifest types being one big example), but they come from the same syntactic heritage. Contrast with the ML family, the Lisp family, the Prolog family (which is pretty much just Erlang now), and the Forth family for different syntactic heritages.
[2]: http://evincarofautumn.blogspot.com.es/2012/02/why-concatena...
If it had an Algol syntax, and performed the SSA transform behind the scene, it would probably be very, very big now.
Bear in mind as I say this that I'm not necessarily advocating for those changes. For instance, this would require some tweaks to the semantics of pattern matching, too, which aren't necessarily for the better... in the abstract. However, they probably would be for the better in terms of usage.
I'm pretty sure Go is going to eat Erlang. Erlang programmers will 100% absolutely correctly complain that OTP can't be translated without loss into Go, and almost nobody will care. Again, I'm not necessarily advocating for this, because the Erlang advocates will be right, you just can't quite get it fully expressed in Go and that saddens me, it's just what's going to happen, I think.
In fact I'm doing it myself; the Erlang core of my system is getting pulled out and replaced by Go for a variety of reasons, and one is despite the fact my team is fairly adventurous over all, we're still better off finding people to work on Go than Erlang. (In the next couple of months I hope to release my first release of "reign", "Rewrite Erlang In Go Nicely", which brings some of the Erlang stuff into Go for the purpose of porting existing programs. I've been pulled into other fire fighting so I'm not on it this second, but I'll be getting back to it soon. That implements Erlang-like mailboxes and network clustering, and I've got a supervisor tree implementation on deck for Github too. Subscribe to https://github.com/thejerf to see when those come out in the next couple of months.)
By the way, Erlang advocates, bear in mind that trying to argue me out of this position is a waste of time. I've been programming in Erlang for 7 years now. I get the syntax just fine, even if I still don't like it. The problem is that you have to argue the greater programming community out of this position, and I don't think you have, and I really doubt you can. For better or worse, being non-Algol seems to put a hard limit on your general-purpose programming acceptance. (In my opinion, that is for the worse, but here we are. Again, please don't mistake this opinion as celebration of any of these facts. My opinion is that Erlang deserves better. My belief is that it won't get it.)
[1]: That's pretty much every modern mainstream language today: C(/++/#), Java, Python, Javascript, etc. Not all those languages come from the same semantic heritage (scripting vs. conventional OO manifest types being one big example), but they come from the same syntactic heritage. Contrast with the ML family, the Lisp family, the Prolog family (which is pretty much just Erlang now), and the Forth family for different syntactic heritages.
[2]: http://evincarofautumn.blogspot.com.es/2012/02/why-concatena...
The syntax issue is why I think the Elixir programming language[1] has a good chance of improving the ecosystem around the Erlang VM. Although, most Erlang programmers, who i've spoken to, feel the syntax is a non-issue, so it is more likely to convert programmers who are new to, or curious about, Erlang.
It is also worth a note that Elixir adds language features, such as default UTF8 binary strings, real macros, Clojure-style protocols, tooling, etc, on top of the Ruby-style syntax.
[1] http://elixir-lang.org/
It is also worth a note that Elixir adds language features, such as default UTF8 binary strings, real macros, Clojure-style protocols, tooling, etc, on top of the Ruby-style syntax.
[1] http://elixir-lang.org/
[deleted]
I think this is mostly right. Erlang is, roughly, in the Lisp, Forth, Smalltalk bin, not the C, Ruby, Go bin. Its advocates are going to be going on about how "Erlang got that right in 199something" for years, even when things like Go have got most of what it has.
I wrote about Erlang 7 years ago, and a lot of that still holds true, IMO:
http://journal.dedasys.com/2007/09/22/erlang/
That said, I lately helped start a pretty big project in Erlang and have been using it a lot lately. It has improved, and it's a fun language to use in a lot of ways.
I wrote about Erlang 7 years ago, and a lot of that still holds true, IMO:
http://journal.dedasys.com/2007/09/22/erlang/
That said, I lately helped start a pretty big project in Erlang and have been using it a lot lately. It has improved, and it's a fun language to use in a lot of ways.
Err, by his classification, Smalltalk is also in the C, Ruby, Go bin.
He divided by Algol-like syntax and heritage, not by mere popularity.
He divided by Algol-like syntax and heritage, not by mere popularity.
> I'm pretty sure Go is going to eat Erlang.
I wouldn't be surprised by this. Go's concurrency pattern is fantastic, but to match what Erlang does it needs to be easily extended beyond the running process. Can channels connect multiple "nodes" yet? That is, two running go programs, can they communicate via channels or do they have to use some other IPC mechanism? Across a network? That universal communication structure is (IMO) erlang's killer feature.
I wouldn't be surprised by this. Go's concurrency pattern is fantastic, but to match what Erlang does it needs to be easily extended beyond the running process. Can channels connect multiple "nodes" yet? That is, two running go programs, can they communicate via channels or do they have to use some other IPC mechanism? Across a network? That universal communication structure is (IMO) erlang's killer feature.
I do not have direct knowledge, but I'm pretty sure the problem with "network" channels in Go is the synchronous nature of channels. Even if we did have a perfect network, that works poorly across a network, and if the network starts degrading even a bit the sync channels just completely fall apart. The language treats them as a fast synchronization method. You can very nearly translate RPC to "channel" in this argument and it works: https://news.ycombinator.com/item?id=2318249 (Err, I did try to find a better explanation that wasn't mine, but Googling up an RPC criticism was hard, because saying "RPC" comes up with a pretty big search pool to be trying to find the word "bad" in...)
My reign library basically just ports over the Erlang idea; asynch messages, PID-like things that can be transmitted across the network and identify the same mailboxes within a cluster. It's meant to be a porting aid, not a solution you'd reach for in Go to create a brand new program. (If you do that, it's on you.) Clustering like this is nontrivial and the big reason I'm sitting on the code locally until clustering is at least working under some circumstances; without clustering support, the mailboxes are just an invitation to write nonidiomatic code for no gain.
My reign library basically just ports over the Erlang idea; asynch messages, PID-like things that can be transmitted across the network and identify the same mailboxes within a cluster. It's meant to be a porting aid, not a solution you'd reach for in Go to create a brand new program. (If you do that, it's on you.) Clustering like this is nontrivial and the big reason I'm sitting on the code locally until clustering is at least working under some circumstances; without clustering support, the mailboxes are just an invitation to write nonidiomatic code for no gain.
> I wouldn't be surprised by this. Go's concurrency pattern is fantastic
Only for those not versed in java.util.concurrent, TPL, PPL, TBB, Cilk Plus.
Only for those not versed in java.util.concurrent, TPL, PPL, TBB, Cilk Plus.
"Those not versed in Cilk Plus" is a pretty large set
java.util.concurrent doesn't have a convenient mechanism for "selecting" across available channels/queues without blocking. This is a key feature of erlang and go. There are ways to simulate it, but it's not the same thing. (I'd love to be wrong about this).
Yes, you need to peek() the queues, so it is not really being blocked on select like Go.
But then, one can use something like Akka, which I forgot to mention, and still be on the JVM.
But then, one can use something like Akka, which I forgot to mention, and still be on the JVM.
>so it is not really being blocked on select like Go.
Select in Go only blocks if you don't feel out the "default:" case...
Select in Go only blocks if you don't feel out the "default:" case...
select {
case: foo := <-fooCh
fmt.Printf("got %v\n", foo)
default:
fmt.Println("got nothing")
}Erlang scheduler time share each processes. So if you have an infinite forloop, it while stop for several ms for other processes to run.
Preemptive scheduler, I doubt Go have this, then again Go doesn't have a VM/OS system.
Preemptive scheduler, I doubt Go have this, then again Go doesn't have a VM/OS system.
go 1.2 has preemptive scheduling http://golang.org/doc/go1.2#preemption
In fairness, it's worth pointing out that Go 1.2 has partial preemption. Preemption is still checked only on function entry. However, unlike something like Node, this is not built in the language semantics, it's a characteristic of the runtime, and I imagine over time this will be fixed.
>Preemption is still checked only on function entry.
And I believe also heap allocation... the two cases together make what is still "partial preemption" pretty damn effective.
And I believe also heap allocation... the two cases together make what is still "partial preemption" pretty damn effective.
Not knowing enough about Erlang/OTP or Go: Would it be possible for more of OTP to be replicated in a Go 2.0? What's missing? What would it take? What can never be replicated?
You can recover a substantial portion, but there's a few things you can't quite get back. Since Go is a mutable-state language, and also a shared-state language (isolation is by convention, not by language design), you have to live with the consequences of that. In my supervisor tree implementation, the restart of a monitored goroutine is just to fire off a new goroutine on the exact same object again; if you still have bad state lying around and immediately crash again, well, too bad, the supervisor can't do anything about that. (Except not thrash the processor with endless restarts.) In contrast, when an Erlang supervisor restarts a process, it is guaranteed to be a fresh process with no shared state from the one that just crashed. It's much more likely to not immediately crash.
(I fiddled with having the user specify a closure that is supposed to "create" a new object for the restart, but then simplified that away when I realized that the closure itself could well have mutable state too. Better just to stick with the simpler interface and document the consequences of failing to clean out state at the beginning of your monitored code. On the plus side, so far the interface for the supervised-things is "Serve()" and "Stop()", and nothing else; hard to argue with that level of simplicity!)
You also won't ever be able to recover live code restarts; you can try to transfer all state to a new process, including file handles, but that's a lot of implementation work. (I'm stuck right now on the fact that my connections are encrypted, and the encryption code won't let me even get to the state, let alone transfer and reconstitute it somewhere else. Someone's got some code for moving file handles around on GitHub but I can't seem to Google it up.) Most people already live in a world where live restarts are difficult or impossible, though, so they won't miss that. Getting a REPL into a live Go server is impossible, at least with Go itself, and will also probably never be as clean as Erlang. (Go "2.0" could fix that with an official Go interpreter, which is the missing bit. I can handle the sockets, I can bind readline and give you a nicer REPL, but interpreting Go is a challenge. Progress is being made, I believe as part of the new compiler implementation, but I'm not sure anyone has this as an explicit goal.) Again, most people live in a world where they already don't have a REPL into their running code, and therefore won't miss this.
There's also some more subtle semantic differences, but I'm saving that for a blog post. (It gets long, especially if I first have to explain Erlang, which is what the blog post does.)
(I fiddled with having the user specify a closure that is supposed to "create" a new object for the restart, but then simplified that away when I realized that the closure itself could well have mutable state too. Better just to stick with the simpler interface and document the consequences of failing to clean out state at the beginning of your monitored code. On the plus side, so far the interface for the supervised-things is "Serve()" and "Stop()", and nothing else; hard to argue with that level of simplicity!)
You also won't ever be able to recover live code restarts; you can try to transfer all state to a new process, including file handles, but that's a lot of implementation work. (I'm stuck right now on the fact that my connections are encrypted, and the encryption code won't let me even get to the state, let alone transfer and reconstitute it somewhere else. Someone's got some code for moving file handles around on GitHub but I can't seem to Google it up.) Most people already live in a world where live restarts are difficult or impossible, though, so they won't miss that. Getting a REPL into a live Go server is impossible, at least with Go itself, and will also probably never be as clean as Erlang. (Go "2.0" could fix that with an official Go interpreter, which is the missing bit. I can handle the sockets, I can bind readline and give you a nicer REPL, but interpreting Go is a challenge. Progress is being made, I believe as part of the new compiler implementation, but I'm not sure anyone has this as an explicit goal.) Again, most people live in a world where they already don't have a REPL into their running code, and therefore won't miss this.
There's also some more subtle semantic differences, but I'm saving that for a blog post. (It gets long, especially if I first have to explain Erlang, which is what the blog post does.)
I'd have to say your idea of supervisors misses the point.
Supervised processes provide guarantees in their initialization phase, not a best effort. This means that they are always restarted to a known stable state. It's not just a question of retrying, it's a question of returning to a piece of data and environment that is reliable. I wrote on this more in details at http://ferd.ca/it-s-about-the-guarantees.html
If you reuse the same exact object again that can be modified, you lose these guarantees entirely, and it becomes a question of convention and attention to detail rather than something provided for you.
The REPL is a vital part of my every day Erlang experience. I can't imagine living without one when things get tricky in production and that pre-built tools aren't enough. Being able to poke around and inspect everything while it runs is great.
Supervised processes provide guarantees in their initialization phase, not a best effort. This means that they are always restarted to a known stable state. It's not just a question of retrying, it's a question of returning to a piece of data and environment that is reliable. I wrote on this more in details at http://ferd.ca/it-s-about-the-guarantees.html
If you reuse the same exact object again that can be modified, you lose these guarantees entirely, and it becomes a question of convention and attention to detail rather than something provided for you.
The REPL is a vital part of my every day Erlang experience. I can't imagine living without one when things get tricky in production and that pre-built tools aren't enough. Being able to poke around and inspect everything while it runs is great.
"I'd have to say your idea of supervisors misses the point."
I think it's unfair to explain how I "missed the point" to me when I'm the one who brought it to your attention in the first place, when I called it out explicitly as a weakness, in the context of a post explaining how OTP can not be completely ported into Go without loss. I did after all explain in a parenthetical that I tried to fix it, realized the fix wasn't really a fix, and decided just to go simple and idiomatic after that.
The thing is, while it is sad that we lose that characteristic of supervisors, there are still other useful characteristics: Sensible restarts; naive restart code has a lot of pathological cases. I rather expect my library to ship with a couple at first too, but we (yay open source) can fix it in one place, once. Composition of supervisors is a great way to build applications, with self-contained pieces; the whole "hierarchy" still applies, though I find with the elimination of the restart strategies it gets a lot simpler, for better and for worse. It's still nice to be able to build code and easily slot it into a management system, even if it can't quite be as powerful.
A complete translation is impossible, but an idiomatic one may be, and I'm already finding it useful even in my little coding efforts.
As for the REPL... yes, that is an unmitigated loss, no question. I'm mitigating it in my personal app with a lot more flexible logging and some more external controls, but there is no true replacement for a REPL. Though... we may get a REPL someday, it just may be either a mere subdialect of Go or a separate scripting language. I've resisted putting a dependency on one of the very young Go scripting languages in my project, but theoretically in another year or two this might at least be mitigated.
I think it's unfair to explain how I "missed the point" to me when I'm the one who brought it to your attention in the first place, when I called it out explicitly as a weakness, in the context of a post explaining how OTP can not be completely ported into Go without loss. I did after all explain in a parenthetical that I tried to fix it, realized the fix wasn't really a fix, and decided just to go simple and idiomatic after that.
The thing is, while it is sad that we lose that characteristic of supervisors, there are still other useful characteristics: Sensible restarts; naive restart code has a lot of pathological cases. I rather expect my library to ship with a couple at first too, but we (yay open source) can fix it in one place, once. Composition of supervisors is a great way to build applications, with self-contained pieces; the whole "hierarchy" still applies, though I find with the elimination of the restart strategies it gets a lot simpler, for better and for worse. It's still nice to be able to build code and easily slot it into a management system, even if it can't quite be as powerful.
A complete translation is impossible, but an idiomatic one may be, and I'm already finding it useful even in my little coding efforts.
As for the REPL... yes, that is an unmitigated loss, no question. I'm mitigating it in my personal app with a lot more flexible logging and some more external controls, but there is no true replacement for a REPL. Though... we may get a REPL someday, it just may be either a mere subdialect of Go or a separate scripting language. I've resisted putting a dependency on one of the very young Go scripting languages in my project, but theoretically in another year or two this might at least be mitigated.
Fair enough.
It is funny to me that Erlang combines unique tools for application stability with the ability to edit stuff online in production. I'm not saying I never launch a production Rails console, but seeing that in Erlang is a weird juxtaposition. I'd love to understand better how those fit together comfortably in an Erlanger's world view.
In practice, one will have to refrain from some of the crazier stuff when working interactively in the shell of a production system. However, it's extremely useful for debugging and minor adjustments by a skilled engineer. Things you can do include inspection of data structures, (very) careful tracing, loading of instrumented modules or minor corrections.
Since Erlang is dynamically typed, practically all data structures can be inspected at run-time, and one particularly nice thing about the Erlang shell is that it tends to be responsive even when the system is operating at near-maximum load.
Since Erlang is dynamically typed, practically all data structures can be inspected at run-time, and one particularly nice thing about the Erlang shell is that it tends to be responsive even when the system is operating at near-maximum load.
>Someone's got some code for moving file handles around on GitHub but I can't seem to Google it up:
https://github.com/sharvil/flingfd
https://github.com/sharvil/flingfd
really looking forward to that blog post. I clicked to your github profile in your other comment upthread, but realized I was already following you there after seeing gomempool. :)
Besides the issues that jerf mentioned, Erlang also has per-process garbage collection built right into the VM. Last time I checked Go's garbage collection was still stop-the-world, mark-and-sweep, making it less suitable for soft real-time systems than Erlang.
"Go 2.0" probably can't ever quite fix that, but there's some potential for improvement; one can imagine as an optimization the compiler being able to determine a particular goroutine really is isolated (no shared state with anything else at start time, communicates only via channels that are full copiers of state, etc.) and independently GC's them, and also excludes them from the "stop" in the "stop the world". But yes, it is stop-the-world, and I'm keeping a close eye on the GC performance in the app I'm transitioning. (So far the numbers are working out OK, but it's definitely in the range I have to watch out.)
Yeah I don't doubt there are some smart people out there that could make something like that happen (look at Azul and their pauseless GC for the JVM for example). However, it will be a tough fix when compared to the simple/pure approach Erlang takes.
For the life of me, I cannot understand why Oracle hasn't bought Azul and made it available to all, for free.
Azul only works well on multi-processor machines with LOTS of RAM, but when it does, it beats everything else out there by a mile. You'd think Oracle would want that.
Azul only works well on multi-processor machines with LOTS of RAM, but when it does, it beats everything else out there by a mile. You'd think Oracle would want that.
[deleted]
The Go situation is changing:
runtime: concurrent GC sweep Moves sweep phase out of stoptheworld by adding background sweeper goroutine and lazy on-demand sweeping.
https://codereview.appspot.com/46430043/
runtime: concurrent GC sweep Moves sweep phase out of stoptheworld by adding background sweeper goroutine and lazy on-demand sweeping.
https://codereview.appspot.com/46430043/
I'm looking forward to see how reign turns out!
Like Clojure, I like that Erlang has lots of interesting ideas. I may never use either in production, but Erlang's OTP sounds very interesting as a way to handle real-world scenarios like failure handling. Similarly, Clojure's datomic, core async, etc. are interesting ideas, implemented by people with good taste.
However, too many examples show trivial things like mapping over a list or calculating something recursively. As a professional programmer, I get how those things wrok. What sets these languages apart from Javas of the world is how state is handled. It isn't easy to dig through tutorials and docs to find the best way of keeping state, updating it, referencing it, etc.
I once attempted to implement a small order matcher (from the stock trading world) in Erlang. I know how to do it in imperative languages, but it was pretty painful to do so in Erlang. It was getting very verbose, I wasn't sure how to create a priority queue, how to modify elements in a data structure, etc. Since this wasn't a simple transformation of data, I had a hard time finding references in documentation spread across the web.
I realize that if I was committed to learning Erlang, I would work through a book or two. Perhaps find a small open source project and work through the implementation. However, I, like so many others, wasn't committed. I was merely trying it out and when I couldn't make progress, I decided to use my precious free time on something else.
However, too many examples show trivial things like mapping over a list or calculating something recursively. As a professional programmer, I get how those things wrok. What sets these languages apart from Javas of the world is how state is handled. It isn't easy to dig through tutorials and docs to find the best way of keeping state, updating it, referencing it, etc.
I once attempted to implement a small order matcher (from the stock trading world) in Erlang. I know how to do it in imperative languages, but it was pretty painful to do so in Erlang. It was getting very verbose, I wasn't sure how to create a priority queue, how to modify elements in a data structure, etc. Since this wasn't a simple transformation of data, I had a hard time finding references in documentation spread across the web.
I realize that if I was committed to learning Erlang, I would work through a book or two. Perhaps find a small open source project and work through the implementation. However, I, like so many others, wasn't committed. I was merely trying it out and when I couldn't make progress, I decided to use my precious free time on something else.
I spent a total of about 11 months (spread over a few years) consulting on a betting exchange in erlang. It was pretty painful even with lots of erlang experience.
I sat down one week and prototyped a rewrite of the core exchange in clojure. 40x better throughput and 10x better latency despite using only two threads, naive `pr-str` serialisation and storing all the exchange state in one huge immutable data structure (for easy rollback on errors). Much easier to debug and to wire up different setups without modifying code (eg swapping out the network layer without touching the io and batching code).
There are some interesting ideas in erlang but they are hidden behind an inexpressive language and poor libraries. I would think more than twice before taking on another large erlang project.
I sat down one week and prototyped a rewrite of the core exchange in clojure. 40x better throughput and 10x better latency despite using only two threads, naive `pr-str` serialisation and storing all the exchange state in one huge immutable data structure (for easy rollback on errors). Much easier to debug and to wire up different setups without modifying code (eg swapping out the network layer without touching the io and batching code).
There are some interesting ideas in erlang but they are hidden behind an inexpressive language and poor libraries. I would think more than twice before taking on another large erlang project.
As non-mainstream languages go, in the financial industry, Scala is picking up steam. However, clojure is at the top of my list as the language I want to learn, despite obstacles of limited time. Lisp has an impressive pedigree and Rich Hickey is a smart, pragmatic dude who seems to have spent a great deal of time thinking about reducing complexity in real-world software engineering.
I think that's the real strength of clojure - not the language itself but that the community around it is focused on radically reducing complexity.
Every project I have ever worked on that struggled or failed did so because the complexity outgrew the developers ability to manage it. It kind of scares me that scala is growing so quickly - from my experience working on a large scala project it seems to breed complexity like nothing else I've ever worked with (haskell, python, ocaml, erlang, clojure).
Every project I have ever worked on that struggled or failed did so because the complexity outgrew the developers ability to manage it. It kind of scares me that scala is growing so quickly - from my experience working on a large scala project it seems to breed complexity like nothing else I've ever worked with (haskell, python, ocaml, erlang, clojure).
I have tried it and (try to) use it when appropriate. I am fairly comfortable with it and my only disappointment is that I do not get to use it often.
The ability to solve a problem in a particular programming language is often dependent on the ability to express the problem in the constructs provided by the language. A very good example is the problem of concurrency. Doing something concurrently in a primarily procedural/OOP language often seems hacky and it is something that does not feel natural. The actor model that erlang implements is a very powerful model for certain class of problems and concurrency is one of them. Erlang the language, minus the OTP, is extremely small and once you get over the culture shock experienced when it comes to syntax, things will seem pretty easy. OTP isn't magic. Its years and years of erlang experience packaged into one neat library, solving commons problems, so that you can concentrate on your work instead of reinventing the wheel.
Reading Joe Armstrong thesis 'Making reliable distributed systems in the presence of software errors'[1] is highly recommended if you want to understand why things are the way they are.
[1] : http://www.erlang.org/download/armstrong_thesis_2003.pdf
The ability to solve a problem in a particular programming language is often dependent on the ability to express the problem in the constructs provided by the language. A very good example is the problem of concurrency. Doing something concurrently in a primarily procedural/OOP language often seems hacky and it is something that does not feel natural. The actor model that erlang implements is a very powerful model for certain class of problems and concurrency is one of them. Erlang the language, minus the OTP, is extremely small and once you get over the culture shock experienced when it comes to syntax, things will seem pretty easy. OTP isn't magic. Its years and years of erlang experience packaged into one neat library, solving commons problems, so that you can concentrate on your work instead of reinventing the wheel.
Reading Joe Armstrong thesis 'Making reliable distributed systems in the presence of software errors'[1] is highly recommended if you want to understand why things are the way they are.
[1] : http://www.erlang.org/download/armstrong_thesis_2003.pdf
In my opinion, there are three main issues:
1) The Language actually is not general purposes. Or at least it is not promoted this way. If you really need Actor based model and lightweight threads, you can choose Scala/Akka, that is also well suitable for a wide range of different objectives.
2) Standard library(I mean OTP) is simply ugly.
3) Language's syntax is ugly too. Pascal again? No, thanks. :) I know there is Elixir that fixes most of the issues, but too few people know about it outside of the Erlang community. When someone mention Erlang he/she probably thinks about "vanilla" Erlang, which is ugly again.
P.S. I had been using Erlang for a while and then stopped.
1) The Language actually is not general purposes. Or at least it is not promoted this way. If you really need Actor based model and lightweight threads, you can choose Scala/Akka, that is also well suitable for a wide range of different objectives.
2) Standard library(I mean OTP) is simply ugly.
3) Language's syntax is ugly too. Pascal again? No, thanks. :) I know there is Elixir that fixes most of the issues, but too few people know about it outside of the Erlang community. When someone mention Erlang he/she probably thinks about "vanilla" Erlang, which is ugly again.
P.S. I had been using Erlang for a while and then stopped.
Learning Erlang has been on my todo list for years now. I know Java because I was exposed to it in school and had to use if for work. I know Perl because I've had to use it for work. I know C because I've had to know it for projects and some work. I know javascript because I have to. I know Common Lisp and Clojure, because I want to.
Erlang belongs in this category of languages that have really cool features but which almost nobody has to learn to do a certain job. Nearly everything you can do with Erlang you can do with something else and there are a lot of languages that are necessary for one purpose or another and can't be replaced with Erlang. This is usually because said language is so entrenched in a space that it doesn't make sense to use anything else.
The end result is that programmers only have so much time and only so many projects that they can reasonably devote to their 'fun' language and there are a lot of those from which to choose. Erlang isn't competing with Java, it's competing with Lisp, Smalltalk, Factor, Haskell, OCaml, etc. That's a long list of competition.
Erlang belongs in this category of languages that have really cool features but which almost nobody has to learn to do a certain job. Nearly everything you can do with Erlang you can do with something else and there are a lot of languages that are necessary for one purpose or another and can't be replaced with Erlang. This is usually because said language is so entrenched in a space that it doesn't make sense to use anything else.
The end result is that programmers only have so much time and only so many projects that they can reasonably devote to their 'fun' language and there are a lot of those from which to choose. Erlang isn't competing with Java, it's competing with Lisp, Smalltalk, Factor, Haskell, OCaml, etc. That's a long list of competition.
Before finding Clojure I dabbled in Erlang. In the end I found the "share nothing" model to be too limiting. Sure its great for highly fault-tolerant systems. But the fact is I just don't need that most of the time. It's just easier to setup a AWS autoscaling cluster of web servers running Clojure and be done with it.
Oh yeah, and Clojure beats the pants off Erlang when it comes to performance. Even Erjang is faster than stock Erlang.
Oh yeah, and Clojure beats the pants off Erlang when it comes to performance. Even Erjang is faster than stock Erlang.
> Clojure beats the pants off Erlang when it comes to performance
Source?
Source?
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
But I actually meant in general. Having real strings and good floating point support helps performance quite a bit.
But I actually meant in general. Having real strings and good floating point support helps performance quite a bit.
I really think moaning about the syntax is a bit pathetic. It's not what most programmers are used to, sure, but it's hardly Malbolge, is it? If Erlang/OTP is a good fit for your problem, use it. Learn the syntax. It's really not that hard.
I am not going to enter into a syntax argument I have already given my views on that here http://rvirding.blogspot.se/2014/01/erlang-syntax-again-and-... . My main point is that the syntax is simple and that it fits the semantics much better than anything based on an Algol like syntax would, even one which uses ';' in the "normal" way.
And one reason it works is because it has built-in those features for building fault-tolerant systems which, for example, Go lacks. Borrowing from NASA "Failure is not an option".
And one reason it works is because it has built-in those features for building fault-tolerant systems which, for example, Go lacks. Borrowing from NASA "Failure is not an option".
> And one reason it works is because it has built-in those features for building fault-tolerant systems which, for example, Go lacks.
Very few people really need that though, so from a marketing point of view, to sell that as the primary feature is to consign Erlang to a fairly small niche.
Very few people really need that though, so from a marketing point of view, to sell that as the primary feature is to consign Erlang to a fairly small niche.
Actually if you really start asking a lot of people do actually want this but it is often something they don't explicitly mention. It tends to be one of those "of course it must ..." things.
I think it's a question of what kind of people you come into contact with. I'm from the 'web' world, and for many web sites, the whole fault tolerance thing is not that important in the grand scheme of things. Look at Twitter, for instance. Despite starting with Rails, which is really not the right technology for the kind of system they have, they managed to kind of stumble along until they got more appropriate systems in place. And most web sites have nowhere near that need to scale or be always available.
I think that in an area like telecoms, it's of course more likely that people care about that a lot more.
I think that in an area like telecoms, it's of course more likely that people care about that a lot more.
We've developed and run a rather large erlang cluster (> 100k simultaneous users) for several years. It's pretty clear that OTP is not ready for that scale -- most of our big bugs have been in the libraries and OTP, not in our code. Couple that with the poor type safety at compile time, and a "in place update" model that doesn't actually work for "many times a day" continuous deployment, and I feel it's not lived up to the hype.
We also run PHP, C++ and Haskell stacks, each of which has had less environment-based problems.
Compared to other languages, Erlang has a huge learning gap between "playing around in the REPL" and "deploying an application". There's a much larger base of knowledge needed to deploy Erlang apps, than an equivalent app in another language such as Python or Java.
To me it sounds like Erlang's biggest departure from the mainstream is http://c2.com/cgi/wiki?LetItCrash, casually letting processes die and be recreated. When I put effort into actually using a niche language (as opposed to merely learning it for fun) I expect it to enable me to write software that's less embarrassingly defective than everyone else's, where Erlang only seeks to reduce the pain from my doing bad work.
That doesn't mean you shouldn't handle errors if you can. However, there are always more errors and coding bugs left than what you think. Systems with 0 bugs just doesn't exist in the real world. So if you are writing a critical system that is supposed to run 24/7 and your code encounters a "one in a million" bug that got through testing, such that a obscure race condition or something, then to handle it the best strategy is to reset the involved processes and try again.
It's Erlang's answer to the question "What if there is a bug in the system?" Most languages doesn't answer it ("just dont write buggy code!") but Erlang does and tries to come up with a reasonable solution.
It's Erlang's answer to the question "What if there is a bug in the system?" Most languages doesn't answer it ("just dont write buggy code!") but Erlang does and tries to come up with a reasonable solution.
Let it crash isn't about having the program crash, it's about the processes. It's a vocabulary issue for a lot of people, however. In erlang your program consists of multiple concurrent processes (well, that's the intention at least). When an individual process fails (say it's a parser and has been given bad input), the erlang way is to fail and let the supervisor/spawner figure out the corrective action. It's the same question we face when writing in java/c#/etc languages with exception handling. Where do I catch the exception?
A search example. You have several search algorithms given your input. Run all in parallel, if they crash it's fine. If all crash then the search was a bust, but if one succeeds you terminate the remainder and have your answer.
A search example. You have several search algorithms given your input. Run all in parallel, if they crash it's fine. If all crash then the search was a bust, but if one succeeds you terminate the remainder and have your answer.
I fall under the "tried it & stopped" category.
I stumbled upon Erlang in 2011, and did the full "Learn You Some Erlang for Great Good!" tutorial and about 1/2 of the Erlang Programming book (and exercises). Where I ended up is that I had no real-world use cases that would benefit from Erlang, so I just kind of atrophied with it. It seems to me like Erlang is really really good at building programs that can be modeled with message passing (like chat), but a lot of problems are difficult to map to that paradigm (or perhaps my mind just has trouble envisioning how to do it yet). The closest I got was starting to use it to write a distributed Web crawler, but I ended up using scrapy (a Python framework) because the string manipulation was annoying with Erlang, and scrapy already had a lot of features that I would have had to re-implement on my own. But as I'm starting to try and manage crawler distribution with Celery and RabbitMQ, I find myself starting to think more and more about how Erlang would probably do this bit in particular better, so I might return to it.
The language that I've since discovered I really want for most tasks is Haskell. I've been programming Ruby full-time for the last few years, and I've grown really jaded with it. I get sick of having to write so many unit tests around everything in what I see as a poor fix for its loosy-goosyness. I'm still pretty early on in learning Haskell, but I find the approach towards correctness first to be exactly what I want, and while so far some of the material is pretty challenging I can see it will be very rewarding as well.
I stumbled upon Erlang in 2011, and did the full "Learn You Some Erlang for Great Good!" tutorial and about 1/2 of the Erlang Programming book (and exercises). Where I ended up is that I had no real-world use cases that would benefit from Erlang, so I just kind of atrophied with it. It seems to me like Erlang is really really good at building programs that can be modeled with message passing (like chat), but a lot of problems are difficult to map to that paradigm (or perhaps my mind just has trouble envisioning how to do it yet). The closest I got was starting to use it to write a distributed Web crawler, but I ended up using scrapy (a Python framework) because the string manipulation was annoying with Erlang, and scrapy already had a lot of features that I would have had to re-implement on my own. But as I'm starting to try and manage crawler distribution with Celery and RabbitMQ, I find myself starting to think more and more about how Erlang would probably do this bit in particular better, so I might return to it.
The language that I've since discovered I really want for most tasks is Haskell. I've been programming Ruby full-time for the last few years, and I've grown really jaded with it. I get sick of having to write so many unit tests around everything in what I see as a poor fix for its loosy-goosyness. I'm still pretty early on in learning Haskell, but I find the approach towards correctness first to be exactly what I want, and while so far some of the material is pretty challenging I can see it will be very rewarding as well.
Never used it, have thought about spending an hour or two to play with it but ultimately:
There is no good reason that I have encountered yet where I need to use it. Generally I think people try to use the tools they have at their disposal to solve a problem. I have python, and I can do most things in python. It's not always efficient, and as an example, when I first started using python, I blindly used urllib without thinking about it. The requests library has been getting momentum recently, and I found that I prefer it and that it simplifies some of what I do, but at the end of the day why would I have searched for an alternative if what I had was working?
As developers we have to value our time. In an ideal world we would learn everything there was to know about every programming language, and pick the appropriate language for each project. In reality we stop to think that a language is capable of achieving a task, and if it is, we don't look any further.
Ironically, the reason so many people use c/java/python/ruby is because so many people use c/java/python/ruby.
There is no good reason that I have encountered yet where I need to use it. Generally I think people try to use the tools they have at their disposal to solve a problem. I have python, and I can do most things in python. It's not always efficient, and as an example, when I first started using python, I blindly used urllib without thinking about it. The requests library has been getting momentum recently, and I found that I prefer it and that it simplifies some of what I do, but at the end of the day why would I have searched for an alternative if what I had was working?
As developers we have to value our time. In an ideal world we would learn everything there was to know about every programming language, and pick the appropriate language for each project. In reality we stop to think that a language is capable of achieving a task, and if it is, we don't look any further.
Ironically, the reason so many people use c/java/python/ruby is because so many people use c/java/python/ruby.
I looked at it, even bought a couple books. A guy here at work was a huge booster for it, and used it in some small piece of production code. It looked cool, and I love parallel and distributed processing, so the idea of 'fail fast' appealed to me because of how it seemed to simplify a lot of thinking about such things. Hot swapping sounds awesome.
But
1) I don't currently do much that requires any of that.
2) I don't want to learn a completely different 'kind' of language just to hit one pain point.
3) Resources are quite limited (re the website, training, books)
4) and this is the biggee: I just don't want to do functional programming. Our Erlang booster? Want to know how much time he sometimes spent on mailing lists and such asking "how do you do X"? I mean for pretty basic stuff. I get the value of functional programming and immutability ("oh no you don't" you'll respond, but bear with me), but in the end it is too high a price to pay FOR ME. I work in imperative languages, I am comfortable in them, I can't get away from them (I need C++ for speed, for example), I'm just not going to take on a language that kicks my legs out from under me like that. Y'all can argue about the finer points of functional vs whatever, but I'll abstain. I'm interested in solving my problems, and the imperative model works very well for my brain and needs.
So, for me, an interesting toy. I'm 47 and don't have time to chase 'yet another language' which is all this is for me.
Now, if I was trying to solve issues like the ones that got Armstrong to write Erlang in the first place, perhaps I'd revisit it. But as it is? No. No time. Not enough return on the investment.
But
1) I don't currently do much that requires any of that.
2) I don't want to learn a completely different 'kind' of language just to hit one pain point.
3) Resources are quite limited (re the website, training, books)
4) and this is the biggee: I just don't want to do functional programming. Our Erlang booster? Want to know how much time he sometimes spent on mailing lists and such asking "how do you do X"? I mean for pretty basic stuff. I get the value of functional programming and immutability ("oh no you don't" you'll respond, but bear with me), but in the end it is too high a price to pay FOR ME. I work in imperative languages, I am comfortable in them, I can't get away from them (I need C++ for speed, for example), I'm just not going to take on a language that kicks my legs out from under me like that. Y'all can argue about the finer points of functional vs whatever, but I'll abstain. I'm interested in solving my problems, and the imperative model works very well for my brain and needs.
So, for me, an interesting toy. I'm 47 and don't have time to chase 'yet another language' which is all this is for me.
Now, if I was trying to solve issues like the ones that got Armstrong to write Erlang in the first place, perhaps I'd revisit it. But as it is? No. No time. Not enough return on the investment.
Based on my (limited) experience. (Learned it for the sake of learning it, thought it was fun to work with, not considering using it for any serious projects.):
I think it's similar to the reason why DSP's aren't very popular compared to general-purpose CPUs for most tasks. It's a very specialized tool, designed to solve a very specialized problem. If you don't have that problem, it's not a practical choice because it's more difficult to use and often ill-suited to more common problems. I'm sure plenty of others have mentioned strings already.
Even if you do have that problem, but only a little bit, it might not be a practical choice. There are a lot of tasks where a DSP might perform better but a general-purpose CPU's still preferable because it's good enough, and the skills necessary to work with one are more common. The story's similar for choice of programming language in many applications that require concurrency and fault tolerance, but not to any particularly great extent.
I think it's similar to the reason why DSP's aren't very popular compared to general-purpose CPUs for most tasks. It's a very specialized tool, designed to solve a very specialized problem. If you don't have that problem, it's not a practical choice because it's more difficult to use and often ill-suited to more common problems. I'm sure plenty of others have mentioned strings already.
Even if you do have that problem, but only a little bit, it might not be a practical choice. There are a lot of tasks where a DSP might perform better but a general-purpose CPU's still preferable because it's good enough, and the skills necessary to work with one are more common. The story's similar for choice of programming language in many applications that require concurrency and fault tolerance, but not to any particularly great extent.
Something not mentioned in the the list of criticisms linked by gordonguthrie is the lack of a coherent release and distribution framework. There are several half baked implementations none of which have the full support of the community. Sure Erlang allows hot code swap, but it's mostly a manual process requiring a user to interact with the shell.
Erlang requires a fair amount of boilerplate for a small project (rebar, app file, application behaviour, gen_server behaviour, etc.) and escript doesn't work very well.
It lacks a good way to do abstract data types (records don't count).
The compiler's ability to optimize is limited by the lack of purely functional guarantees and the metaprogramming facilities (parse transforms) aren't easy to use to work around that.
There's no facility like Haskell's ST or clojure transients to encapsulate mutable stuff, just a hole to write code in C and who really wants to do that? Yes, I know about the process dictionary and ets but those aren't appropriate for most algorithms I've wanted mutability for.
That said, I still use Erlang, but only in the domains where it really shines.
It lacks a good way to do abstract data types (records don't count).
The compiler's ability to optimize is limited by the lack of purely functional guarantees and the metaprogramming facilities (parse transforms) aren't easy to use to work around that.
There's no facility like Haskell's ST or clojure transients to encapsulate mutable stuff, just a hole to write code in C and who really wants to do that? Yes, I know about the process dictionary and ets but those aren't appropriate for most algorithms I've wanted mutability for.
That said, I still use Erlang, but only in the domains where it really shines.
I like a lot of things about Erlang. But the main reason I would be wary of using it is that it seems like an all-or-nothing kind of thing. The distributed actor model effectively means Erlang everywhere. This contrasts with RPC, queues, http, etc. where a variety of technologies (and languages) can be combined together. And an all-in approach seems laden with risk - all devs and relevant technologies need to fit in with the Erlang stack.
And if you are not using distributed actors, then why bother with Erlang at all?! (It's a nice language to be sure, but there are lots of nice functional languages available so the competition is pretty fierce).
And if you are not using distributed actors, then why bother with Erlang at all?! (It's a nice language to be sure, but there are lots of nice functional languages available so the competition is pretty fierce).
Tons of people mention Elixir in threads like these. Is anybody actually using it in production, or is it just something that Rubyists use as a foil to criticize Erlang's syntax?
I feel the algol-ization of (functional, prototypical)javascript is a confusing mess and a weakness that makes js harder to use. Making Erlang look object-oriented just seems awkward.
Syntax: comma means AND, semicolon means OR, period means "done." Is that so crazy? There's no comparison to how badly Perl does my head in.
I feel the algol-ization of (functional, prototypical)javascript is a confusing mess and a weakness that makes js harder to use. Making Erlang look object-oriented just seems awkward.
Syntax: comma means AND, semicolon means OR, period means "done." Is that so crazy? There's no comparison to how badly Perl does my head in.
I've started using Elixir on my projects over the last few months, and I absolutely love it. It's not just the cleaner syntax, the language adds features on top of what Erlang already provides, and provides easy interop between the two languages, the documentation is better, the build tool (mix) is great, and I think the community is awesome.
It's a new language, and it won't be 1.0 until later this year, but if you're willing to live on the edge a bit, I think the rewards are well worth it.
It's a new language, and it won't be 1.0 until later this year, but if you're willing to live on the edge a bit, I think the rewards are well worth it.
The erlang syntax is actually much simpler than Elixir's which both contains more syntax and alternate ways of writing things.
A language needs to get a foothold somewhere. Ruby started on the low end and worked its way into a position of power. Java started in the enterprise and became normal thanks to catering to their needs so well. Erlang is in an awkward place where it solves certain problems well, but there is not a big class of user for it to get a foothold in. It's not better than Ruby at bring Ruby and it isn't better than Java at being Java and it isn't better than C at being C.
I guess that's why Elixir exists, which is sort of like Erlang with Ruby semantics.
http://elixir-lang.org/
http://elixir-lang.org/
I have learnt a small amount of it a few times, I use and rely on RabbitMQ every day so it is important I know a bit about it.
That said I just can't get over how bizarre and jarring the syntax is, this paired with the configuration structure and error messages really make it hard to get into to.
Having seen a few talks on the subject I tend to agree, more recently I am using golang for most of the things I intended to do in Erlang.
The reason I chose this route is to stick with a syntax which is common to all the languages i use day to day, while exploring a new, but much smaller toolset for building concurrent applications.
It seemed to me a much wiser route in the long run.
That said I still like the Erlang runtime and the modules it provides, if only the authors of the language could chart a course out of this unusual and sometimes frustrating syntax.
On elixir, I really hope this catches on but unfortunately like coffee script you will still need to get your hands dirty in Erlang if you want to wrap any existing libs or modules available in the runtime, or debug the crazy error messages it produces from time to time.
That said I just can't get over how bizarre and jarring the syntax is, this paired with the configuration structure and error messages really make it hard to get into to.
Having seen a few talks on the subject I tend to agree, more recently I am using golang for most of the things I intended to do in Erlang.
The reason I chose this route is to stick with a syntax which is common to all the languages i use day to day, while exploring a new, but much smaller toolset for building concurrent applications.
It seemed to me a much wiser route in the long run.
That said I still like the Erlang runtime and the modules it provides, if only the authors of the language could chart a course out of this unusual and sometimes frustrating syntax.
On elixir, I really hope this catches on but unfortunately like coffee script you will still need to get your hands dirty in Erlang if you want to wrap any existing libs or modules available in the runtime, or debug the crazy error messages it produces from time to time.
I found learning Erlang difficult since pattern matching is poorly justified in the material I came across. You don't see the benefit right off the bat.
Also, the "processes only" model is pretty off-putting compared to Scala IMO where you're able to choose between threads and processes. You lose _some_ benefit in reliability (I assume, since it's said so often), but I've never seen that actually play out in the real world. What I have seen is comparably slow IPC exactly a real world development cost. So I'm personally more of a "in-process first" kinda guy.
I may be completely wrong on that one BTW. It's just what I recall from reading half of some Erlang book and studying online material trying to pick up the language.
It wasn't until Scala and Akka that the benefits of both pattern-matching and actors really clicked with me. Though I still prefer Scala's versions on both counts so I don't feel a great need to revisit Erlang at this point since I'm not working with Telco equipment. ;-)
Also, the "processes only" model is pretty off-putting compared to Scala IMO where you're able to choose between threads and processes. You lose _some_ benefit in reliability (I assume, since it's said so often), but I've never seen that actually play out in the real world. What I have seen is comparably slow IPC exactly a real world development cost. So I'm personally more of a "in-process first" kinda guy.
I may be completely wrong on that one BTW. It's just what I recall from reading half of some Erlang book and studying online material trying to pick up the language.
It wasn't until Scala and Akka that the benefits of both pattern-matching and actors really clicked with me. Though I still prefer Scala's versions on both counts so I don't feel a great need to revisit Erlang at this point since I'm not working with Telco equipment. ;-)
Shared state is great as long as you control it.
Databases are a giant blob of shared state, albeit a carefully-managed one. People complain about them all the time, but databases completely take over in huge areas of the application development landscape. There's a reason for that -- consistency is a very powerful simplifying assumption (giant understatement). Getting consistency in erlang may be possible, and of course you can still use a database from erlang, but the philosophy doesn't quite line up.
Databases already offer isolation between transactions. And they naturally work with immutable structures similar to functional programming.
For most applications out there, HA means replicating a database, and when it goes down (which is actually quite rare), you lose a little time doing a failover.
Hot code loading means uploading a PHP file with a new extension and "mv"ing it over the old one. Need schema changes? PostgreSQL offers transactional DDL (e.g. ALTER TABLE).
Any error in the database usually just causes that one transaction for that one request to fail. Any error in the application usually just crashes that one process serving that one request.
Philosophically, using erlang is trading consistency for availability. Given that it's easy to get good availability using normal applications connected to a database, using erlang is somewhat of a niche.
I have spent some effort learning erlang, and I really like it in many ways. I bought the new book and I like it so far. I have no problem with the syntax and I find it enjoyable to write in (though I haven't written any large programs). There are certain projects where I think erlang would be a great choice, like management and control of a cluster system. Obviously it works for telco-like things, too, but I've never developed anything like that.
Databases are a giant blob of shared state, albeit a carefully-managed one. People complain about them all the time, but databases completely take over in huge areas of the application development landscape. There's a reason for that -- consistency is a very powerful simplifying assumption (giant understatement). Getting consistency in erlang may be possible, and of course you can still use a database from erlang, but the philosophy doesn't quite line up.
Databases already offer isolation between transactions. And they naturally work with immutable structures similar to functional programming.
For most applications out there, HA means replicating a database, and when it goes down (which is actually quite rare), you lose a little time doing a failover.
Hot code loading means uploading a PHP file with a new extension and "mv"ing it over the old one. Need schema changes? PostgreSQL offers transactional DDL (e.g. ALTER TABLE).
Any error in the database usually just causes that one transaction for that one request to fail. Any error in the application usually just crashes that one process serving that one request.
Philosophically, using erlang is trading consistency for availability. Given that it's easy to get good availability using normal applications connected to a database, using erlang is somewhat of a niche.
I have spent some effort learning erlang, and I really like it in many ways. I bought the new book and I like it so far. I have no problem with the syntax and I find it enjoyable to write in (though I haven't written any large programs). There are certain projects where I think erlang would be a great choice, like management and control of a cluster system. Obviously it works for telco-like things, too, but I've never developed anything like that.
As an everyday language, it seems too different to get used to. As a language you learn to expand your horizons, it's not weird/different enough when compared to e.g. Haskell and Lisp.
Also, Erlang has long had an excellent reputation for performant, parallelizable code, but Go and node.js have stolen some of their thunder on that front. (I'm talking purely marketing-wise, I don't know enough to compare them technologically speaking.)
I'm not sure if "no platform / no package manager" really matters.
People first learn a language and get excited about it, and then if something irks them, they'll scratch that itch. It's like that famous de Saint Exupéry quote: "If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea."
The node.js ecosystem was absolutely awful at first, and the deployment story really only got fixed about a year or longer after the first release of NPM.
Also, Erlang has long had an excellent reputation for performant, parallelizable code, but Go and node.js have stolen some of their thunder on that front. (I'm talking purely marketing-wise, I don't know enough to compare them technologically speaking.)
I'm not sure if "no platform / no package manager" really matters.
People first learn a language and get excited about it, and then if something irks them, they'll scratch that itch. It's like that famous de Saint Exupéry quote: "If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea."
The node.js ecosystem was absolutely awful at first, and the deployment story really only got fixed about a year or longer after the first release of NPM.
I've actually considered learning Erlang, but never gone through with it as other languages seem more useful and/or enjoyable.
For me to seriously consider learning a new language/framework it should have:
Good documentation. Python is the gold standard. Good SEO for that documentation. Multiple good FREE learning resources, preferably with something useful being built. Good tooling (package manager, testing, etc)
Most importantly there should be a reason to learn it. For Node, I get easy asynchronous code. Clojure I get an enterprise-acceptable lisp. Go I get C-like performance + concurrency in an enjoyable language with modern tooling. Hell, learning Java allowed me to program for the Android.
Erlang? Well it's got some great concurrency and it's highly available. But I don't know anyone using it (and when I hear about it, it's usually because someone has stopped using it), it has a high learning curve and most of what makes it interesting can be found elsewhere.
For me to seriously consider learning a new language/framework it should have:
Good documentation. Python is the gold standard. Good SEO for that documentation. Multiple good FREE learning resources, preferably with something useful being built. Good tooling (package manager, testing, etc)
Most importantly there should be a reason to learn it. For Node, I get easy asynchronous code. Clojure I get an enterprise-acceptable lisp. Go I get C-like performance + concurrency in an enjoyable language with modern tooling. Hell, learning Java allowed me to program for the Android.
Erlang? Well it's got some great concurrency and it's highly available. But I don't know anyone using it (and when I hear about it, it's usually because someone has stopped using it), it has a high learning curve and most of what makes it interesting can be found elsewhere.
Rails made Ruby very popular.
Django made Python very popular.
There is no killer webframework for Erlang. However, N2O looks promising. [1]
Also, the learning curve: I took me half a day to be good enough in Python and years to learn the basics in Erlang. It is way more complex and the standard library is plagued with inconsistent/messy interfaces. (They say it is because of legacy code support or other BS.) But under the ugly surface lies the hidden beauty: single assignment is great when reading other people's code. Patching several running servers without stopping with one command is thrilling. Or the built-in nice abstractions for distributed programming like rpc:multicall [2].
[1]: http://synrc.com/framework/web/
[2]: http://erldocs.com/R16B03-1/kernel/rpc.html#multicall/3
Django made Python very popular.
There is no killer webframework for Erlang. However, N2O looks promising. [1]
Also, the learning curve: I took me half a day to be good enough in Python and years to learn the basics in Erlang. It is way more complex and the standard library is plagued with inconsistent/messy interfaces. (They say it is because of legacy code support or other BS.) But under the ugly surface lies the hidden beauty: single assignment is great when reading other people's code. Patching several running servers without stopping with one command is thrilling. Or the built-in nice abstractions for distributed programming like rpc:multicall [2].
[1]: http://synrc.com/framework/web/
[2]: http://erldocs.com/R16B03-1/kernel/rpc.html#multicall/3
It has a huge learning curve compared to many other languages.
Ask the simple question of how do you write the equivalent of
int main(....) { ... } and well... there isn't one!
You are almost forced, from the start, to learn about releases and a ton of other really complicated stuff just to write a program you can share. Its sort of being fixed with relx.
Secondly no one seems to understand pattern matching at first. Its just such an alien concept when you look at it compared to all the other mainstream procedural/oo languages people usually already know. Again a huge cliff to climb to really grasp the possibilities and usage.
It really is quite a great language, and an even better runtime. The learning curve to making great things with it is just quite high in my opinion. I've done two major projects with it, one shipped as an embedded web app in some lab equipment out there. I think it was a good choice!
Ask the simple question of how do you write the equivalent of
int main(....) { ... } and well... there isn't one!
You are almost forced, from the start, to learn about releases and a ton of other really complicated stuff just to write a program you can share. Its sort of being fixed with relx.
Secondly no one seems to understand pattern matching at first. Its just such an alien concept when you look at it compared to all the other mainstream procedural/oo languages people usually already know. Again a huge cliff to climb to really grasp the possibilities and usage.
It really is quite a great language, and an even better runtime. The learning curve to making great things with it is just quite high in my opinion. I've done two major projects with it, one shipped as an embedded web app in some lab equipment out there. I think it was a good choice!
#!/usr/bin/env escript
main(_) -> io:format("hello, world").
main(_) -> io:format("hello, world").
Fair enough, but thats not how the books and documentation present erlang. They present it with the shell and c()
Good point. Never thought of that...
My thoughts:
- Ugly, yet simple syntax - Ugly OTP, yet powerful - emacs - Grumpy community, just like freebsd-dudes. - Isn't general purpose - Breaking meta on ever step: no loops, no variables, no strings, actors, recursions, no namespaces (i mean like in any popular language) - Nobody writes tutorials. - Poor library selection. Look at RoR, having 40 dependencies is okay there. - Situations like you do everything like in Basho's getting started for webmachine, and nothing is working - A lot of libraries that do the same thing, which is funny because it lacks of other libraries. Don't you dare ask community which webserver to use. - If you ask about IDE on [email protected] - almost instant ban, because, you know, trolling.
- Ugly, yet simple syntax - Ugly OTP, yet powerful - emacs - Grumpy community, just like freebsd-dudes. - Isn't general purpose - Breaking meta on ever step: no loops, no variables, no strings, actors, recursions, no namespaces (i mean like in any popular language) - Nobody writes tutorials. - Poor library selection. Look at RoR, having 40 dependencies is okay there. - Situations like you do everything like in Basho's getting started for webmachine, and nothing is working - A lot of libraries that do the same thing, which is funny because it lacks of other libraries. Don't you dare ask community which webserver to use. - If you ask about IDE on [email protected] - almost instant ban, because, you know, trolling.
My thoughts:
- Ugly, yet simple syntax - Ugly OTP, yet powerful - emacs - Grumpy community, just like freebsd-dudes. - Isn't general purpose - Breaking meta on ever step: no loops, no variables, no strings, actors, recursions, no namespaces (i mean like in any popular language) - Nobody writes tutorials. - Poor library selection. Look at RoR, 40 dependencies is okay there. - Situations like you do everything like in Basho's getting started for webmachine, and nothing is working - A lot of libraries that do the same thing, which is funny because it lacks of other libraries. Don't you dare ask community which webserver to use. - If you ask about IDE on [email protected] - almost instant ban, because, you know, trolling.
- Ugly, yet simple syntax - Ugly OTP, yet powerful - emacs - Grumpy community, just like freebsd-dudes. - Isn't general purpose - Breaking meta on ever step: no loops, no variables, no strings, actors, recursions, no namespaces (i mean like in any popular language) - Nobody writes tutorials. - Poor library selection. Look at RoR, 40 dependencies is okay there. - Situations like you do everything like in Basho's getting started for webmachine, and nothing is working - A lot of libraries that do the same thing, which is funny because it lacks of other libraries. Don't you dare ask community which webserver to use. - If you ask about IDE on [email protected] - almost instant ban, because, you know, trolling.
Have never used it nor considered it.
The driving force behind most of the new languages I have adopted; is a friend with experience who plants seeds, then can offer support and answer simple questions as I am learning. I have no friends that I know of who use Erlang.
The driving force behind most of the new languages I have adopted; is a friend with experience who plants seeds, then can offer support and answer simple questions as I am learning. I have no friends that I know of who use Erlang.
[deleted]
Erlang isn't more popular because to be popular you need to be at least passably good at a lot of things. There is a lot of stuff where Erlang makes life hard. Operating system integration, lack of IDE, imperative programming, UTF-8 manipulation, and maps (which just hit the language) are all good examples of things that Erlang gets stomped on by most more "mainstream" languages.
That having been said, anybody who is serious about concurrent network programming knows about Erlang. The problem is that those people are far outnumbered by the people doing CRUD all the time.
That having been said, anybody who is serious about concurrent network programming knows about Erlang. The problem is that those people are far outnumbered by the people doing CRUD all the time.
Erlang needs a production quality web server that is a fully compliant OTP application, and mnesia needs to have its dependency on dets abstracted away so that other storage engines can be used (relational database of choice, dynamodb, etc.). This would give a web developer a single platform that is extremely fault tolerant and scalable. This sort of thing may be possible (by using an embedded web server wrapped in your own OTP code and by experimental mnesia extensions), but it wouldn't be easy to get it set up and working.
Yaws, Cowboy and Mochiweb are production quality, and are in production.
I've actually always wanted to use Erlang and I've worked on quite a few projects where it probably would have been the best solution possible (massively concurrent websocket backends for example). The two things that made Erlang a non-starter on those projects were:
1) It's hard to find people that have production experience with Erlang 2) The perception is that batteries are not included (even in comparison with Go... if you have some information to refute that notion I would be more than happy to learn more)
1) It's hard to find people that have production experience with Erlang 2) The perception is that batteries are not included (even in comparison with Go... if you have some information to refute that notion I would be more than happy to learn more)
I've used it and I like it alright. I like the CSP style communication and automatic serialization especially. However, I probably would seek another alternative in the future. Here are my primary concerns.
1. Erlang performance is not very good (forcing significant FFI usage which is a pain).
2. Debugging code which is a mix of Erlang and C is difficult
3. Weakly typed language seems unsuitable for larger projects.
4. Better interop with C++ or Java would be a plus.
5. The syntax I can see people complaining about but it didn't bother me.
1. Erlang performance is not very good (forcing significant FFI usage which is a pain).
2. Debugging code which is a mix of Erlang and C is difficult
3. Weakly typed language seems unsuitable for larger projects.
4. Better interop with C++ or Java would be a plus.
5. The syntax I can see people complaining about but it didn't bother me.
Re 3: A nit, it's not weakly typed, it's dynamically typed. The type of a variable X may be an integer or a list. But you can't ask for the head of an integer or multiply a list by 3. That said, I half-agree with you. I find static typing or tools which can perform static analysis to be a great benefit in working with larger projects or other coding with other people. Tools for static analysis exist for erlang and come with the standard install, dialyzer.
Distel solves most of your 3 point. I am working as a full time Erlang developer for the last half year on a company with 6 or 7 Erlang developers. We got some big projects (many thousands concurrent users), and never had an issue with the fact that Erlang is weakly typed.
There's a lot that I like about Erlang the language, but using it in production left a sour taste in my mouth due to difficult-to-find documentation, difficulty in testing the code, and (especially) the misery that is mnesia.
It was a poor fit with our cloud-based infrastructure, and once the mnesia database began corrupting itself weekly, requiring a full rebuild, it was an easy decision to move to another solution for what we were using it for.
It was a poor fit with our cloud-based infrastructure, and once the mnesia database began corrupting itself weekly, requiring a full rebuild, it was an easy decision to move to another solution for what we were using it for.
mnesia is indeed a frequent choice by newbies for queryable storage in Erlang, but I've found few production systems use it for similar reasons to the ones you describe. Nowadays you're more likely to see external datastores (PostgreSQL, MySQL, etc) used except for transient/in-memory stuff which can be stuffed in ETS.
i find messaging between processes and handle exits can be a bit awkward as well.
for example if you send a message to a process there is no way to know whether it actually received the message or not. if you wait for a reply from the process then you can tell if the process received your message AND processed it but sometimes you only want to do the first for performance as well as semantic reasons. for example you may not want to retry sending a message that has crashed a process. i think this is because erlang wants to be network transparent and with the network you obviously can't be 100% sure whether your message was received or not.
handling exit()s is a bit weird as well. you get a message which is like {'EXIT', pid_that_called_exit_or_the_pid_you_are_linked_to}. so you need to know who would call exit() on you to handle exits correctly (OTP assumes only your parent will call exit on you) or assume that you will know all your linked pids correctly at all times and if you get an exit for a pid that is not linked then assume it is for you. i think it would much cleaner if there was a way to differentiate between an EXIT from a linked pid and an EXIT from yourself.
for example if you send a message to a process there is no way to know whether it actually received the message or not. if you wait for a reply from the process then you can tell if the process received your message AND processed it but sometimes you only want to do the first for performance as well as semantic reasons. for example you may not want to retry sending a message that has crashed a process. i think this is because erlang wants to be network transparent and with the network you obviously can't be 100% sure whether your message was received or not.
handling exit()s is a bit weird as well. you get a message which is like {'EXIT', pid_that_called_exit_or_the_pid_you_are_linked_to}. so you need to know who would call exit() on you to handle exits correctly (OTP assumes only your parent will call exit on you) or assume that you will know all your linked pids correctly at all times and if you get an exit for a pid that is not linked then assume it is for you. i think it would much cleaner if there was a way to differentiate between an EXIT from a linked pid and an EXIT from yourself.
Why do you want to know if it received the message? If you need that why not call a function? I used to do a lot of work with soft real time message passing using MPL (Motorola Programming Language) and SDL where the whole program was simply a state machine implemented by sending messages. I don't think I ever felt the need to have one process send confirmation back to say that the message had been received.
I learned Erlang at University, and haven't come across it in the real world yet. I've mostly been locked into Microsoft houses since I graduated.
It's not wasted, though. I use my knowledge of functional programming to write better, more stable programs in Javascript and C#.
The lessons of Erlang, of what can be achieved when one shrugs off the burden of state... are extremely valuable in scalable, concurrent programming - regardless of language.
It's not wasted, though. I use my knowledge of functional programming to write better, more stable programs in Javascript and C#.
The lessons of Erlang, of what can be achieved when one shrugs off the burden of state... are extremely valuable in scalable, concurrent programming - regardless of language.
Since you asked: I have never tried Erlang because I've heard it's like Haskell but harder to learn, and Haskell already breaks my feeble mind, so I have steered clear. This may or may not be an accurate picture, but it was my decision-making process. I have no programming problems that make me think learning a whole new language would be worth it (on top of my existng stack of 10 or so).
Erlang is much easier than Haskell. Erlang is a pretty good gateway into Haskell, too; if you know Erlang, you have fewer things in Haskell throwing you for a loop. It's the road I travelled, and Haskell is certainly easier to use when you've already gotten immutability, and writing useful programs with immutability, already nailed down, so you're just learning the things specific to Haskell rather than trying to swallow an entire major new paradigm at once.
I don't understand how Erlang could be "like Haskell" other than the fact that they could both be considered "functional." When I think of Haskell, I think of it's type system, and Erlang's type system is feeble compared to Haskell's.
Erlang is much easier than Haskell. Haskell breaks my mind, but Erlang is easy-peasy.
I have picked up my copy of "Real World Haskell" (Bryan O'Sullivan et.al) about three times; each time ended up nearly starting over and each time making it about ten pages or so more in, (i guess it's a recursive language at several levels). It's a fascinating approach, but egads, it requires a thousand fold more effort to get into than any other language i've learned. somewhere between the monads and the syntax..[hollywood car explosion]
somehow Haskell makes me feel bad about myself; like an ultra strict grade school teacher.
somehow Haskell makes me feel bad about myself; like an ultra strict grade school teacher.
I like Real World Haskell a lot. The chapters on how to do real work like parsing audio files was fascinating to me. Too many functional language books seem to get hung up on the mechanisms like partials and reducing, but not on how I should use them with stateful tasks.
I've read both Real World Haskell and Learn You a Haskell. Read Learn You a Haskell, I suspect you'll like it much better.
I'm always baffled by these kinds of statements. I learned ocaml first, so haskell wasn't too big a leap for me. But I did get to watch my wife go through the process of learning haskell, and she didn't have any more problems than learning any other language.
My wife is a web designer. She has no interest in programming. She taught herself PHP and javascript because she needed to use them. When she finally got to the point where she couldn't tolerate PHP's shittiness anymore, she asked me what she should use instead. I said "scala is a good choice, or you could just skip a step and go straight to haskell". She tried both, decided on haskell because she didn't like lift or play, and proceeded to teach herself haskell. She has never read real world haskell, or even learn you a haskell. I just asked her what a monad is: "Beats me, just use do and the arrow things". She's already finished two big websites written in haskell. This idea that you need to be a compsci phd or something to use haskell is simply not reality.
My wife is a web designer. She has no interest in programming. She taught herself PHP and javascript because she needed to use them. When she finally got to the point where she couldn't tolerate PHP's shittiness anymore, she asked me what she should use instead. I said "scala is a good choice, or you could just skip a step and go straight to haskell". She tried both, decided on haskell because she didn't like lift or play, and proceeded to teach herself haskell. She has never read real world haskell, or even learn you a haskell. I just asked her what a monad is: "Beats me, just use do and the arrow things". She's already finished two big websites written in haskell. This idea that you need to be a compsci phd or something to use haskell is simply not reality.
> This idea that you need to be a compsci phd or something to use haskell is simply not reality.
The fact that there is so much maths talk surrounding Haskell really doesn't help. And I've watched many, many discussions about Haskell go into deep arguments about category theory. I want to write a program, not write a computer science paper.
The fact that there is so much maths talk surrounding Haskell really doesn't help. And I've watched many, many discussions about Haskell go into deep arguments about category theory. I want to write a program, not write a computer science paper.
>The fact that there is so much maths talk surrounding Haskell really doesn't help
Nor does it hurt. It only provides something for people to point to while they say "look, people are talking about something I am not interested in, therefore haskell is too hard and I shouldn't bother trying".
>And I've watched many, many discussions about Haskell go into deep arguments about category theory
You are not required to participate in any discussions you don't want to participate in.
>I want to write a program
So do it? The whole point of my post is that it is perfectly simple to do so. If a non-programmer can teach herself haskell and be productive with it, there's no reason a programmer can't.
Nor does it hurt. It only provides something for people to point to while they say "look, people are talking about something I am not interested in, therefore haskell is too hard and I shouldn't bother trying".
>And I've watched many, many discussions about Haskell go into deep arguments about category theory
You are not required to participate in any discussions you don't want to participate in.
>I want to write a program
So do it? The whole point of my post is that it is perfectly simple to do so. If a non-programmer can teach herself haskell and be productive with it, there's no reason a programmer can't.
> So do it?
A huge part of a programming language is, in fact, its community. I'd say that's more important than the language itself; any given feature can and will be replicated, but the community cannot be.
I cannot get the maximum out of Haskell if I cannot get involved in its community, which is heavily CS-oriented.
A huge part of a programming language is, in fact, its community. I'd say that's more important than the language itself; any given feature can and will be replicated, but the community cannot be.
I cannot get the maximum out of Haskell if I cannot get involved in its community, which is heavily CS-oriented.
Have you interacted with the Haskell community? The Haskell community is made up of individuals who come to Haskell from a variety of different backgrounds. Yes there are a lot of Computer Scientists using Haskell, but not all of us are programming languages PhDs. There are people who are interested in designing hardware and build HDLs in Haskell. There are others who use it for its correctness and performance characteristics when building large scale systems. Some are just doing web development. The community is probably one of the most helpful and friendly as well. The people in the IRC channel are always ready to help and encourage new comers with resources and advice. I have had a much better experience in #haskell them I ever had in #ruby, and usually the explanations are correct and clear.
It's unclear to me whether you want "to write a program" or to "get the maximum out of Haskell". Those are two very different goals.
The thing is, I can write a program in any language. The reason for learning a new language would be to learn a new way of thinking, to "get the maximum out of it". If I can't get involved in its community, I can't do that properly.
If you don't want to learn haskell then don't. It is the weird insistence on making up ridiculous excuses that I have a problem with. Making up a strawman version of "the haskell community" is entirely unnecessary. Once again, a web designer with no CS education of any sort can do it without any problems at all. Your excuse is obviously baloney.
I would like to see these 2 big sites that your wife has single handedly done in Haskell with a "just use do and the arrow things" understanding.
Yes, but newcomers don't know that. First thing they see is old school algol-like spaghetti. :) Haskell looks much nicer.
what does this nicer non-spaghetti do?
chunkWith :: ([a] -> ([a], [a])) -> [a] -> [[a]]
chunkWith _ [] = []
chunkWith f xs = let (h, t) = f xs in h : chunkWith f t
i'm sure that many here merely glance at that and understand it immediately. but as i typed above, it somehow makes me feel bad about my own stupidity. (no need for anyone to explain specifically what this tiny example does, (i actually happen to understand this one). the goal here is to admire the immediate obviousness of the syntax ;))
chunkWith :: ([a] -> ([a], [a])) -> [a] -> [[a]]
chunkWith _ [] = []
chunkWith f xs = let (h, t) = f xs in h : chunkWith f t
i'm sure that many here merely glance at that and understand it immediately. but as i typed above, it somehow makes me feel bad about my own stupidity. (no need for anyone to explain specifically what this tiny example does, (i actually happen to understand this one). the goal here is to admire the immediate obviousness of the syntax ;))
Have you tried learning Haskell with http://learnyouahaskell.com ? It always saddens me when people think their mind is too "feeble" for learning something, whatever it may be, because in most cases it isn't!
There is of course the equivalent in erlang
http://learnyousomeerlang.com/
http://learnyousomeerlang.com/
I found Erlang a lot easier to learn than Haskell. I don't really find them to be very similar, especially because they have a completely different evaluation strategy. The syntax and semantics are also quite different. Specifically, Haskell's non-strict (lazy) evaluation turns everything inside out so you tend to write many things in a different way than you would in Erlang.
This is very old but...
http://wagerlabs.com/blog/2006/01/01/haskell-vs-erlang-reloa...
http://wagerlabs.com/blog/2006/01/01/haskell-vs-erlang-reloa...
Erlang is meant to be high-availability and high-performance language. Good. It has potentials.
However, I cannot build any high-availability and or high-performance system based on it because it lack community around it. I.e., if something stops working there is very little resources or support - I'm not even sure if anybody tried or tested that.. So it is chicken and egg problem :(
However, I cannot build any high-availability and or high-performance system based on it because it lack community around it. I.e., if something stops working there is very little resources or support - I'm not even sure if anybody tried or tested that.. So it is chicken and egg problem :(
> doesn't run on the JVM
https://github.com/trifork/erjang
https://github.com/trifork/erjang
This is an implementation of Beam on the JVM, not an implementation of Erlang-the-language.
It offers few, if any, of the advantages of being a JVM-native language. (e.g. java interop)
It offers few, if any, of the advantages of being a JVM-native language. (e.g. java interop)
What nearly all these comments seem to agree on is that the syntax of Erlang is unusual, which poses a not insignificant barrier to entry.
Personally, I'm willing to try a new unusual language if there's some killer feature, but I haven't heard much about Erlang at all. What incentive is there to put in the extra effort if there is no perceived benefit?
Personally, I'm willing to try a new unusual language if there's some killer feature, but I haven't heard much about Erlang at all. What incentive is there to put in the extra effort if there is no perceived benefit?
Short answer: You have to be slightly smarter than average to use it properly.
Longer answer: The only proper way to learn Erlang is to read the documentation. Then re-read the documentation. All of it. It takes 3-6 months to get proficient, then another 6 months to stop doing things the native or outright bad way.
If you are primarily an "erlang programmer," you can't interview for jobs. Everybody hires for either java, ruby, or python. If you do see a rare "Erlang job" position, they probably actually mean "We want you to understand ejabberd because we based our company around it and it's actually unusable at scale, so you get to fix other people's problems all day long." (Of course, building your own company/services around Erlang stops the "need to interview in other languages" problem.)
But, why can't you interview in Erlang? I guess you can, but the way I work, I have an editor in one window and API docs in the other. Interviewers, sitting up there on their oh-so-high perches, don't like it when candidates want to do quick API lookups for things like parameter order or return values. (Does it take (Fun, List) or (List, Fun)? Does it return Value or {ok, Value} or {value, Value}?)
Short conclusion: Erlang is a system and understanding systems takes effort and practice. People, in general, don't want to learn, they want to do. It's the whole "one year of experience 15 times over" instead of 15 years of growth and advancement problem. It's the "person with 20 years in computing can't write a tail recursive function" problem. It's just a problem.
Alternative question: why don't people understand defmacro (and recursive defmacro) and write their programs from the bottom up?
Bonus analysis: In a world where people just want to learn one thing and use it forever, Erlang doesn't fit. With Python, you can learn it once then keep "extending" it to pretend to get concurrency and other fancy features Python actively rejects at the implementation level. So, you learn Python once, then feel productive because you're duplicating functionality given to you for free in other languages.
Erlang has so much "done right the first time" built into its VM you don't have to reinvent basic parallel computing every time you want to get two webpages at once or serve more than one client at a time from a basic five line server. But—Erlang people know for other tasks, say something better served by numpy, they should jump over to Python or Lua or something else better suited to the task without reimplementing all of the "they did it right the first time" code in Erlang just because they refuse to learn any other language.
Longer answer: The only proper way to learn Erlang is to read the documentation. Then re-read the documentation. All of it. It takes 3-6 months to get proficient, then another 6 months to stop doing things the native or outright bad way.
If you are primarily an "erlang programmer," you can't interview for jobs. Everybody hires for either java, ruby, or python. If you do see a rare "Erlang job" position, they probably actually mean "We want you to understand ejabberd because we based our company around it and it's actually unusable at scale, so you get to fix other people's problems all day long." (Of course, building your own company/services around Erlang stops the "need to interview in other languages" problem.)
But, why can't you interview in Erlang? I guess you can, but the way I work, I have an editor in one window and API docs in the other. Interviewers, sitting up there on their oh-so-high perches, don't like it when candidates want to do quick API lookups for things like parameter order or return values. (Does it take (Fun, List) or (List, Fun)? Does it return Value or {ok, Value} or {value, Value}?)
Short conclusion: Erlang is a system and understanding systems takes effort and practice. People, in general, don't want to learn, they want to do. It's the whole "one year of experience 15 times over" instead of 15 years of growth and advancement problem. It's the "person with 20 years in computing can't write a tail recursive function" problem. It's just a problem.
Alternative question: why don't people understand defmacro (and recursive defmacro) and write their programs from the bottom up?
Bonus analysis: In a world where people just want to learn one thing and use it forever, Erlang doesn't fit. With Python, you can learn it once then keep "extending" it to pretend to get concurrency and other fancy features Python actively rejects at the implementation level. So, you learn Python once, then feel productive because you're duplicating functionality given to you for free in other languages.
Erlang has so much "done right the first time" built into its VM you don't have to reinvent basic parallel computing every time you want to get two webpages at once or serve more than one client at a time from a basic five line server. But—Erlang people know for other tasks, say something better served by numpy, they should jump over to Python or Lua or something else better suited to the task without reimplementing all of the "they did it right the first time" code in Erlang just because they refuse to learn any other language.
I'm seriously thinking about Erlang now. What raised my eyebrows was "2-3 million concurrent connections on a single FreeBSD box"[this is what WhatsApp achieved]. Async network IO can be done with library support in Python, natively in nodeJS, etc. I wonder if one can push those stacks to this level.
> concurrent connections on a single FreeBSD box
Do you have a source for that? I'd love to read more
Do you have a source for that? I'd love to read more
The first three results on google for me for 'whatsapp freebsd erlang concurrent connection' are -
https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-...
http://blog.whatsapp.com/index.php/2011/09/one-million/
http://www.erlang-factory.com/upload/presentations/558/efsf2...
Perhaps those would make a good starting point?
https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-...
http://blog.whatsapp.com/index.php/2011/09/one-million/
http://www.erlang-factory.com/upload/presentations/558/efsf2...
Perhaps those would make a good starting point?
Whatapp old video talk and presentation on it. You can search it on HN.
Um... it's not easy to get 2-3million they did it but they also profile the crap out of it.
I think they easily got 1 million out of the box though.
Um... it's not easy to get 2-3million they did it but they also profile the crap out of it.
I think they easily got 1 million out of the box though.
Can I get anything like this with a more common tech stack? I.e. Node JS, Java + NIO, Python + Twisted (or something else)? 10K, I get. But 1 million+ is freakin awesome in my books.
[deleted]
A mixture of things:
1. It doesn't fill a pressing need
2. It has foreign syntax
3. It's hard to tell if it has familiar semantics (due to #2)
Credentials: I looked at some Erlang sample code twice and haven't looked at it again since; also, I'm no stranger to new languages, I fully adopted Clojure within a month of learning it
1. It doesn't fill a pressing need
2. It has foreign syntax
3. It's hard to tell if it has familiar semantics (due to #2)
Credentials: I looked at some Erlang sample code twice and haven't looked at it again since; also, I'm no stranger to new languages, I fully adopted Clojure within a month of learning it
For me it was lists for strings, something both basic and that I know I'd run into a lot.
Another issue is that a lot of languages are bringing Erlang's best feature (actor model concurrency) via libraries or into their core, so it makes me less interested in pursuing Erlang.
Another issue is that a lot of languages are bringing Erlang's best feature (actor model concurrency) via libraries or into their core, so it makes me less interested in pursuing Erlang.
* tried it & stopped
Performance was focused solely on throughput, latency was terrible for anything requiring even modest computation. Finally dropped it after rewriting a naive Clojure implementation of something that ran 8x faster than the Erlang version.
Performance was focused solely on throughput, latency was terrible for anything requiring even modest computation. Finally dropped it after rewriting a naive Clojure implementation of something that ran 8x faster than the Erlang version.
Coming from Haskell, the actor model does not seem composable. The state machine style is interesting, but the pattern that it comes out as distracts from the concept / algorithm.
This comes from reading rabbitmq and riak-core sources.
This comes from reading rabbitmq and riak-core sources.
Erlang has 3 issues. It has a VM dependency, its syntax is not C like, and it doesn't have a huge marketing budget. Elixer fixes #2, but I don't see it helping the other two issues.
Never used Erlang nor considered it, for the same reason C programmers don't start rewriting their code in Python: it's just not the right tool for the kind of stuff I work on.
> Never used Erlang nor considered it
---------------
Well, I guess only the first part of that is true now. :p
But yeah: Why not Erlang?
I haven't seen a good pitch for it that addresses anything we're interested in.
Erlang's big thing seems to be that it scales. We don't have that as a major problem for our programming. If we did, I imagine I'd be interested in quantitative comparisons with other programming languages for similarly advanced code, (i.e. I wouldn't want to read some ungodly shitfest alongside decent code as the argument that Erlang was better.)
To be convinced from that perspective, I'd have to:
A) Know ahead of time that we were going to be in a position where we'd need that sort of optimisation
B) Know, or strongly suspect, that we wouldn't have to expend more effort learning Erlang than we would optimising it to 'good enough' performance in another language.
C) Be assured that I'd be able to hire sufficiently intelligent programmers who knew, or were willing to learn, Erlang to maintain things if I set up in it.
That seems a rather niche position to be in requiring both a very strong pitch for that advantage on the part of Erlang, and a significant degree of foresight on my part. If it takes six months to a year to gear up for starting a decent Erlang solution, we'd best be expecting to do massive systems engineering fairly frequently as compared to writing the solution in something that we know right now for that to pay off.
People may say that it's trivial to implement what's missing in Erlang, as compared to the systems side of things that's missing in some already known language. That may be true, I don't pretend to know enough about it to comment on it. However, even if it's so, is it sufficiently harder to implement something that scales out to the required efficiency in Known-Language-X than it is to learn Erlang to that level? Especially given that there's probably already community support for scaling in Known-Language-X.
#
It does seem to have some other nice features. But from that perspective - and this was my first response on dipping into Learn You... I look at it and think 'This looks kinda like Haskell. Why not use Haskell?' or, as the case may be, 'Why not Lisp?' Both of which I've some experience with and would be easier to find good programmers for.
In that regard Erlang is competing with some damn powerful languages.
---------------
Well, I guess only the first part of that is true now. :p
But yeah: Why not Erlang?
I haven't seen a good pitch for it that addresses anything we're interested in.
Erlang's big thing seems to be that it scales. We don't have that as a major problem for our programming. If we did, I imagine I'd be interested in quantitative comparisons with other programming languages for similarly advanced code, (i.e. I wouldn't want to read some ungodly shitfest alongside decent code as the argument that Erlang was better.)
To be convinced from that perspective, I'd have to:
A) Know ahead of time that we were going to be in a position where we'd need that sort of optimisation
B) Know, or strongly suspect, that we wouldn't have to expend more effort learning Erlang than we would optimising it to 'good enough' performance in another language.
C) Be assured that I'd be able to hire sufficiently intelligent programmers who knew, or were willing to learn, Erlang to maintain things if I set up in it.
That seems a rather niche position to be in requiring both a very strong pitch for that advantage on the part of Erlang, and a significant degree of foresight on my part. If it takes six months to a year to gear up for starting a decent Erlang solution, we'd best be expecting to do massive systems engineering fairly frequently as compared to writing the solution in something that we know right now for that to pay off.
People may say that it's trivial to implement what's missing in Erlang, as compared to the systems side of things that's missing in some already known language. That may be true, I don't pretend to know enough about it to comment on it. However, even if it's so, is it sufficiently harder to implement something that scales out to the required efficiency in Known-Language-X than it is to learn Erlang to that level? Especially given that there's probably already community support for scaling in Known-Language-X.
#
It does seem to have some other nice features. But from that perspective - and this was my first response on dipping into Learn You... I look at it and think 'This looks kinda like Haskell. Why not use Haskell?' or, as the case may be, 'Why not Lisp?' Both of which I've some experience with and would be easier to find good programmers for.
In that regard Erlang is competing with some damn powerful languages.
Didn't understand how to use dializer. Situation seems to have improved since I tried last time, because of learnyousomeerlang.
haven't used it. but I recall reading a lot of "I tried erlang with its promises of immense concurrency and my program runs like crap!" "That's just because you're doing it wrong" (discussion of highly esoteric details one needs to deeply understand ensues). Made me much less curious about it.
Elixir, aka "Ruby on Erlang" ;)
http://elixir-lang.org/
http://elixir-lang.org/
Scala and Clojure were designed to succeed Java for all the types of problems that people typically use Java for.
Don't forget RabbitMQ. It must be one of the most widely deployed Erlang applications, surely?
All your thoughts most gratefully received - the internal debate is pointless and fruitless.
> * FP is trés, trés à la mode
That is spelt "très", not "trés".
That is spelt "très", not "trés".
Erlang is dark magic. Not intended for the faint of heart.
I, for one, it's 90% about the syntax.
Erlang is not available as PaaS and it is missing a good editor. Solve those issues and it will take off.
No strings :P
So, it's probably not any sort of technological issue--I'm pretty impressed by the tech behind Erlang.
It's the language (somewhat Prolog-ish) that is weird and uncomfortable to people new to it. Elixir helps with this, but still, every time I've tried to pick up Erlang I've rapidly been turned off.
It's the community--rather, the lack of one. Right now the product I'm working on pretty much plays directly to the strongpoints of Erlang: high-availability, high-scalability, soft-realtime performance, and straightforward error handling. Should be an obvious play.
But, I can't find Erlang developers where I live--which is funny, because at least one company with a good exit in town is an Erlang shop.
Maybe we'd be better off trying to open a branch somewhere in Europe to poach ex Ericcson folks. :(
EDIT:
More thoughts.
Prototyping is just a hell of a lot faster in JS/Ruby than in Erlang, though this could be a side-effect of it being a lower-level language more suited to infrastructure stuff. Then again, I've seen at least one 3D modeling package written in it ( Wings3D ).
Maybe that's part of the problem: just what the hell is Erlang good for? I see it used for really hardcore systems stuff, but it also seems to want to serve web pages, and draw 3D objects, and orchestrate builds, and all these other things. It doesn't seem to have a clean focus in the public eye right now.
It's the language (somewhat Prolog-ish) that is weird and uncomfortable to people new to it. Elixir helps with this, but still, every time I've tried to pick up Erlang I've rapidly been turned off.
It's the community--rather, the lack of one. Right now the product I'm working on pretty much plays directly to the strongpoints of Erlang: high-availability, high-scalability, soft-realtime performance, and straightforward error handling. Should be an obvious play.
But, I can't find Erlang developers where I live--which is funny, because at least one company with a good exit in town is an Erlang shop.
Maybe we'd be better off trying to open a branch somewhere in Europe to poach ex Ericcson folks. :(
EDIT:
More thoughts.
Prototyping is just a hell of a lot faster in JS/Ruby than in Erlang, though this could be a side-effect of it being a lower-level language more suited to infrastructure stuff. Then again, I've seen at least one 3D modeling package written in it ( Wings3D ).
Maybe that's part of the problem: just what the hell is Erlang good for? I see it used for really hardcore systems stuff, but it also seems to want to serve web pages, and draw 3D objects, and orchestrate builds, and all these other things. It doesn't seem to have a clean focus in the public eye right now.
I have "tried it & stopped". I only tried it to check out webmachine, which appears to the be only web framework in existence that is not stupid and terrible. I stopped because I was done trying webmachine, and went back to my normal language that is much nicer than erlang (haskell).
I don't think my experience with erlang has anything to do with the reasons it isn't more popular though. The biggest thing I see is the lack of module/library/package management. CPAN was a big deal. It is now expected that every language have their own CPAN. I think the lack of one is a huge problem for any language, erlang being a good example. I think it is also a big reason that ocaml and haskell went from being "ocaml is the more commonly used one" to "haskell has ten times the userbase of ocaml".
I don't think my experience with erlang has anything to do with the reasons it isn't more popular though. The biggest thing I see is the lack of module/library/package management. CPAN was a big deal. It is now expected that every language have their own CPAN. I think the lack of one is a huge problem for any language, erlang being a good example. I think it is also a big reason that ocaml and haskell went from being "ocaml is the more commonly used one" to "haskell has ten times the userbase of ocaml".
I agree. For instance, Common Lisp is much nicer for me to use now that we have Quicklisp. You can start playing with any common library with a single REPL call.
Erlang is dogmatically functional and smells of prolog. Most people don't know what to do with it.
I love reading all these posts about new cool-kid concurrent languages when Erlang has decades of maturity and a sophisticated scheduler that kicks the shit out of go/rust/scala/insert cool new thing.
Source: I've used it professionally and its my language of choice
I love reading all these posts about new cool-kid concurrent languages when Erlang has decades of maturity and a sophisticated scheduler that kicks the shit out of go/rust/scala/insert cool new thing.
Source: I've used it professionally and its my language of choice
The problem with Erlang is the syntax.
Elixir is the solution.
Elixir is the solution.
Just my hypothetical answer: Erlang isn't popular because it's kind of a shorthand for Error Language (Erlang).
The name is too easily confused with Uhhh Lang ?
The Erlang community is the last place with insight into why Erlang is not popular.
So lets ask people NOT in the community. Here is a list of hypotheses.
Erlang is not more successful because:
* OTP means Open Telephony Platform
* Erlang/OTP is run by Ericsson
* the syntax is prolog-y & not c-y or ruby-y or python-y, its just too damn erlang-y
* no package manager
* no list of open source packages
* no community site
* the mailing list is the community
* everyone knows each other from Stockholm
* it is too hard to get a first working app
* lists for strings, aargh!
* no for loops, eek!
* variables don't vary, whimper!
* people don't learn OTP first but start with Erlang
* people don't learn Erlang first but start with OTP
* no docs
* too many docs but it is the wrong sort
* not enough teaching materials
* doesn't run on the JVM
* we used to think that it was because there were no books...
* Erlang Solutions isn't a proper internet company
* the language develops too slowly
* emacs is the IDE
Some things people are pinning their hats on:
* more books, yay!
* WhatsApp!
* Elixir is irresistable to Rubyists
* LuvvieScript will prove irresistable to the JSers (disclaimer, I'm lying)
* FP is trés, trés à la mode
* LFE & Joxa will be the little lisps that can...
* something will turn up
* something better turn up
* oh God, get me another drink, even at Stockholm prices, I'll be here when something turns up, but by God, a feed of strong drink is the only way to endure the wait
It would be helpful if you would say if you have:
* never used Erlang nor considered it
* tried it & stopped
* use it regularly
So fire away. Do your worst. Hold nothing back.