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

31–40 of 150 posts

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

#31

Post by hn_throwaway_99 »

robertAngst wrote: post #23
vidarh wrote: post #17

Earlier quoted context omitted.

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…

> 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 limitations that definitely seem awkward if you're coming from a relational DB world (e.g. no joins, limits on the kinds of inequality queries you can do, etc.), but these limitations are there specifically so Datastore can guarantee performant distributed queries.

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

#32

Post by njharman »

robertAngst wrote: post #23
vidarh wrote: post #17

Earlier quoted context omitted.

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…

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

Yes erlang does. Unless you try hard and work against the language erlang systems are written differently than ruby/rails program.

I used "system" and "program" there specifically. One of the key things erlang "forces".

Languages do matter.

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

#33

Post by oconnor663 »

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…

I think Facebook chat had a very similar experience. The first version was written by someone who liked Erlang. Later on, when some performance issues came up (probably related to GC), no one knew Erlang, and all the high performance backend code in the company was in C++. So it made sense to rewrite the thing.

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

#35

Post by _RPM »

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?

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

#36

Post by [deleted] »

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…

[deleted]

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

#37

Post by bonif »

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…

Thanks for this comment, gives context and explains "why we switched from X to Y", answer: I did not know X, or it didn't make sense at the time. It does not mean X is bad, or Y > X (as usually suggested in this kind of articles)

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

#38

Post by exelius »

_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?

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 found someone you probably want to hire. If not, they don’t get an offer. Either way you probably didn’t pay them much to begin with so there’s a lot of upside and not much downside.

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

#40

Post by tombert »

rrix2 wrote: post #21
tombert wrote: post #18

In 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. (Person…

Are you writing LFE in your professional capacity? I've always been curious if LFE was more than a sort of toy language, it's hard to tell from outside the community. I've been becoming more and more enticed to learn Elixir (and Phoenix) and the BEAM, and LFE would be a nice thing to add to the tool belt.

Alas, no, I do not get to do Erlang in any kind of professional capacity now, and haven't since 2015.

That said, I do use LFE for a lot of personal projects. I don't mind it being niche-ish largely because Virding wrote it to be a very thin wrapper around vanilla Erlang, so as a result there's not a lot to mess up. With the exception of macros, there's really not many changes to the semantics from regular Erlang, meaning that the transformation to and from LFE is trivial. LFE mostly exists to keep the syntax consistent and cleaner, and while the language is kind of toy-ish, it almost doesn't matter.

Honestly, I'd be a lot more worried for something like Joxa or Clojerl, not because they aren't awesome projects (they are), but they don't have as direct of mappings to the BEAM semantics.

Also, Virding is very active on the #lfe Erlangers Slack, so typically when I have a question, it is resolved pretty quickly.

Post reply on HN