How And Why We Switched from Erlang to Python (2011) • Hacker News Board

Re: How And Why We Switched from Erlang to Python (2011)

#81

Post by jacquesm » Sun, Apr 28, 2019, 9:15 PM UTC

bradleyjg wrote: post #54

lightcatcher wrote: post #27

I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then My recollection of events (of 8 years ago): The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebas…

In general language diversity at a company is a big negative. Obviously sometimes there are even bigger negatives that mandate overriding that rule--you aren't going to use Java on the front end or javascript on the backend, that would be madness--but you never want two languages in the same niche. That's a cost with no benefit. If you have some developer that wants to write something in a new (for your company) lang…

> or javascript on the backend, that would be madness

It seems madness is pretty common.

Re: How And Why We Switched from Erlang to Python (2011)

#82

Post by robocat » Sun, Apr 28, 2019, 9:26 PM UTC

ajross wrote: post #74

kbutler wrote: post #72

Earlier quoted context omitted.

If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. The point is this was a well-specified, independent component with an existing functional implementation. This makes an ideal intern/temp/first project, because of those factors - it doesn't require deep knowledge of the organization or other services in the environment or busi…

> If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. Yeah, and that logic is almost inherently a violation of labor law. The whole idea behind allowing "internships" at all is that the intern is deriving value (education) from the relationship that isn't captured by wages alone. The test for whether it's legal involves how much…

GP didn't suggest "Handing out throwaway projects", you did: I think you misparsed their comment.

You ask the intern to do work that you want them to succeed at and you think they will succeed at: like the example given.

Re: How And Why We Switched from Erlang to Python (2011)

#83

Post by robocat » Sun, Apr 28, 2019, 9:31 PM UTC

rlander wrote: post #44

lightcatcher wrote: post #27

I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then My recollection of events (of 8 years ago): The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebas…

So, in a Python-only org, someone with no Erlang experience decided to ship his first ever server to production, thinking Erlang would be a magic bullet to “scalability issues”. Obviously, there were maintainability issues and the org, blaming the language, decided to switch back to python. To me, the fact that a novice was able to deploy production code that went on unmaintained for months, running a crucial part of…

"the org, blaming the language".

I didn't see anywhere in the article blaming the language - can you find a quote to support your assertion?

From the article: "After two years of iteration, the code has become difficult to maintain. 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."

Re: How And Why We Switched from Erlang to Python (2011)

#84

Post by exelius » Sun, Apr 28, 2019, 9:43 PM UTC

ajross wrote: post #74

kbutler wrote: post #72

Earlier quoted context omitted.

If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. The point is this was a well-specified, independent component with an existing functional implementation. This makes an ideal intern/temp/first project, because of those factors - it doesn't require deep knowledge of the organization or other services in the environment or busi…

> If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. Yeah, and that logic is almost inherently a violation of labor law. The whole idea behind allowing "internships" at all is that the intern is deriving value (education) from the relationship that isn't captured by wages alone. The test for whether it's legal involves how much…

Most real internships pay under market rate, but not insanely low. A few years back, going rate for an undergrad CS internship was ~$25/hr or so.

If you’re recruiting on campus, you’re competing with other companies for the most promising candidates. If you come in with an unpaid internship, you’re going to get the leftovers.

Re: How And Why We Switched from Erlang to Python (2011)

#85

Post by robocat » Sun, Apr 28, 2019, 9:45 PM UTC

vidarh wrote: post #17

pdimitar wrote: post #8

Them 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 ar…

> 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.

I didn't see anywhere in the article blaming Erlang as a language - it just said Python was better for mixpanel.

From the article: "After two years of iteration, the code has become difficult to maintain. 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."

The impression I got from the article was that they only wanted similar performance (hence intern), and that they got a suitable result.

I think that recently a similar service GetSentry changed their ingress code from Python to rust presumably for performance and security (although I might be utterly incorrect, I can't remember why I think they are using rust).

Re: How And Why We Switched from Erlang to Python (2011)

#86

Post by tomjakubowski » Sun, Apr 28, 2019, 9:51 PM UTC

bradleyjg wrote: post #54

lightcatcher wrote: post #27

I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then My recollection of events (of 8 years ago): The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebas…

In general language diversity at a company is a big negative. Obviously sometimes there are even bigger negatives that mandate overriding that rule--you aren't going to use Java on the front end or javascript on the backend, that would be madness--but you never want two languages in the same niche. That's a cost with no benefit. If you have some developer that wants to write something in a new (for your company) lang…

You could fire them or you could just help them understand something that they don't. Sheesh.

Re: How And Why We Switched from Erlang to Python (2011)

#87

Post by detaro » Sun, Apr 28, 2019, 9:56 PM UTC

bradleyjg wrote: post #54

lightcatcher wrote: post #27

I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then My recollection of events (of 8 years ago): The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebas…

In general language diversity at a company is a big negative. Obviously sometimes there are even bigger negatives that mandate overriding that rule--you aren't going to use Java on the front end or javascript on the backend, that would be madness--but you never want two languages in the same niche. That's a cost with no benefit. If you have some developer that wants to write something in a new (for your company) lang…

> If you have some developer that wants to write something in a new (for your company) language, [...] you probably want to fire that guy.

Now that's

> a cost with no benefit.

Re: How And Why We Switched from Erlang to Python (2011)

#88

Post by Stratoscope » Sun, Apr 28, 2019, 10:03 PM UTC

ajross wrote: post #74

kbutler wrote: post #72

Earlier quoted context omitted.

If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. The point is this was a well-specified, independent component with an existing functional implementation. This makes an ideal intern/temp/first project, because of those factors - it doesn't require deep knowledge of the organization or other services in the environment or busi…

> If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. Yeah, and that logic is almost inherently a violation of labor law. The whole idea behind allowing "internships" at all is that the intern is deriving value (education) from the relationship that isn't captured by wages alone. The test for whether it's legal involves how much…

I think you may be mistaken about this. If it helps any, I wasn't one of your downvoters; I upvote comments that may be incorrect but lead to an interesting and informative discussion.

I live with an HR exec and read some of this thread to her while she was cutting rhubarb for something she's baking.

She said (paraphrased), "Are you kidding? This is a perfect project for a summer intern. They won't have to take three months to get up to speed with all your internal systems, and of course there is educational value - they will get to see how some talented developers tackled the problem in one language while they translate it to another."

Re: How And Why We Switched from Erlang to Python (2011)

#89

Post by detaro » Sun, Apr 28, 2019, 10:12 PM UTC

ajross wrote: post #74

kbutler wrote: post #72

Earlier quoted context omitted.

If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. The point is this was a well-specified, independent component with an existing functional implementation. This makes an ideal intern/temp/first project, because of those factors - it doesn't require deep knowledge of the organization or other services in the environment or busi…

> If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. Yeah, and that logic is almost inherently a violation of labor law. The whole idea behind allowing "internships" at all is that the intern is deriving value (education) from the relationship that isn't captured by wages alone. The test for whether it's legal involves how much…

Is your point of contention the "your code review/acceptance test." as the only time investment?

Re: How And Why We Switched from Erlang to Python (2011)

#90

Post by bradleyjg » Sun, Apr 28, 2019, 10:13 PM UTC

ajross wrote: post #74

kbutler wrote: post #72

Earlier quoted context omitted.

If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. The point is this was a well-specified, independent component with an existing functional implementation. This makes an ideal intern/temp/first project, because of those factors - it doesn't require deep knowledge of the organization or other services in the environment or busi…

> If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test. Yeah, and that logic is almost inherently a violation of labor law. The whole idea behind allowing "internships" at all is that the intern is deriving value (education) from the relationship that isn't captured by wages alone. The test for whether it's legal involves how much…

Even ten years ago, I doubt it was an unpaid internship. They weren’t common in tech going all the way back to dotcom. And if it was a paid internship, labor law doesn’t care. As far as it’s concerned that’s a job like any other.