11 ms·
Yes, definitely a good approach as well. One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages
by pbourke 7y ago
Yes, definitely a good approach as well. One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal.
On my team, we've been successful with this rough approach:
1. write a prototype in Python to explore the idea/ensure correctness
2. extract the core library and re-implement it in Rust
3. consume the core from Javascript via WASM and Python via pyo3 (Python/Rust bindings)
- FpUser 7y agoOne point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal. Interestingly I've found something quite opposite for computational algorithms. The problem was that execution of Python under debugger was unbearably slow for me (I used VS Code for this case). So waiting until the code gets to the point I need was not fun. With C however it would get there almost instantly. Compile time for isolated computational function was nearly instant as well. Maybe debugging under VS code was the culprit but I did not feel that for this particular task Python was any more interactive than plain C.
- pbourke 7y agoYes, I can see that being tiresome. Our projects are closer to simulations, so rather than focusing on a tight core at first, we have a number of factors that can be in play during each time step. Rather than worry about figuring out structures for our simulation objects like we might need to do in a lower-level language, Python lets us just throw together some numpy arrays and dicts as needed, and really iterate quickly on the solution. If I was working on something with a tight computational core I would probably take the low-level first approach like you have. Horses for courses, and all that.