3 ms·
Numpy/Scipy are great for prototyping, but IMO code the performant / concurrent stuff in C/C++/Rust/Julia once your prototype is done. Use the right tool for th
by the__alchemist 5y ago
Numpy/Scipy are great for prototyping, but IMO code the performant / concurrent stuff in C/C++/Rust/Julia once your prototype is done. Use the right tool for the job instead of trying to bend the wrong one.
- thehappypm 5y agoIn actual production, corporate environments, performance isn't necessarily the most important thing. Maintainability is often much more important. Sure, a Rust system may be faster than Python, but when your lead engineer quits and your backup is on vacation, and nobody else even knows how the hell the code works, you're going to reach for something like Python or Java.
- rfoo 5y agoTry to convince those "Data Scientists" to learn Julia/Rust or spend another ten years for learning how to write non-crashy C++ then. Also, IMO Python is the right tool for glueing optimized C++ implementation of various linalg algos together. And this is exactly how we use Python. And we still have to workaround GIL. Yes, it is that bad. <rant> Glue codes could be slow, but they must scale. They should not unnecessarily contend for a stupid lock. GIL is really a scalability bug and I do acknowledge it is a hard-to-fix one due to the world's legacy codebases depends on it. However when someone applies an absurd amount of computer science (the design OP posted is literally based on state-of-the-art PL research), you should at least be sincerely curious why people are being so serious about it. </rant>