1. The server for the company's core product is written in Erlang, but no one at the company is an Erlang expert?
2. The company decides to rewrite the core of its product in python, and gives the job to an intern?
I feel like I must be missing something....
In the case of FB, as told to me, a bunch of folks in the valley said "of course we know Erlang!" and built the app but when push came to shove the only hardcore Erlang guys were in Poland and that made working on chat difficult. I'm not sure how much of that is truth, but its a recurring theme in Erlang projects, one that I've personally heard time and again.
For some reason, Erlang inspires confidence, perhaps even foolhardiness.
Side note: I work at an Erlang shop and our lead engineers speak at Erlang Factory every year. It's a great language and quite powerful but it can be difficult to understand.
Erlang is a great fit for a number of problem domains, but if you silo it into a small part of your organization, you're going to run into issues such as these. You have to be willing to train people in it. It isn't that hard to pick up if it's someone's full time job to do so, as long as they're smart. And you want to hire smart people anyway, right?
Maybe this time they'll do it in Go.
My sneaking suspicion is that, in some cases, people pick it because they read that it's "web scale" or something like that without really knowing the details, and when things fall apart, they revert to something that they know better.
BTW, reference for the FB chat thing being rewritten?
On the note of Erlang's complexity, it's not so much complex as it is different. I think all languages get hard at scale, Erlang just has some nice native concurrent processing capabilities that are making more sense with each passing day as we move towards more cores in processors. It's easier to Parallelize Erlang than say C++ for example.
The api server was one of the very first things written, back when Mixpanel was a fun side project for some college kids, well before YC. We picked erlang because it sounded cool.
It was actually pretty stable, but the only piece of erlang in our stack. Replacing it was one of those important but nonurgent things that are hard to prioritize.
We want interns to have meaningful work, though, and "important + nonurgent" is just about the ideal thing for an intern to work on. They get to work on something interesting, but there's plenty of time for review and refactoring.
In addition to the statement that they had no Erlang experts currently on staff, it sounds like the people who wrote the system were not Erlang experts either. I wonder if they used OTP to build the system? The post doesn't say, but I'd bet they wrote a lot of their code with erlang's message passing primitives, if they were using messaging at all. This will get hairy and that's why most people should use OTP to build server applications in Erlang.
Lesson learned: you build better systems using languages and frameworks you know vs. using something trendy that you don't understand.
With that said, comparing Python and Erlang on the basis of performance is a bit like looking for the world's tallest midget isn't it? Performance isn't the point at all, within a certain threshold.
film @ 11...
Hm, I wonder if they tried to train someone or if they waited to see if someone would study Erlang at home for free.
I read the title, ( sounds familiar ), look at domain mixpanel.com, didn't they did these a while ago?
Turns out to be same post from 2011.
Come on! Stop posting the same thing over and over again.
Why Erlang community couldn't came up with something like Haskell's ByteString? I mean, there is a bit-syntax in Erlang, but with a very limited functionality of what you would expect for string handling.
you _can_ do quiet a bit of string processing in erlang's bytestrings (note: not unicode-aware), see e.g. cowboy (which has nice to read sourcecode).
as to why erlang does not have a haskell-like ByteString, i guess, it's because haskell has very fast (but potentially unsafe) c-bindings. erlang's ports are too slow to use them for something that small-grained. i'm not sure, why no BIFs were introduced to bring somthing similar, honestly.
That's a misleading statement, I think; it's like saying Python was not designed for web application development (which is true but also misleading).
It's more correct to say that Erlang was designed without much thought given to string processing. Erlang was designed as a fairly general-purpose language, only one with non-encoding-aware strings; the real problem is that it hasn't caught up, even though Unicode has existed since 1991 and has long been incorporated into most languages and most software by now.
Instead of adapting, Erlang seems to be stagnating in one area that users are frequently complaining about. In this day and age, I would argue that string processing is quite important for the things that Erlang can, or should, be used for.
Anecdotally, when I first tried Erlang I tried to create a naive, parallel log processor which read lines and spawned off lines to a pool of workers. As a newbie I was quickly stumped because Erlang's file I/O is abysmally designed. I eventually gave up the project, and later I found that Tim Bray, also an Erlang noob, had struggled with the exact same issue . You would think that this is something Erlang would excel at, but apparently it's not.
I have been disappointed with Haskell's string support, too -- it's all over the place (String vs. Text types, the weird Data.Encoding module, horrible regexp library, etc.) -- but at least it's fully Unicode-aware and it has a fast ByteString type.
Erlang is somewhat strange for a language in that it got put to use in some very important critical systems before it got big. Things like Ruby, Tcl and Python slowly got popular and changed along the way. Doing an Erlang 2.0 that improves on some of the warts is probably not so easy...
As for a built-in bstring() type, it is being discussed, but there are other things more important to get into the language, maps for instance. Erlang is rather conservative in the speed with which we add stuff to the language.
Erlang has some of the fastest I/O in a runtime. But it is not easy to use correctly. The same goes for string processing. Erlang can be blinding fast at that, but you must understand how to make it fast.
please please have a record replacement already. There are like a couple of proposals for record replacement.
Then I read: >>No one on our team is an Erlang expert, and we have had trouble debugging downtime and performance problems.<<
Now it is clean. As always: You must know your stuff amd you better be an expert than not.
That being said, I really like Erlang, and I can think of a few problem domains where Erlang would indeed be a really good fit. But serving HTML in my opinion is so trivial that all the fancy stuff that Erlang offers matters little in that regard.
1. Maintainability: Go is ALGOL/C-family-esk and it will be much easier for a Java/C#/Python/<insert very common lang> programmer to ramp up on it than Erlang. Go code is sometimes called boring because it tends to be very straight forward and pragmatic- this makes for very maintainable large systems.
2. Performance: Go performs much better than Python or Erlang[1-3].
Computer Language Benchmarks Game:
1: Go vs Python: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
2: Go vs Erlang: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
TechEmpower: Web Framework Benchmarks:
I'm going to go out on a limb and say that performance is more subtle than can be reduced to a single "is better than" about throughput in HTTP requests or computing mandelbrot fractals in the shootout.
All of the languages have a specific area where they shine. Erlang in largely concurrent systems. Python also has a sizable mindshare in the HPC world.
Sure, and I'd agree with that. But when it comes to empirical data, microbenchmarks are one of the best sources of data we have to look at. The best source will always be your specific application of course. Benchmarks will never be perfect, but they should not be so easily discarded.
>>All of the languages have a specific area where they shine.
Agreed. I do think it is worth pointing out that the Computer Lang. Bench. Game has a wide variety of programs just for the reason you point out, and it gathers both execution time and memory usage data.
>>Erlang in largely concurrent systems.
Very true; however, concurrency is also a strong point of Go.
>>Python also has a sizable mindshare in the HPC world.
While I'm sure this is true, that could be for reasons other than performance. I know some Astronomers that use Python because as non-CS people its easier for them to use than C or Fortan. However, if they have a really expensive program and they bring in someone with formal C-S training to port to C Fortran or Java the resulting improvement is almost always huge.