Why Erlang matters
petrohi.me
petrohi.me
- Syntax is the easiest part of learning a language. It's all written down and its just a RTFM. And yes, I have written a lot of C and lisp and prolog and erlang and ... and I never have problems with the syntax.
- If people worry so much about the syntax what happens when they get to the semantics?
- Seriously, why would you want to Erlang to have similar syntax to a language with different semantics? In my view that would be asking for trouble. I think one reason why I haven't had trouble with mixing languages is that both the syntax and the semantics are different. C looks like and behaves like C while Erlang looks like and behaves like Erlang.
- The erlang syntax is actually very simple, much simpler than the languages you would like it to look like.
I will now stop before I say something nasty.
I liked the blog.
Glad you liked the blog.
If it is not that popular (which is rather good) it is not a language's fault. It is due to inability to acquire and maintain an appropriate mindset.
btw, there is a nice lecture - http://www.youtube.com/results?search_query=Erlang%2BJoe%2BA...
Are you implying that creators of Node and Java are stupid and lack passion? It seems like you are... And it's a) not relevant here at all; b) simply not true.
> It is due to inability to acquire and maintain an appropriate mindset.
It's debatable, but I tend to agree here.
Not popular often means you have to write libraries or code yourself that in a more popular language would already be sitting around ready to use. In other words, in a business context, it might cost you more money to use a less popular language.
> it is not a language's fault
I don't agree. I think for instance that Erlang could likely have a more C like syntax, and that would have bought it more users. There's plenty of other stuff that you can do to make a learning curve relatively easy, so that people can slowly start out and get to know a language.
Of course there are factors beyond the control of a language's designers and proponents, but looking at things like PHP and Ruby, you can certainly get popular without, say, having huge corporate backing.
This reminded me about famous Linus rant against C++ - in the same vein it can be argued that "cryptic" (actually very readable and consistent IMHO) syntax would be a win even if it did nothing more than keep C (style) programmers out of Erlang development :)
You're certainly right from business perspective, however.
That "common nonsense" you speak of (aka Java) runs on billions of devices and handles trillions in revenue. Erlang keeps legacy phone switches running. It's like people who say X language is amazing and lament the crap that is English.
Who cares?
English runs the world economy.
In what sense? Why do I have to paste this link: http://www.paulgraham.com/avg.html here of all places?
Don't take my word for it, ask a famous Lisper: http://en.wikipedia.org/wiki/Worse_is_Better
Also, I'm afraid Java is a perfect counterexample for "worse is better". It does everything and then some, but there are better (like, worse - less complicated, easier to use, more focused) solutions for almost everything Java does... And Java is still insanely popular.
Lastly, you seem to want to equate popularity with quality, and then you give Linux as an example. Surely, Windows is better because it's installed on many more PCs than Linux?
Java does that. Linux does that. Windows does that. Lisp doesn't.
And note - your article wasn't written by the author - it was written by someone else.
You're entitled to your own definition of words, in this case you defined "worse" (and this definition is very popular, too!) and it's ok. My perspective is different and so my definition is - I don't care about "average people" at all, I like very much "mental contortions" and I enjoy making more than shipping, and so "worse" for me means something different altogether.
I just wanted to what you meant by "worse", really. I won't agree with you here, but I understand and accept your opinion.
I edited my previous post in reply to your note at the end.
There are limits of course, and always complexity, but distributed incentive based systems appear to empirically work rather well.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" -stroustrup
If you have to write about how your language matters, you have already missed the point. If it mattered, people would be using it.
[1] http://www.erlang-factory.com/upload/presentations/31/Eugene...
[2] http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2...
"Erlang matters today because it demonstrates how these semantics can be elegantly packaged in one language, execution model and virtual machine." I think yes, in a theoretical sense this is absolutely true. The question is why is it not a language in widespread practical use?
1. It kind of is, I think RabbitMQ, CouchDB and Riak are doing ok, for example.
2. Both syntax and semantics are sufficiently different from "industry standard" to be a hurdle for majority of people... I'm being told. I don't understand this; the more different the language is the more interesting it seems to me and the more happy I am to learn it[1], but I heard this argument enough times to accept it as (sad) reality.
[1] And there is still so many of them to learn! Take a look at any one RosettaCode page (http://rosettacode.org/wiki/Y_combinator) if you don't believe me :)
And scalaris [1]. For me it's killer app for Erlang.
CouchDB is more C++ than Erlang these days, bad example. It hasn't been mostly Erlang for a really long time. Erlang basically only does the clustering behavior, which is something Zookeeper et al. do already.
Riak is the only solid example out of those you listed, and its known for having poor raw performance, excellent availability, easy clustering, and awful usability.
Interesting, where can I learn more about this claim? What are the incompatible facets of a generic queue and Erlang? What is an example of these generic queues (or if it's only an ideal, what are its characteristics)?
If the queue gets badly backed up, you're probably fucked.
Larger, longer-lived work queues are really more of a Hadoop thing, not an in-memory queue thing.
Where the first answer states that: "RabbitMQ presumes that consumers are mostly online, and any messages "in wait" (persistent or not) are held opaquely (i.e. no cursor). RabbitMQ pre-2.0 (2010) would fall over if your consumers were too slow, but now it's robust for online and batch consumers - but clearly large amounts of persistent messages sitting in the broker was not the main design case for AMQP in general."
(It's contrasted with Kafka, which is "designed for holding and distributing large volumes of messages")
Still, I see no reason why you say that it's Erlang that causes this?
You can implement a queue that works better for batch work in Erlang, it's just that it'd be closer to a data store.
Isn't that true of any queue ?
[1] Or at least Joe Armstrong says so in his book, "Programming Erlang".
Can you point to any references?
Things are much easier now with line numbers in error messages though.
But since Jose Valim is probably my favorite developer alive, I have faith that Elixir will do for Erlang what Rails did for Ruby.
I know it sounds like I'm comparing Rails (a framework) to Elixir (a language), but what I am comparing is a way of bridging-in Joe/Jane Developer.
Anyway, just giving a shout out to Erlang as I am finding the platform to be very interesting and that makes the day go by much better.
Can you share what type of application you will be working on?
Why, why syntax does have to matter? I thought it matters too, at first, but after sixth or so language I noticed the feeling of importance of syntax vanishing. Now I find good support in my editor much more important than syntax.
(Edit: and "you don't need editor support if you have good syntax" doesn't seem true to me either)
The paradox of Erlang is that the sorts of environments it's used in and that initially supported its development are often fairly conservative, so the features and choices it started out with are not easy to get rid of. This means the language is saddled with some ugly warts.
It's really good at what it does and is definitely worth a look, but I agree that sooner or later someone is going to come along and steal lots of the good parts and add them to a more modern language.
Erlang is using the actor model and so is Akka.
I really want to learn one or the other as a goto functional language.
I keep looking at sites like Netflix, Twitter and Foursquare. Those seem to be sites running on either Java or Scala.
Why would they pick that instead of Erlang?
Depends why you picked Erlang. Erlang has unsurpassed fault tolerance built in. This mean ability to crash and restart individual processes, ability to hot code reloading. Its standard library by default comes with such things as a distributed application controller that will make sure you application will immediately start running on another machine if it crashes locally.
I don't know of any other languages or platforms that provide that as a first class.
Then for things Erlang would be used you really would want something battle tested. Eventually Akka will be battle tested and this won't be an issue but I think it is not there yet.
I picked Erlang or Scala/Akka because both of them seem to have reasonable support for web libs and are based around distributed concurrency.
Erlang was a choice because it seems to run really well on medium-tier hardware. What can be served with a single Erlang server might take 10 Python servers, etc..
I haven't seen any Akka benches but if huge crazy scale web sites are serving everything with Scala then I have to assume it's speedy.
I also want to dabble in the idea of creating 2D games and I know Erlang's math computation speed isn't very good but Java's (and that means Scala too) is very reasonable.
It would be nice to just learn Scala and use that for the core game engine (not 3D) logic / collision detection on the server side. I think with Erlang you would have to end up writing the game stuff in C to get reasonable performance?
The actor model isn't the only aspect that gives Erlang its robustness. In fact, far more important is its supervisory model, which goes as deep as you want it and can supervise across system boundaries.
I keep waiting for the language that learns these lessons from Erlang with a happier syntax, but I have yet to find it.
I know Java has "pauseless" garbage collector but I think that is just marketing talk. Given how references to objects can be shared between threads I don't see a way for it to work.
The problem occurs when you try to translate the Erlang syntax to the language of your choice, which isn't the right approach. C, and Java don't use pattern matching, so naturally their syntax is not designed for it.
Maybe one should write a small program to demonstrate the key functionalities of Erlang, like write a TCP packet decoder etc, then try doing the same in your prefereed language and then see what makes sense.
Immutable message transmission has no way to say "I already know about this message; don't send it again."
Most of the good characteristics of Erlang that you describe are achievable in other languages.
So what I'm asking is, by what concrete mechanism does immutable message passing outperform cache coherence?
We can always drop down to C or asm to make ultra-shared data structures with minimal overhead. We could always do that. But people end up wanting to spend their precious lives making a difference in the world and not checking the return value of malloc thirty times per day.
So true!
I'm not sure Cloud Haskell is ready to dethrone Erlang (and the OTP framework, and tooling for debugging distributed processes, and special VM features, ...) for high-reliability distributed computing today, but Haskell and its libraries are evolving with absurd speed and the Cloud Haskell ecosystem could certainly be competitive with Erlang in the near future. Haskell can certainly be used to write high-performance network applications (e.g., Mighttpd, Warp), so it's surely only a matter of time ...
But, they should change its name so that it sounds like a library and not another language dilect. :)
Judging by its name, I thought that its a new haskell dilect ;)
My impression is that Haskell implementations are more used as research tools and there is less control of what goes in and how it is to be supported.
In that sense it would be safer to build a product on top of Erlang.
That is just my impression and I could be wrong.