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

91–100 of 150 posts

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

#91

Post by [deleted] »

tomjakubowski wrote: post #86
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…

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

[deleted]

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

#92

Post by pdimitar »

StreamBright wrote: post #75
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…

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

I'm not an authoritative source by any stretch but my anecdotal evidence shows many former colleagues getting a Rails fatigue of sorts and moving to other languages. I personally moved on to Elixir but no small amount went back to Python and PHP and some got to JS, Haskell, even OCaml and Rust and Go.

It's really not productive when even minor version bumps of Rails back in the days of v3.2 all the way to v4.2 were a nightmare to execute, often impossible. You were stuck with a ton of quirks for years, likely all the way to your next job.

Rails was productive, but only compared to a ton of other lame half-frameworks at the time. Nowadays it isn't special by any measure.

---

So TL;DR: it doesn't really matter what Ruby or Rails are up to these days. Many people have moved on, the free lunch is over and the hype is gone. Which is a good thing: hype more often than not kills technology and doesn't enable it.

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

#93

Post by Daishiman »

jacquesm wrote: post #81
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…

> or javascript on the backend, that would be madness It seems madness is pretty common.

It is. Mistakes take a far longer time to be understood than fashion.

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

#94

Post by dhab »

Elixir, which runs on the Beam VM, had piqued my interest for a while, so finally set out to learn about it this weekend. On searching for "flaws" of the language and the platform, I (accidentally) ran into: https://www.youtube.com/watch?v=42k70Y-yTYY . (year 2017)

Video description:

  ...What many developers don’t understand is that Erlang is 
  built on an architecture and within ecosystem 
  that contains many subtle security flaws. 
  One such set of flaws allows anyone with the ability to 
  interact with a remote Erlang node to compromise 
  that node by abusing the underlying BEAM Virtual Machine 
  and the services required to run Erlang...
My notes:

* Looks like a deep issue in VM architecture

* It's not detectable at all

* Ericsson was informed 1 year prior to the talk, and their recommendation is to not expose nodes publicly

Speakers argument: Yes, but the threat still exists for another internal project to exploit it

* Speaker's belief: It doesn't look like it is going to be fixed (any time soon)

To me to me this sounds like a very serious issue - to the point that I have crossed off anything on Beam that - I wouldn't build/learn to build on, wouldn't trust (note: didn't say wouldn't use) another software that was built on it.

Overall, it seemed like a great platform that scaled upto a certain point with good guarantees on latency and throughput and resource utlitization. Not to mention, seems like (probably) only one platform that does pre-emptive scheduling. Heartbroken that after being marketed as "battle tested", this aspect of the VM/lang has gone under radar for so long.

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

#95

Post by k__ »

jacquesm wrote: post #81
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…

> or javascript on the backend, that would be madness It seems madness is pretty common.

True.

For most projects, it's good enough.

Also, I worked for many shops that had a two language policy, one for development speed and one for performance.

For example, PHP and C or something.

They had many PHP devs and a few C devs and would write anything new in PHP and then later replace the few performance critical parts with C implementations.

I thought about doing this with JavaScript and Rust in my projects, but somehow I never got to the point that JavaScript became the bottle-neck.

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

#96

Post by aiisjustanif »

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…

Depends. If it's a internal, innersourced, tool for everyone. Have at it, use another language. If it's my critical application, explain why we use only one language for it and don't fire them.

We teach, not react.

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

#97

Post by mst »

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…

Your recollection is valuable, and thank you - but contra a large chunk of the rest of this thread, the article was very clear to me that it was "our erlang was crap erlang and we didn't know how to make it not crap so we switched" which is totally reasonable and didn't seem like a negative towards erlang at all. I've supported rewrites from a language I liked more to a language I liked less for similar reasons, and what Ankur did seems like an entirely sane decision.

But even if I didn't need the clarification, the additional data was awesome, so my thank you remain sincere :)

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

#98

Post by snotrockets »

wqwh wrote: post #14
nemothekid wrote: post #3

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

You can get excellent performance in Python, but at the cost of dev effort – a very deep understanding of the interpreter (and replacing some loops with Cython) would do wonders.

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

#100

Post by scarface74 »

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…

We have three approved languages - C#, JavaScript and Python.

Of course C# you get all of the advantages of statically typed languages, so for major programs where you wil have multiple developers, it’s the go to language. But for smaller scripts like event based lambdas and scripting type scenarios, C# is overkill. Besides, each piece of AWS functionality is in its own NuGet package as opposed to one package for everything for JavaScript (Node) and Python.

JavaScript - our product is web based. Every developer is expected to know JS. So if someone decides to do a simple Microservice or lambda in C# or JS, it’s okay. Whichever they feel like doing, it’s okay.

We have another team that does a lot of ETL type processing. I doubt that many people would argue that JS is a better language for it than Python. If you are on that team and need to write something, you can choose whichever of the three languages you wish.

Post reply on HN