5 ms·

They rewrote, which is known to help too. Going from 30 to 15 instances is not bad but it's very likely that a Java-to-Java rewrite would have helped go down t

They rewrote, which is known to help too. Going from 30 to 15 instances is not bad but it's very likely that a Java-to-Java rewrite would have helped go down too. The big one however is going from 200 Python servers to 4 Erlang ones: a 50x reduction is quite something and a Python-to-Python rewrite would not have allowed to achieved a 50x gain: > All this is possible because Elixir, and the Erlang platform underneath, are fundamentally designed for always-online software with many users. When you use the right tool for the job, the benefits are clear.

chii 3y ago
> it's very likely that a Java-to-Java rewrite would have helped go down too. it depends. The elixir programming paradigm might be one where you are able to more easily write efficient, but still highly concurrent code, where as it would take more work to do the same in java.
- elcritch 3y ago
  Elixir / Erlang does open up a lot of paradigms. However it'll be interesting to see how Java fairs with its new virtual threads. There was already Akka so it should happen fairly quickly. Still I'd prefer Elixir. The BEAM VM just runs lighter.
  - OkayPhysicist 3y ago
    If it's cludged on like Java's attempt at supporting basic functional programming, it's guaranteed to painful regardless.
- ddorian43 3y ago
  Project loom should make it better in dev experience and easier to reason + better library evosystem.
ddorian43 3y ago
Is this a cpu-heavy workload? If it's mostly io-heavy, I could see a gevent + pypy approach getting 50x better.
- retrocryptid 3y ago
  [flagged]
  - infecto 3y ago
    Why is that?
  - dragonwriter 3y ago
    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?
    - retrocryptid 3y ago
      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.
      - dragonwriter 3y ago
        > When you move from one minor rev of python to the next, some language feature changes Even if there was a breaking change affecting your project every minor version, to have the cadence of backward-compatibility induced changes you siggest you’d have to be switching Python versions forward about four times as fast as they are released, which, if you started with the oldest in support version at the beginning of the project, you could only sustain for about a year and a half, before running out of versions to switch forward to. > If you used a feature like package variables in your code in 2.3, Then you are probably out yelling at kids to get off your lawn; 2.3 being out of support for 12 years.
tyingq 3y ago
There's some actual detail on the Python -> Elixir move here: https://medium.com/pinterest-engineering/fighting-spam-with-guardian-a-real-time-analytics-and-rules-engine-938e7e61fa27 https://medium.com/pinterest-engineering/fighting-spam-with-... In short, the Elixir is doing something completely different. And they are also not counting some new pieces like the database cluster and kafka based aggregators, etc.
mrighele 3y ago
> They rewrote, which is known to help too. Going from 30 to 15 instances is not bad but it's very likely that a Java-to-Java rewrite would have helped go down too. A java-to-java rewrite could have been as much if not more painful than a java-to-elixir rewrite, especially if the service is highly concurrent. Rewriting synchronous code as asynchronous in Java is a lot of work and not fun at all IMO. Given the recent arrival of virtual threads in Java 21 this may not be necessary any longer but at the time I think it was a perfectly reasonable choice.
- za3faran 3y ago
  Wait a few years for a blog post outlining their rewrite in Java's virtual threads for an improvement in performance and latency ;)
astrobe_ 3y ago
> The big one however is going from 200 Python servers to 4 Erlang ones If your rewrite or refactor gives you a 10X in performance, that's not an optimization, but a bugfix. Unless you are a researcher who have just found a revolutionary algorithm.
- coldtea 3y ago
  Or you just used a crappy inefficient architecture or algorithsm etc. Just because they were slow doesn't make them bugs, nor does using something faster in a rewrite means it's a bugfix.
  - btreecat 3y ago
    They could be design bugs as in it was broken/buggy by design.
    - Difwif 3y ago
      Or it was quick and cheap to build, by design. It's perfectly acceptable to optimize for time to market first if you can eat the other costs.
    - Adkron 3y ago
      Could those design-bugs be in the language's runtime?
- znpy 3y ago
  I’m going to be cynical and say that if they went from 200 to 4 servers they were probably spawning the python code via cgi, synchronously…
- anonymoushn 3y ago
  Why? Most software is at least 10x slower than necessary for reasons that don't require inventing new algorithms.
  - astrobe_ 3y ago
0xedd 3y ago
They threw DB[s] and Kafka into the mix. Python would get them the same net gain, if not more, with less dev cost. Python's I/O workloads perform on par with Go/NodeJS (See FastAPIs 3rd party quarterly benchmarks as an example). If they rebrand Python to Metal or some other name, people would recommend it left and right. It's just suffering from bandwagon criticism. Yet it remains one of the top 3 languages for years, covering several domains.
- ebiester 3y ago
  Python is the second best language for everything. Even with its warts (which any language gets after 30 years), it's a very solid, defensible choice. However, it does not have a great concurrency story relative to languages that were built concurrency first (Go, Erlang), and it's fair to acknowledge that.

chii 3y ago

> it's very likely that a Java-to-Java rewrite would have helped go down too. it depends. The elixir programming paradigm might be one where you are able to more easily write efficient, but still highly concurrent code, where as it would take more work to do the same in java.

elcritch 3y ago
Elixir / Erlang does open up a lot of paradigms. However it'll be interesting to see how Java fairs with its new virtual threads. There was already Akka so it should happen fairly quickly. Still I'd prefer Elixir. The BEAM VM just runs lighter.
- OkayPhysicist 3y ago
  If it's cludged on like Java's attempt at supporting basic functional programming, it's guaranteed to painful regardless.
ddorian43 3y ago
Project loom should make it better in dev experience and easier to reason + better library evosystem.

ddorian43 3y ago

Is this a cpu-heavy workload? If it's mostly io-heavy, I could see a gevent + pypy approach getting 50x better.

retrocryptid 3y ago
[flagged]
- infecto 3y ago
  Why is that?
- dragonwriter 3y ago
  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?
  - retrocryptid 3y ago
    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.
    - dragonwriter 3y ago
      > When you move from one minor rev of python to the next, some language feature changes Even if there was a breaking change affecting your project every minor version, to have the cadence of backward-compatibility induced changes you siggest you’d have to be switching Python versions forward about four times as fast as they are released, which, if you started with the oldest in support version at the beginning of the project, you could only sustain for about a year and a half, before running out of versions to switch forward to. > If you used a feature like package variables in your code in 2.3, Then you are probably out yelling at kids to get off your lawn; 2.3 being out of support for 12 years.

tyingq 3y ago

There's some actual detail on the Python -> Elixir move here: https://medium.com/pinterest-engineering/fighting-spam-with-guardian-a-real-time-analytics-and-rules-engine-938e7e61fa27 https://medium.com/pinterest-engineering/fighting-spam-with-... In short, the Elixir is doing something completely different. And they are also not counting some new pieces like the database cluster and kafka based aggregators, etc.

mrighele 3y ago

> They rewrote, which is known to help too. Going from 30 to 15 instances is not bad but it's very likely that a Java-to-Java rewrite would have helped go down too. A java-to-java rewrite could have been as much if not more painful than a java-to-elixir rewrite, especially if the service is highly concurrent. Rewriting synchronous code as asynchronous in Java is a lot of work and not fun at all IMO. Given the recent arrival of virtual threads in Java 21 this may not be necessary any longer but at the time I think it was a perfectly reasonable choice.

za3faran 3y ago
Wait a few years for a blog post outlining their rewrite in Java's virtual threads for an improvement in performance and latency ;)

astrobe_ 3y ago

> The big one however is going from 200 Python servers to 4 Erlang ones If your rewrite or refactor gives you a 10X in performance, that's not an optimization, but a bugfix. Unless you are a researcher who have just found a revolutionary algorithm.

coldtea 3y ago
Or you just used a crappy inefficient architecture or algorithsm etc. Just because they were slow doesn't make them bugs, nor does using something faster in a rewrite means it's a bugfix.
- btreecat 3y ago
  They could be design bugs as in it was broken/buggy by design.
  - Difwif 3y ago
    Or it was quick and cheap to build, by design. It's perfectly acceptable to optimize for time to market first if you can eat the other costs.
  - Adkron 3y ago
    Could those design-bugs be in the language's runtime?
znpy 3y ago
I’m going to be cynical and say that if they went from 200 to 4 servers they were probably spawning the python code via cgi, synchronously…
anonymoushn 3y ago
Why? Most software is at least 10x slower than necessary for reasons that don't require inventing new algorithms.
- astrobe_ 3y ago

0xedd 3y ago

They threw DB[s] and Kafka into the mix. Python would get them the same net gain, if not more, with less dev cost. Python's I/O workloads perform on par with Go/NodeJS (See FastAPIs 3rd party quarterly benchmarks as an example). If they rebrand Python to Metal or some other name, people would recommend it left and right. It's just suffering from bandwagon criticism. Yet it remains one of the top 3 languages for years, covering several domains.

ebiester 3y ago
Python is the second best language for everything. Even with its warts (which any language gets after 30 years), it's a very solid, defensible choice. However, it does not have a great concurrency story relative to languages that were built concurrency first (Go, Erlang), and it's fair to acknowledge that.