Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

engineering.mixpanel.com

Post reply on HN
Print view View original

71–80 of 150 posts

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

#71

Post by znpy »

_RPM wrote: post #35
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…

Is it common for an intern to get such an impactful project?

No idea, but that seems like a reasonable choice in that case.

Yes the project was impactful, but there already was a reference implementation with a reference performance target. Worst case scenario, they would have been back to using the old implementation.

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

#72

Post by kbutler »

ajross wrote: post #57
exelius wrote: post #38

Earlier quoted context omitted.

Yeah; it’s actually pretty easy work. Interns have a lot of uncommitted time, and they’re going to leave soon so you don’t want to integrate them into the team too much. It’s also way easier to build to a well-defined spec (which an in-production endpoint would likely have). So you let them rewrite something that already works. If what they build is good, you‘ve just knocked out a good chunk of technical debt and fou…

The question isn't whether or not the work is easy for the intern, it's whether or not it's appropriate. And this cuts both ways: a company that is doing serious core refactoring/redevelopment on the back of an underpaid "intern" is probably exploiting that labor in an unfair way. If it's in fact an unpaid internship, then they're straight up in violation of the Fair Labor Standards Act. And, of course, a company tha…

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 business requirements. You build this, and if we like it, we use it and may give you a job offer.

Unless given other information, you can assume the company complied with the law with respect to paying the intern and the intern accepted the internship offer, and it sounds like he got a great experience out of it.

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

#73

Post by i0exception »

hu3 wrote: post #61
i0exception wrote: post #41

Disclaimer: I work at Mixpanel We have a monorepo and I imported our entire commit history into Mixpanel - https://twitter.com/i0exception/status/1010663994435067904 As you can see, over the last 3 years, we've rewritten large parts of our infrastructure in golang. While we still use python for a lot of things, we felt that the type safety and concurrency primitives in go were a much better fit for writing some of ou…

250k lines of Go in ~3 years, around 1k per weekday is impressive. Adding 1k lines of code per day to a monorepo while keeping the project manageable is no easy feat. Is it split into microservices? Any tips to tame the beast?

We try to avoid microservices wherever possible. If we're adding something new, it typically starts off as part of the service being deployed - either as a container within the pod (we use kubernetes) or as a library that the code can use. If something grows big enough in a way that it can't scale with the service it's running with, we split it into a separate service. The opposite is also true - if a service that we run no longer warrants a separate deployment, we make it a container or a library. We use GRPC for most communication and interfaces for anything that travels package boundaries. Both of these help with making the split/aggregation a lot easier to manage.

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

#74

Post by ajross »

kbutler wrote: post #72
ajross wrote: post #57

Earlier quoted context omitted.

The question isn't whether or not the work is easy for the intern, it's whether or not it's appropriate. And this cuts both ways: a company that is doing serious core refactoring/redevelopment on the back of an underpaid "intern" is probably exploiting that labor in an unfair way. If it's in fact an unpaid internship, then they're straight up in violation of the Fair Labor Standards Act. And, of course, a company tha…

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 they are supervised by the people who are supposed to be teaching them.

Handing out throwaway projects like you posit is an easy trip to a class action suit.

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

#75

Post by StreamBright »

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…

Well, Rails does not have a good track record with scaling. Memory requirements if nothing else will be a big hurdle to come by regardless if you have SOA, in my experience.

Back in the day not many organizations survived on Ruby/Rails and many of them moved over to Erlang or Java just to deal with resource issues.

https://blog.chef.io/2013/02/15/the-making-of-erchef-the-che...

Not sure what is up with Ruby nowadays. JRuby was always an interesting option though.

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

#76

Post by StreamBright »

hn_throwaway_99 wrote: post #31
robertAngst wrote: post #23

Earlier quoted context omitted.

> they'd written a monolith instead of building a system where the message delivery was designed to be sharded; n Do some languages handle this differently? Isnt this based on how the code was written rather than a language natively sharding?

Sharding is basically a data storage concern, so it's not something that the language can really control. There are however, frameworks that enforce some level of "shardability". The Datastore (now Firestore) in AppEngine/Firebase comes to mind, in that your data is shared all over the place (the details are hidden from you), and you can't write un-indexed queries that don't scale well. The Datastore has some limitat…

Absolutely not. While working for Amazon we had to think about a lot how to "shard" our fleets to have the least amount of items in every cache and maintain high hit ratios. If you let all traffic hit a single cluster your cache hit ratios will be terrible and most customers are going to experience worst case latency which is absolutely do not work for popular websites.

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

#77

Post by lightcatcher »

nojvek wrote: post #65
bradleyjg wrote: post #54

Earlier quoted context omitted.

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…

Language diversity is a pragmatic balance. Sometimes a language offers superior abstraction or some guarantees that eliminate a whole host of bugs and manual effort. It’s always worth trying a hypothesis in a small spike and reliably proving whether it will scale to the rest of the org and the impact will be worth the effort. But you’re right, there should be one official supported way of doing some kind of thing at…

I think of it as a trade-off between the tool perfectly designed for the job and the tool that can be used for the job of which I'm already an expert user.

As an example, my current team's codebase is Python and C++. When we need to do some basic Linux scripting (check if this file exists, if not send an error email), the two prime candidates are Bash and Python. Bash might be exactly designed for this type of thing, but a lot of the team would need to Google stuff like "bash logical and of two booleans" for Bash where they already know the Python syntax. My current rule of thumb here is "<10 lines of code: use Bash. else use Python". More generally, I often try to err on the side of using the tool I know than the unknown tool that might be perfect for the problem.

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

#78

Post by StreamBright »

arendtio wrote: post #67
tdumitrescu wrote: post #39

FWIW the server in question is really simple. It has since been ported to Golang, which has become one of Mixpanel's primary languages (alongside Python and JS/TS).

Now this will make the Erlang people happy :D Sometimes I have the impression that functional programmers dislike Go especially for having such an inelegant language design ;-) Personally, I don't have hard feelings for either side: I love Go and like the functional style in general (I know a bit of Scheme). Erlang is one of my top 2 languages I want to learn (together with Rust).

To learn Erlang is not that difficult. I think it is a bit harder to understand how to write production ready sacable OTP code. Btw. you should check out Elixir. It is much easier to get into Elixir nowadays and many aspect (like deployments) are solved while with Erlang you need to do a bit more to get the same results. You can also just toy with Erlang without OTP (not really recommended). :)

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

#79

Post by lightcatcher »

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…

> a company that is doing serious core refactoring/redevelopment on the back of an underpaid "intern" is probably exploiting that labor in an unfair way

> Handing out throwaway projects like you posit is an easy trip to a class action suit.

So if an intern shouldn't do work on the core product but also shouldn't do throwaway projects, what do you suggest an intern should do? What do you consider an "underpaid" intern? Would you consider 75% salary of campus new hire as underpaid?

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

#80

Post by StreamBright »

My problem is with such articles that very rarely I see some in-depth argument with numbers and details to justify the switch. Many engineers are just too lazy to drill down and get to know their stack so that they can scale it up when necessary or add/remove fetaure, fix bugs with reliable veolicty. I have spent some time in California working for startups and the ratio of engineers who know their stack in depth to ones who would switch language because of trends, never really get to know anything in depth is 1:100.
Post reply on HN