Fun read, but mistitled.
Sentry did not fix Python’s performance for source-maps; they called out to Rust code to handle that codepath.
Don’t get me wrong, that they called out to Rust doesn’t bother me; but the title does.
I keep hearing people tell me that “Python is fast enough”, but whenever Python falls short (which, frankly, seems to be quite common), the solution is to write the code in a faster language and then call that code from Python. When do we accept that Python is actually not fast enough and that what we need is faster, higher-level languages?
Because no one has yet come up with a language that matches python for ease of development, prototyping speed, and ecosystem richness that also is much faster. Julia is trying, albeit with a numerical focus.
Also the fact that python can be used as glue code between native code extensions is one of the reasons it'a been so successful.
Python is good for connecting things together very quickly, so you get a huge speed boost out of the door.
For things that need to be fast, you can write up C just for the part that needs to be fast and call it from Python. This is a pretty painless process, and what a lot of performance-sensitive libraries use.
So if you wrote everything in C, you might get a faster program, but it would be slower to write in the first place, and all the bits that would be easy to write in python end up being longer.
If you write everything in Python, then when you get to bits where C is easier, you just … write those bits in C. Almost by definition, Python will give you a better result, because when it doesn’t, you can simply use the better result.
Great read! Creating Python extensions is always a bit magical.