7 ms·

Second system syndrome. They did savings by re-implementing their services and attribute those savings to the new tool / programming language. I wonder what t

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.

throwaway894345 3y ago
I think second syndrome is probably a significant factor, but I can also believe that ditching Python was also a significant factor. EDIT: I’m being rate limited because I guess my comments are too spicy for the HN mods, but anyway I agree that there’s no reason other non-Python languages would fare much worse than Elixir.
- miroljub 3y ago
  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.
  - 83457 3y ago
    Isn't the major difference here compared to others the BEAM?
    - throwaway894345 3y ago
      You need to advance a theory about how the BEAM could make a 95% improvement in a way the alternatives cannot. For example, a Go has a very good asynchronous story as well and while it may not be exactly as good as BEAM languages, it makes up for it in straight line execution performance. I’ve personally rewritten a few carefully optimized Python applications in pretty naive Go (without significant rearchitecting) and witnessed 50X-1000X performance improvements. And moreover Go allows for more optimization beyond what Python allows (e.g., consolidating allocations and lifting them out of the hot path).
  - pdimitar 3y ago
    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.
    - SanderNL 3y ago
      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.
      - pdimitar 3y ago
        Why is it ridiculous? I migrated Rails apps to Elixir before, we reduced from 15 servers to 3, and 1 was basically "if crap hits the fan", we could have gotten away with 2 easily. It's worrying that a supposedly high-quality forum like HN receives comments with no substance. If you have an actual counter-argument, let's discuss. If not, well, not an interesting exchange.
        throwaway894345 3y ago
        You’re comparing Elixir to Python and Rails. Many of us have seen Python replaced with other languages for an astronomical improvement. Python and Ruby are the slowest category of languages; they’re easily beaten and you need to offer some evidence as to why the improvement was derived from migrating to Elixir specifically rather than moving away from Python/Rails.
        pdimitar 3y ago
        Sure, not wrong on the outset, but you do come across as dismissive of Elixir while stating this.
paulsutter 3y ago
Python is 100x slower than a real language (I like python and use it often, not meant as a dig at the language just stating facts) My favorite thing about Python is writing prototypes. The big risk with writing a prototype is that it survives into production. Using Python ensures that the code will be replaced by real code Python is great for other non-production code like Jupyter notebooks, numpy experiments, etc
- edanm 3y ago
  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.
  - TeeWEE 3y ago
    - 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.
    - 0xedd 3y ago
      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.
winter_blue 3y ago
This is a pretty realistic balanced real-world benchmark of web frameworks (and languages): https://www.techempower.com/benchmarks/ 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 electricity use, and pollution and carbon emissions if the grid where the data center is located uses fossil fuels. Not to mention, dynamically-typed languages are truly horrible from a code readability point of view. Large code bases are IMO difficult to read and make sense of, hard to debug, and more prone to bugs, without static types. I'm aware that Elixir is dynamically-typed, but it (along with JS) is an exception in terms of speed. Most dynamically-typed languages are quite slow. Not only do dynamically-typed languages damage the environment as they're typically an order of magnitude slower, they also lower developer productivity, and damage the robustness and reliability of the software written in it. To be clear, I'm in favor of anything that increases productivity. If Kotlin were 10 times slower, I'd be happy to pay that price, since it is genuinely a great language to work with, is statically typed, and developers are more productive in it. I'm not sure how Elixir mitigates the downsides of dynamic typing (maybe lots of 'type checks' with pattern matching?), but it would definitely be super-nice if a well-designed (Kotlin or Haskell like?) statically-typed language targeting the BEAM existed...
- dorfsmay 3y ago
  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!!!
  - winter_blue 3y ago
    The creator of JustJS has written about how it's so fast actually: https://just.billywhizz.io/blog/on-javascript-performance-01/ https://just.billywhizz.io/blog/on-javascript-performance-01... (Related GitHub thread: https://github.com/just-js/just/issues/5 https://github.com/just-js/just/issues/5)
- 3y ago
riffraff 3y ago
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 https://wiki.c2.com/?SecondSystemEffect
liveoneggs 3y ago
While you are probably right it's also true that python is just straight up slow - especially in normal configurations (django, flask, uwsgi, lambdas, etc) and elixir is pretty fast while offering a great/fun/friendly dev experience + BEAM-HA/scaling-benefits. They could have also blown everything out of the water with C++ - or probably even golang - but if elixir can do it on 2-4 boxes it's fast enough.
loloquwowndueo 3y ago
Um that’s not what second system syndrome is. It’s a simple rewrite.

throwaway894345 3y ago

I think second syndrome is probably a significant factor, but I can also believe that ditching Python was also a significant factor. EDIT: I’m being rate limited because I guess my comments are too spicy for the HN mods, but anyway I agree that there’s no reason other non-Python languages would fare much worse than Elixir.

miroljub 3y ago
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.
- 83457 3y ago
  Isn't the major difference here compared to others the BEAM?
  - throwaway894345 3y ago
    You need to advance a theory about how the BEAM could make a 95% improvement in a way the alternatives cannot. For example, a Go has a very good asynchronous story as well and while it may not be exactly as good as BEAM languages, it makes up for it in straight line execution performance. I’ve personally rewritten a few carefully optimized Python applications in pretty naive Go (without significant rearchitecting) and witnessed 50X-1000X performance improvements. And moreover Go allows for more optimization beyond what Python allows (e.g., consolidating allocations and lifting them out of the hot path).
- pdimitar 3y ago
  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.
  - SanderNL 3y ago
    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.
    - pdimitar 3y ago
      Why is it ridiculous? I migrated Rails apps to Elixir before, we reduced from 15 servers to 3, and 1 was basically "if crap hits the fan", we could have gotten away with 2 easily. It's worrying that a supposedly high-quality forum like HN receives comments with no substance. If you have an actual counter-argument, let's discuss. If not, well, not an interesting exchange.
      - throwaway894345 3y ago
        You’re comparing Elixir to Python and Rails. Many of us have seen Python replaced with other languages for an astronomical improvement. Python and Ruby are the slowest category of languages; they’re easily beaten and you need to offer some evidence as to why the improvement was derived from migrating to Elixir specifically rather than moving away from Python/Rails.
        pdimitar 3y ago
        Sure, not wrong on the outset, but you do come across as dismissive of Elixir while stating this.

paulsutter 3y ago

Python is 100x slower than a real language (I like python and use it often, not meant as a dig at the language just stating facts) My favorite thing about Python is writing prototypes. The big risk with writing a prototype is that it survives into production. Using Python ensures that the code will be replaced by real code Python is great for other non-production code like Jupyter notebooks, numpy experiments, etc

edanm 3y ago
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.
- TeeWEE 3y ago
  - 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.
  - 0xedd 3y ago
    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.

winter_blue 3y ago

This is a pretty realistic balanced real-world benchmark of web frameworks (and languages): https://www.techempower.com/benchmarks/ 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 electricity use, and pollution and carbon emissions if the grid where the data center is located uses fossil fuels. Not to mention, dynamically-typed languages are truly horrible from a code readability point of view. Large code bases are IMO difficult to read and make sense of, hard to debug, and more prone to bugs, without static types. I'm aware that Elixir is dynamically-typed, but it (along with JS) is an exception in terms of speed. Most dynamically-typed languages are quite slow. Not only do dynamically-typed languages damage the environment as they're typically an order of magnitude slower, they also lower developer productivity, and damage the robustness and reliability of the software written in it. To be clear, I'm in favor of anything that increases productivity. If Kotlin were 10 times slower, I'd be happy to pay that price, since it is genuinely a great language to work with, is statically typed, and developers are more productive in it. I'm not sure how Elixir mitigates the downsides of dynamic typing (maybe lots of 'type checks' with pattern matching?), but it would definitely be super-nice if a well-designed (Kotlin or Haskell like?) statically-typed language targeting the BEAM existed...

dorfsmay 3y ago
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!!!
- winter_blue 3y ago
  The creator of JustJS has written about how it's so fast actually: https://just.billywhizz.io/blog/on-javascript-performance-01/ https://just.billywhizz.io/blog/on-javascript-performance-01... (Related GitHub thread: https://github.com/just-js/just/issues/5 https://github.com/just-js/just/issues/5)
3y ago

riffraff 3y ago

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 https://wiki.c2.com/?SecondSystemEffect

liveoneggs 3y ago

While you are probably right it's also true that python is just straight up slow - especially in normal configurations (django, flask, uwsgi, lambdas, etc) and elixir is pretty fast while offering a great/fun/friendly dev experience + BEAM-HA/scaling-benefits. They could have also blown everything out of the water with C++ - or probably even golang - but if elixir can do it on 2-4 boxes it's fast enough.

loloquwowndueo 3y ago

Um that’s not what second system syndrome is. It’s a simple rewrite.