> Leaving some performance critical stuff in C is okay. I disagree on account of the glovebox problem. If you can't touch your data without losing perf, your

> Leaving some performance critical stuff in C is okay. I disagree on account of the glovebox problem. If you can't touch your data without losing perf, your API becomes awkward like a glovebox. All meaningful low-level operations must be represented in your high-level API which bloats the heck out of it. To add insult to injury, it still usually doesn't get you 100% functionality coverage, so projects that veer even slightly off the beaten path are all but guaranteed to involve C and bridge crossings and explode in complexity. So the end result is unnecessarily bloated libraries that unnecessarily constrain your creativity. Yes, I know about numba -- I've used it heavily and even contributed a few bugfixes -- but it's often not even a workable solution, let alone a good solution, let alone a good solution that's fully integrated into the ecosystem (i.e. debug and in other people's code). Most of the code I write is still python, but I need perf, so I suffer at the python/C bridge regularly. Like any other programming language bridge, it has trolls under it, so if you only need to cross once or twice you're probably fine but if you frequent the bridge they're going to periodically pop up and beat the shit out of you. This won't affect people following tensorflow tutorials but it greatly affects people in the deep end of the ecosystem and it really sucks. Next time the trolls come out, I'm going to try to make the case for Julia again. Hopefully one of these times we make the right choice, but in the meantime it would be nice if the people using my libraries understood that I was taking troll-beatings on their behalf and listened to my requests that maybe we should do something about it one of these days.