Re:Things you probably don't know about Go (2012) [slides]
by kerkeslager on Friday October 11, 2019 @07:45AM
(#21223385)
> In real life if you find your performance bottleneck is some part of a Python library, chances are you're going to look around your company and not find someone that has the competence and time to fix your performance bottleneck by creating a usable and bug-free C implementation.
Okay but:
1. How often do you find your performance bottleneck is some part of a Python library? My entire point is that modern Python development almost always delegates hotspots to pre-optimized libraries.
2. If your bottleneck is a use case that's unsolved so that there isn't a pre-existing library for it, it's probably unsolved because it's a difficult enough problem that using the C foreign-function interface is the least of your problems. It's also likely that you need a level of optimization which Go can't give you, so you're going to have to drop down to C/Fortran/assembly/whatever regardless of whether you're using Python or Go.
Okay but:
1. How often do you find your performance bottleneck is some part of a Python library? My entire point is that modern Python development almost always delegates hotspots to pre-optimized libraries.
2. If your bottleneck is a use case that's unsolved so that there isn't a pre-existing library for it, it's probably unsolved because it's a difficult enough problem that using the C foreign-function interface is the least of your problems. It's also likely that you need a level of optimization which Go can't give you, so you're going to have to drop down to C/Fortran/assembly/whatever regardless of whether you're using Python or Go.