Please remember something very important everyone: The company may have changed its policy, but the company that made the policy hasn’t changed. The people that made the bad decisions are still in charge, and the priorities that made them make that decision are still the same. They haven’t changed.

This is relevant not just for Proton, but about every time company pretends to step back from a bad decision.

Worthless maneouver at this point, the mask is off already. The guy has exposed his extreme toxicity, nobody (employees or customers) will trust him again.

Which is embarrassing. When you’re the CEO of the upstart, you have to have as spotless of an image as possible. He clearly isn’t cut out for the job. Not that it matters anymore, Proton may very well be toast at this point.

Great costume work.

Except for the guys in the golf cart, what the hell were they thinking

The Linux Foundation has unfortunately become a commercial shithole, run by a clusterfuck of Silicon Valley VCs. When I see the kinds of garbage AI projects that are being shoveled into it every day, I lose more and more respect for it.

Look for yourselves: https://www.linuxfoundation.org/projects

And it’s sad to see Linus falling into their lock and step. I respect him for a lot of things, but when it comes to AI, he’s sadly just wrong.

If you didn’t use a profiler, then how can you be sure that the issue was Python and not something else? If the slowness really is evenly distributed through the code as you suggest, then a profiler would show that almost instantly and it’s very easy to do that in Python using cProfile.

On top of that, the Python standard library is built for convenience, not performance. The nature of it being a standard library means that the implementation has to be simple. fastregex uses LLVM and SIMD for example, that’s something that’s wildly impractical for the Python stdlib to support. In contrast, I have no idea what regex or JSON library you used for your Rust code, but if it were outside the stdlib, chances are high that it had much more leeway to optimize performance because it didn’t have all the other maintenance obligations that stdlib code needs to support.

All of this is just pure speculation on my part, but ultimately I’m trying to make a point that it is hard to say that the difference was caused by a language issue and not something else. There are lots of other things that could be contributing to this difference and you can’t really say for sure without meaningful diagnostics.

As an example of this, look at Nicholas Nethercote’s excellent series of blogs on making the Rust compiler faster: https://nnethercote.github.io/

The “bottlenecks” they find result in 1% speedups.

The kinds of software that you and I write on a daily basis is nothing compared to pieces of software that get millions of man-hours per year. Assuming you’re not Linus Torvalds or Ted Ts’o hiding behind a funny alias, of course. I don’t think anyone is suggesting that it’s a good idea to write a compiler in Python (outside of prototyping purposes perhaps) since it’s obviously not I/O bound, but if you and I are trying to optimize something we wrote ourselves, we’re more likely to be in the “nice small hotspot” domain you described, rather than the 1% bottleneck speedups discussed in the link you posted.

Very cool link though by the way, I look forward to reading as much of it as I can…

Did you use a profiler to find the bottlenecks? Did you try using cjson to speed up the json parsing? I would also avoid using the stdlib regex library too. It’s probably more of a convenience/reference implementation, not something to be intended for high performance. Maybe there’s a re2 wrapper for Python or a similar regex library in C with Python bindings.

Rewriting in Rust is fine, but good Python devs know how to find bottlenecks in their software and replace them with fast implementations. I’ve written plenty of performant Python code, it’s not very hard to profile and optimize. Usually the performant stuff is already written in C/C++ or Fortran anyway (numpy, PyQt, etc.)