Live data from Hacker News

Elixir saves Pinterest $2M a year in server costs

paraxial.io

201–210 of 481 posts

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

#201
post #64

Earlier quoted context omitted.

> When our notifications system was running on Java, it was on 30 c32.xl instances. When we switched over to Elixir, we could run on 15. Would be curious to know how they tried to optimise the Java stack. Because on every benchmark I've seen the JVM is faster in every which way than Elixir. Except for memory where often people will over-provision the JVM rather than look at where their code might be over-allocating o…

The advantages of Elixir are not performance-related. There is a lot of focus on raw performance on web-related services, when in reality most of their running time is spent waiting for IO. If there are two things the BEAM excels at, is IO and turning almost any problem into half a dozen processes that are scheduled and run in parallel, if not geographically-distributed, with 1/50th the effort of any other language.…

Elixir does not do anything better at IO than other languages.

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

#202
post #186
post #179

Earlier quoted context omitted.

How is calling Python "not a real language" just stating facts? I'm not sure by which metric we are judging whether a language is real or not, but I'm fairly sure that almost anything anyone comes up with will include Python, considering it's one of the most used languages in the world at this point, and used for a fairly large variety of use cases.

- GIL - No sound typing - No proper package management - Runtime type checking only - Interpreted I guess thats what he means with "Not a real language". I disagree.... Its a tool that has it place. But its often used as a hammer.

Easy to learn hard to master syndrome. Your comment says nothing.

* GIL - Your use case more than likely reimplements one wheel or another. Whatever compute you're doing should be deferred to the right tool (DB, queue, etc). Otherwise, if it's I/O, you're on par with Go and NodeJS (See FastAPI 3rd party quarterly benchmarks as an example)

* No sound typing - I don't know what this means. If you're concerned with typing, you can use pydantic for highly performant type checking and input/output validation.

* No proper package management - Poetry is excellent, been around a long time and is the unwritten defacto tool. Pipenv imo is close second. This argument feels forced as no one argued Go isn't a language before gomod was solidified. The community was fragmented and people wrote/chose their own tool.

* Runtime type checking only - In a world of interprocess communication, I don't see how this is relevant. You're not using Pytyon to write firmware. If you're not writing tests and just depend on successful compilation, you're writing bad code. Tests not only cover your point but are an excellent self doc. An added value, imo, that isn't spoken about enough. Regardless, tests cover this.

* Interpreted - A good last point to nail in the "your comment says nothing". What does this imply? That it's easier to debug with an interpreter? That cold starts are slow and your design is flawed given the tools?

Anyway, with C and Go bindings, most arguments against Python fall short. It has its place, yes, but a much wider one than the bandwagon regurgitates.

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

#203

Earlier quoted context omitted.

Elixir is a functional language for the Erlang VM. Most C++/Java/Rust/... programmers wpuld have hard time understanding it. But if you are in a bubble where everyone uses Haskell and talks about Monads, then OPs statement may be valid

Monads and Haskell is not a requirement to understand a functional programming language. Also, I find it hard to believe that anyone who knows N+1 programming languages would have a hard time understanding Elixir quickly, it looks like most mainstream programming languages used today, with slightly different syntax for some things. Take a look at https://elixir-lang.org/crash-course.html and you'll see what I mean, i…

As much as I love Elixir, it's really not just "basically Ruby with some slight modifications". The syntax is similar at a glance, but there are some major design differences (e.g. immutability); solving the same problem in Elixir and Ruby can require a completely different structure to your code.

I wrote this blog post about what I think are the three most important differences between Elixir and Ruby: https://phoenixonrails.com/blog/elixir-for-ruby-developers-t... . There's definitely a learning curve, although it's not insurmountable.

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

#204
post #186
post #179

Earlier quoted context omitted.

How is calling Python "not a real language" just stating facts? I'm not sure by which metric we are judging whether a language is real or not, but I'm fairly sure that almost anything anyone comes up with will include Python, considering it's one of the most used languages in the world at this point, and used for a fairly large variety of use cases.

- GIL - No sound typing - No proper package management - Runtime type checking only - Interpreted I guess thats what he means with "Not a real language". I disagree.... Its a tool that has it place. But its often used as a hammer.

Typescript/JavaScript has many of these properties except for GIL and maybe not typically interpreted. That means not a real language? Ruby also has a GIL.

I don’t even know what “proper package management” means in this context. Certainly there’s an official package management system and modules. C++ doesn’t have the latter (very fragmented user efforts and not commonly used in my experience) and barely the former (no adoption). So that means C++ isn’t a real language?

Python does have type checking by the way. Same as TypeScript - you annotate your types and you can run a program to verify your annotations. This is basically how TypeScript works although the typing in the latter is more mature by way of @types packages to let the community supplement adding typing information to third party packages. There’s no relation between the two so it’s not sound (in both cases), but in practice it’s quite useful.

Anyway, it’s a no true Scotsman argument.

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

#205

Earlier quoted context omitted.

Even if we take this as a factor, there's still no reason why would a Go or Java or SBCL implementation be significantly worse than Elixir.

There is a reason: the BEAM is almost not prone to huge GC pauses. Bigger load results in every actor responding very slightly slower. Nothing else. Many other systems don't have this property. They fall down under pressure. Gosh, a huge chunk of HN is always so dismissive. At least read up a bit beforehand, man. The criticisms should be informed and benefit the readers, not only express a generic skepticism.

That does not in any way explain a drop of 95%, which IMO is ridiculous and points to other issues.

The system they created now is totally different from the one they had. It’s more efficient by an insane margin. Choice of language seems like it would have trouble breaking the top 5 major reasons.

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

#206

Earlier quoted context omitted.

Second system syndrome. They did savings by re-implementing their services and attribute those savings to the new tool / programming language. I wonder what the saving would look like if they chose another tool for the second / optimized system. I doubt it would differ much if they went with Go, Java or stayed with Python.

This is a pretty realistic balanced real-world benchmark of web frameworks (and languages): https://www.techempower.com/benchmarks/ It shows that Python with Django is literally 40 times slower than the fastest framework. Python with uvicorn is 10 times slower. The use of languages like Python and Ruby literally results in >10x the servers being used; which not only results in higher cost, but also greater electricit…

Do you know if there are plans to publish more recent numbers, the newest one is a year old.

I'll definitely take a look at JustJS, that's an impressive ranking!!!

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

#207
post #3

By the title alone, this means nothing. How much would it cost otherwise? What is the percentage savings? In TFA, it gets better though: "Steve: That’s pretty easy. When I started on the spam team, we had close to 1,400 servers running. When we converted several parts to Elixir, we reduced that by around 95%. One of the systems that ran on 200 Python servers now runs on four Elixir servers (it can actually run on two…

Second system syndrome. They did savings by re-implementing their services and attribute those savings to the new tool / programming language. I wonder what the saving would look like if they chose another tool for the second / optimized system. I doubt it would differ much if they went with Go, Java or stayed with Python.

forgive the nitpicking but "second system syndrome" usually means that re-architecting goes wrong because of bloat[0].

This is the opposite case, when lessons learned in the first write are actually useful for a second rewrite.

I think the commonly associated soundbite is "build one to throw away."

[0] https://wiki.c2.com/?SecondSystemEffect

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

#209

Earlier quoted context omitted.

Even if we take this as a factor, there's still no reason why would a Go or Java or SBCL implementation be significantly worse than Elixir.

There is a reason: the BEAM is almost not prone to huge GC pauses. Bigger load results in every actor responding very slightly slower. Nothing else. Many other systems don't have this property. They fall down under pressure. Gosh, a huge chunk of HN is always so dismissive. At least read up a bit beforehand, man. The criticisms should be informed and benefit the readers, not only express a generic skepticism.

If you're seeing GC pauses of >1ms in Go, please report a bug

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

#210

Earlier quoted context omitted.

Even if we take this as a factor, there's still no reason why would a Go or Java or SBCL implementation be significantly worse than Elixir.

There is a reason: the BEAM is almost not prone to huge GC pauses. Bigger load results in every actor responding very slightly slower. Nothing else. Many other systems don't have this property. They fall down under pressure. Gosh, a huge chunk of HN is always so dismissive. At least read up a bit beforehand, man. The criticisms should be informed and benefit the readers, not only express a generic skepticism.

The beam just garbage collects each actor separately, and it so happens that much of the time your actor has finished before a gc happened so you never see the cleanup.

The beam also has a spectacular failure mode: OOM whenever messages come in at a higher rate than they are processed. The lack of backpressure mechanisms mean a huge amount of beam language developers spend way too much time recreating their own way for dealing with this or pretend it is not a problem at all. This means too many libraries in the ecosystem behave totally differently under load.

Post reply on HN