Hacker News Reader

Comment by mhd | Hacker News Reader

I might get flamed/downvoted for this, but where's the content of this article? Apart from some vague tropes ("Erlang is bad at string processing!" "We need scalability, and that means async Python", "Pick the right Python libraries!"), there's really nothing interesting about the implementation details, especially considering such a attention-grabbing headline (to put it nicely).

What specifically was bad about the Erlang code? Isn't this just saying that if nobody in your company really understands a language, don't use it?

This is more about the technical competency of a specific company than general technical issues. Or, to put it bluntly, it's more "Mixpanel sucks at Erlang" than "Erlang sucks". Don't get me wrong, I'd be really, really interested in a good analysis why in this case Erlang was the wrong choice, but this article didn't even get close to anything technically interesting (Even with the ubiquitous requests/s graph).

View on HN

The thing I learned from the article is that they return 0 for failure and 1 for success. And then, instead of fixing this meaningfully, they added a bit of sticky plaster that enables you to ask for verbose info when you get a 0.

I can't help but think when I spot such code smells that perhaps the issue runs deeper. So when I then read about Erlang vs Python I also can't but think that I bet it's not the language choice that is the problem.

I don't think I fully understood that I judge code at first sight like that, but I clearly do.

Author of the post here. I agree that 0 and 1 aren't the best choices for a response, but you have to keep backwards compatability in mind. We wanted this change to be transparent to people who have production code that interacts with the API, so it wasn't the appropriate time to change that. On the other hand, for people developing future APIs, we've added extra feedback in a way that doesn't affect other customers' code. I agree that it's not the best solution, but you have to make these kinds of compromises when you have real customers.

Yes, that's a very odd thing to do. More so when you have a better model -- HTTP response codes -- right in front of you!

HTTP response codes don't cover all errors though. They're good at describing problems with HTTP communication, but aren't adequate for describing non-HTTP application errors.

Additional error indicators are fine (much better than overloading the meaning of HTTP codes), but they should be sane, meaningful, consistent with developer expectations, etc. It's that part where the implementation is weird.

I looked at their site and saw they're hiring. Being a problem solver I tend to think "I can fix your problems, let me help", so I looked to see if they need an architect or chief scientist or something... but when the architect position ( http://mixpanel.theresumator.com/apply/Eoh3qJ/Solutions-Arch... ) has the minimum experience of "Student (College)"... I just face palm and am not surprised by any of this - I bet their definition of solutions architect is really just sales support.

I think they just need to raise the calibre of their backend, the signals here (this article, the error codes, the job advert) are not things that inspire confidence in the product. As the main thing that they do is crunching data I'm taken aback that even their backend engineer position advert ( http://mixpanel.theresumator.com/apply/CiOzuu/Software-Engin... ) doesn't even have the word algorithm in it, but maybe they have a wizard who does that for them.

Am I being harsh? Probably... I don't know the guys there and I may just have a very narrow reading of too little info to make such assumptions, so to be a bit balanced (I'm British, it's what we do), they clearly "get" reporting needs.

Their interfaces are show that they understand the kind of thing people want to see. I was impressed by those, I've done reporting a lot, and so many times you see reports that forget that the reader is trying to understand something. So it's refreshing to see reports that appear to remember that.

I usually return Bad Request with an explanation/verbose error in the body, for errors which don't fall under the other codes. It works pretty well.

Doesn't Bad Request usually mean malformed HTTP request data? I find myself using Forbidden when users send me bogus/invalid data, as its a more generic 'No', and a body with more information never hurts.

It does, but I consider it more of an indicator that the request (including its content) was somehow invalid. I reserve Forbidden for cases where the client needs to authenticate.

EDIT: Actually, I see that the spec says that authentication should do nothing to fix a Forbidden error, so you might be right. Unauthorized is for authentication.

Perhaps this is what buro9 means about overloading error codes, but the rest map so cleanly on the errors that it's hard to ignore them. You can't very well return 200 and say "There was error X" in the response.

Maybe we should use 418?

If in doubt, I'm a Teapot serves well ;)

What's the HTTP error code for "ambiguous input, please select from one of the following unambiguous suggestions"?

Just returning an error isn't helpful, you want to help them resolve it. So you want to return something, and this isn't success (in an application sense) as you didn't do what they asked of you, you're doing something else. But it IS success in HTTP terms, the request made it to the server, got processed fine, and came back fine.

Application codes != HTTP codes.

It's debatable whether the application is entirely separate from the RPC layer. For example, when writing a RESTful API, would you really want the server to respond with 200 for everything, even for "Resource not found" errors?

In web applications, HTTP codes and application codes are quite integrated. Of course, you do need some extra error info, as HTTP error codes can't possibly cover every error in your app, but 422 with extra info as a catch-all sounds like a reasonable compromise.

I follow Rails example and use 422 (Unprocessable Entity - The request was well-formed but was unable to be followed due to semantic errors).

Ah, that sounds perfect, actually. Thank you.

I agree with you. The most important lesson I got from this post is that you'll get a bunch of hits if you choose a provocative title.

There isn't even a comparison on the graph between Erlang and Python versions!

I think it did make a technically interesting point--if your infrastructure is written in a language that nobody in your team has mastered, it might be worth the investment to port it to something else.

Erlang is widely regarded as a great platform for servers with lots of concurrent connections because threads are so lightweight (Facebook chat is built on Erlang). And yet Mixpanel decided to rewrite in a language that would be more maintainable for them in the future.

Yeah, I don't think anyone disagrees with you. It's just that this point was rather hidden beneath a misleading title and content!

I don't think the title is misleading at all. "How and Why We Switched from Erlang to Python".

How - by writing a WSGI app that uses gevent and simplejson Why - because the Erlang code was old, no one knew Erlang well enough to maintain, and Python is the language used everywhere else at Mixpanel

The title wasn't "OMG PYTHON RULEZ ERLANG SUCKZ!!". The only real ambiguity in the title was that Mixpanel (as a whole codebase) didn't switch from Erlang to Python, just a small module switched.

What did you expect with this title? More language criticism?

On second reading, you're right. I'm now trying to decide if I should delete by original comment.

I agree with you, for what it's worth.

I just hope you're not suggestion the author should never have written it - not every blog post needs to be a dazzler. I'll assume you're angry about the upvotes instead.

Reply on news.ycombinator.com