Short version:
How? We had a intern build it.
Why? Intern didn't know erlang.
How And Why We Switched from Erlang to Python (2011)
11–20 of 150 posts
Re: How And Why We Switched from Erlang to Python (2011)
#12> No one on our team is an Erlang expert, and we have had trouble debugging downtime and performance problems. So, we decided to rewrite it in Python, the de-facto language at Mixpanel.
So they have changed the language to suit the programmers instead of changing programmers to suit the language.
Re: How And Why We Switched from Erlang to Python (2011)
#131. This article was written in 2011 (it's 8 years old). I was confused why they were going with eventlet, but the age of the article explains why. 2. Even for 2011, 1k rps with an average latency of 100ms seems laughably bad. I have to be missing something here.
[deleted]
Re: How And Why We Switched from Erlang to Python (2011)
#141. This article was written in 2011 (it's 8 years old). I was confused why they were going with eventlet, but the age of the article explains why. 2. Even for 2011, 1k rps with an average latency of 100ms seems laughably bad. I have to be missing something here.
When you write Python you already know you're throwing the performance out of the window. In fact based on my experience those numbers are pretty good.
Re: How And Why We Switched from Erlang to Python (2011)
#15> No one on our team is an Erlang expert, and we have had trouble debugging downtime and performance problems. So, we decided to rewrite it in Python, the de-facto language at Mixpanel. So they have changed the language to suit the programmers instead of changing programmers to suit the language.
A very reasonable thing to do.
Re: How And Why We Switched from Erlang to Python (2011)
#16Sometimes using the right tool for the right job also means making sure you have people who can use said tool.
Or, part of the job that the tool has to be right for is the team, which can be as much a part of the job definition as the output.
OTOH, if there is strong reason to think the tool is otherwise correct, finding resources to. enable the team to gain and/or borrow the knowledge they are currently lacking should be practical.
Re: How And Why We Switched from Erlang to Python (2011)
#17Them not being able to utilize Erlang well seems to be the gist of the article. The rest seems like a post-hoc rationalization. It's fair to switch away from a technology your team doesn't know well and doesn't want to learn. Maybe that should have been the title.
Long time, Dimi..
It's a favorite pet peeve of mine too that people often try to rationalize either their lack of experience with a platform or a broken architecture as a problem with the language in question. Though sometimes it's done because it helps paper over internal politics (e.g. lack of clout to be perceived to criticize past decisions) by blaming something external like a language or framework to justify architectural changes, so it's not always that these teams don't know what the actual problem is.
(Twitter's transition from Rails back in the day, always springs to mind as my goto example of this, because as much as the transition might well have been appropriate, as much as they claimed otherwise, the real problem was never Rails, but the fact they'd written a monolith instead of building a system where the message delivery was designed to be sharded; no language or framework choice could have saved them from a rewrite)
Re: How And Why We Switched from Erlang to Python (2011)
#18In some fairness to the writer, Erlang has improved a lot since 2011.
I'm a big fan of the Erlang platform, and I even kind of begrudgingly love the language, but Erlang didn't even have first-class immutable maps until 2015, and while I actually think the semi-prolog pattern-matching syntax is elegant and beautiful once you get a handle on it, I actually really dislike the whole comma-semicolon-period thing. (Personally, nowadays when I say I'm writing "Erlang", I'm actually writing LFE).
Also, the best webserver for Erlang is Cowboy (at least in my opinion), and the initial commit for that wasn't until 2011, and it wasn't really an awesome server until around ~2014. I'm not overly familiar with the Python ecosystem, but if I were to guess, the server frameworks probably were more mature than a lot of the Erlang ones.
I don't fully agree that it's difficult to benchmark Erlang, since it has a lot of awesome diagnostic tools available out of the box and moreover it even has stuff like caching and whatnot built-in with ETS, so I think that argument comes down to "we didn't really know what we're doing", but, you know, that's a valid enough reason to not use a platform if your job is to get something done. I wouldn't recommend most people write their new apps in Idris or Coq either, for no other reason than it is difficult to fully pick up and use those platforms easily.
Re: How And Why We Switched from Erlang to Python (2011)
#19> No one on our team is an Erlang expert, and we have had trouble debugging downtime and performance problems. So, we decided to rewrite it in Python, the de-facto language at Mixpanel. So they have changed the language to suit the programmers instead of changing programmers to suit the language.
A very reasonable thing to do.
Kind of a silly thing to even write about, though. The title makes it seem like the reason had something to do with the two languages, not that the developers knew one language and not the other.
Re: How And Why We Switched from Erlang to Python (2011)
#201. This article was written in 2011 (it's 8 years old). I was confused why they were going with eventlet, but the age of the article explains why. 2. Even for 2011, 1k rps with an average latency of 100ms seems laughably bad. I have to be missing something here.
When you write Python you already know you're throwing the performance out of the window. In fact based on my experience those numbers are pretty good.
It's trivial to get 1kr/s with the simplest of wsgi flask behind nginx without touching anything. But these "comparisons" are meaningless without asking what "serving the request" is about.