Live data from Hacker News

Elixir saves Pinterest $2M a year in server costs

paraxial.io

371–380 of 481 posts

Re: Elixir saves Pinterest $2M a year in server costs

#371

Earlier quoted context omitted.

This is incorrect. We continue to use it in a large rule engine for spam filtering.

I was there and it was not being used in new projects. Maybe that spam filtering service has existed for that long. I would definitely not say that pinterest has fully bought into using elixir because of cost savings which is what the article seems to be insinuating.

There was a point like 8 (ish?) years ago where Pinterest wanted to consolidate on a single backend language internally, after it became apparent Python was not suitable, and multiple contenders were being tried in different places. I think at that time Steve was advocating for Elixir to be it. However it ended up being Java.

Nowadays, kind of ironically after the consolidation, we have backend services in at least six languages I can think of. Which is just the reality of how things play out for a tech company doing acquisitions. But yeah we’re not making new ones in Elixir.

Re: Elixir saves Pinterest $2M a year in server costs

#372

I am very skeptical about this. The title makes it look like it's all about Elixir, but there seems to have been a fair amount of re-architecturing. "One of the systems that ran on 200 Python servers now runs on four Elixir servers" This alone is a major telltale.

For sure; Elixir comes with a whole new architecture as well, and they COULD have gained a significant performance improvement if they rewrote / re-architected it in Python. However, could they have done a 50x performance improvement in Python? And what about the other numbers, like speed and concurrency? That said, I'm confident they crunched the numbers and did the tradeoffs; after all, adding another language and/…

Depends. Were they already using gunicorn? What about cPython? Was the code written by a junior developer without much consideration for memorization and dictionary access?

And sure, you can get some performance improvements by rewriting things in those languages, at the expense of losing the entire python open source environment.

So I would need way more information about the previous system to take this even remotely seriously.

Python scales quite reasonably for most small to medium companies.

Re: Elixir saves Pinterest $2M a year in server costs

#373

Earlier quoted context omitted.

Elixir is slower than plain PHP according to the techempower benchmarks. I'm not even sure how that's possible but it is. By like a factor of 2 iirc. I'm not sure how elixir is that slow since it's compiled.

It depends on what is actually being benchmarked though; if it's the simple JSON payload, more time will be spent on HTTP parsing (done in nginx for the PHP benchmark so really really fast) and some JSON parsing (done in a C library for the PHP benchmark so really really fast). Basically, how much PHP is actually being benchmarked? Are you looking at a benchmark that compares real-world usage, or a microbenchmark lik…

That's a reasonable point. This is Techempower as I mentioned originally. In pretty much all the benchmarks PHP smokes Elixir

Re: Elixir saves Pinterest $2M a year in server costs

#374
post #93

Earlier quoted context omitted.

Elixir is slower than plain PHP according to the techempower benchmarks. I'm not even sure how that's possible but it is. By like a factor of 2 iirc. I'm not sure how elixir is that slow since it's compiled.

> Elixir is slower than plain PHP according to the techempower benchmarks. I'm not even sure how that's possible but it is. You're "Not even sure how that's possible" as if implying PHP is slow? Even old pre-7 PHP was much faster than Ruby, Python, and others. And most PHP libs are just wrappers over C code.

PHP is interpreted and Elixir is compiled. Comparing them to Ruby and Python make no sense as they are interpreted as well.

The fact that Elixir, a compiled language, known for speed, is slower than PHP is surprising. As far as "Most PHP libs are wrappers over C code". That's just not true. Most PHP libs are in PHP

Re: Elixir saves Pinterest $2M a year in server costs

#375

Earlier quoted context omitted.

Going from > greater electricity use, and pollution and carbon emissions if the grid where the data center is located uses fossil fuels . to > dynamically-typed languages damage the environment as they're typically an order of magnitude slower is quite a stretch. Do dynamically-typed languages inherently damage the environment? Or is it the fossil fuels? Not that the appeal to the environment matters, because later o…

> Do dynamically-typed languages inherently damage the environment? Or is it the fossil fuels? My opinion is that slow languages that use 10x the electricity, with no ROI for the 10x energy use is bad. High energy use, even if it's clean energy, implies a higher environmental toll. If a country were solely using nuclear and solar, higher energy use results in (1) more nuclear reactors constructed, and (2) more solar…

For the vast majority of projects this makes no difference. If you are at Facebook scale? Sure. But then, you do what they did, write a VM to speed things up.

Dynamic typing doesn't cost much more money on average and thankfully the cost of energy itself is a motivation for companies to do rewrites. If they are paying a lot in server costs and electricity then they do typically rewrite to reduce the amount of servers.

For companies they primarily need to worry about running at a profit and getting to market quickly which dynamic languages do extremely well, and the costs in electricity and carbon aren't very high when your scale is small.

Re: Elixir saves Pinterest $2M a year in server costs

#376

Earlier quoted context omitted.

Yep. We got a 10x improvement on throughput for our backend runtime, which was in Java, by moving to a better architecture for performance hotspots.. using Java again. In a rewrite with a different design/architecture, that new design typically accounts for most gains, rather than language. A language may make some parts of that rewrite simpler.

I've gotten 100x improvement with no code change by just adding an index in the database table. An inexperienced developer might have blamed the database and insisted on moving to NoSQL because of "web scale". If they got the chance to rewrite it, they could have pointed to the performance increase as a proof that they were right.

Yes, that too. Indexes and caching

Re: Elixir saves Pinterest $2M a year in server costs

#377
post #141

Earlier quoted context omitted.

[flagged]

Flagged for being silly flamebait. The Python projects you have personal experience with might have been poorly run but that’s not representative of the language, and it’s not going to lead to a conversation where anyone learns something.

The syntax and semantics of the language change in non-reverse-compatible ways between every minor release. This is independent of project management.

As an example, between 2.3 and 2.5, the syntax for package variables was changed (and then the semantics were changed between 2.5 and 2.7). There is nothing you can do as a python user to ameliorate the impact of such changes other than to not use those language features.

Can you explain how "managing my project better" would have allowed me to avoid the impact of this change?

Re: Elixir saves Pinterest $2M a year in server costs

#378

Earlier quoted context omitted.

This sounds like ets tables holding on to binaries that were extracted from JSON. This is something that iirc pager duty ran into.

The underlying problem we had* was the rate work was being completed was lower than the rate requests were coming in which causes the mailboxes on the actors to grow indefinitely. In golang the approximate equivalent is a buffered channel that would start blocking because it has run out, but the beam will just keep those messages piling on to the queue as fast as possible until OOM. This is obviously a philosophical…

Why weren't your processes dropping messages? Also I think you can tell the VM to not allow the process to exceed a certain message size and trigger some sort of rate limiting or scaling out

Edit: huh. I could swear the VM had memory limit options. Guess not. Time to rewrite it in zig!

Re: Elixir saves Pinterest $2M a year in server costs

#379

Earlier quoted context omitted.

[flagged]

I don’t tend rewrite Python code any more often than is needed due to feature changes or occasionally refactoring to pay off some maintenance friction caused by design that has in practice turned out to be suboptimal. What are you talking about?

When you move from one minor rev of python to the next, some language feature changes (either syntax or semantics or features no longer work.)

For instance... if you use async io in 2.x, the debugger stops working. Between 2.3, 2.5 and 2.7, the syntax of package variable scoping changed and then the semantics changed from package to class variables.

If you used a feature like package variables in your code in 2.3, that code would not work in 2.5. If you fixed it in 2.5, the semantics changed so that if you defined a package variable according to the 2.5 syntax, but it was defined within a class, it became a class variable.

This is just an example.

Re: Elixir saves Pinterest $2M a year in server costs

#380
post #141

Earlier quoted context omitted.

Flagged for being silly flamebait. The Python projects you have personal experience with might have been poorly run but that’s not representative of the language, and it’s not going to lead to a conversation where anyone learns something.

The syntax and semantics of the language change in non-reverse-compatible ways between every minor release. This is independent of project management. As an example, between 2.3 and 2.5, the syntax for package variables was changed (and then the semantics were changed between 2.5 and 2.7). There is nothing you can do as a python user to ameliorate the impact of such changes other than to not use those language featur…

> The syntax and semantics of the language change in non-reverse-compatible ways between every minor release.

Even accepting this and assuming the average project was bit by every single one, the release cadence for minor versions is aboit once per year (recently, almost exactly that, in October), and minor versions are supported for 5 years, so this would justify updates every year if you were a maximally eager adopter, or every five years with a maximally conservative while only using in-support versions approach, or somewhere in between for less extreme cases, not every three months.

> As an example, between 2.3 and 2.5, the syntax for package variables was changed (and then the semantics were changed between 2.5 and 2.7).

2.7 was released 13 years ago. Why would you reach that far back for a relevant example?

Post reply on HN