gopy VS poly-match

I've used gopy[0] recently to access a go library in Python. It surprisingly Just Worked, but I was disappointed by some performance issues, like converting lists to slices.

[0] https://github.com/go-python/gopy

the heavy lifting is done in native libraries and you get to experiment fast using an easy language. the combo is quite hard to beat. Now there is a missed opportunity to write such libraries in Go, but as I read here and there Go is hard to integrate well as a library. There is gopy but it's light years away from PyO3 for instance, I don't think it'll ever gain traction, but who knows.

> So if you learn Go, you'll never be able to use it to interoperate with e.g. your Python program to speed it up.

Never done it myself, but:

https://www.ardanlabs.com/blog/2020/07/extending-python-with...

https://github.com/go-python/gopy

Check out gopy for an easy way to extend your Python code with Go.

Not my experience at all. At work we rewrote a small bit of hotspot python in Rust with no issues. This was what we primarily followed: https://ohadravid.github.io/posts/2023-03-rusty-python/

Take at look at this example, it still uses Python as an interface to Rust code. Maybe you can do something similar to still achieve performance improvements without changing the entire codebase.

People are probably downvoting because it's needlessly hyperbolic and argumentative. Nobody is saying that python isn't faster to iterate with, but they're arguing that it would take months to get negligable performance gains in a lower level language, meanwhile here is a recent post from a company that increased the execution of they're python code by 100x with less than 100 lines of Rust. They also claim that nobody cares if something runs a few milliseconds faster, when we're talking about game dev, where games are frequently judged on how many milliseconds it takes to run game logic between frames.

Semi Vectorized code:

https://github.com/ohadravid/poly-match/blob/main/poly_match...

Expecting Python engineers unable to read defacto standard numpy code but meanwhile expect everyone can read Rust.....

Not to mention that the semi-vectorized code is still suboptimal. Too many for loops despite the author clearly know they can all be vectorized.

For example instead the author can just write something like:

   np.argmin(

The article links to a full implementation, so you should be able to test this.