3 ms·

Unless you have a clear specification for what you are going to build (as in, you have most of your data schemas and processes sketched out), stick with Python

Unless you have a clear specification for what you are going to build (as in, you have most of your data schemas and processes sketched out), stick with Python and benefit from the development velocity as you figure things out. Then rewrite it later when you need to scale.

nnadams 4y ago
I have embraced this workflow completely. I used to be more concerned about which language, but now I find I much more useful to just start immediately in Python. I spend most of the time working out the kinks and edge cases, instead of memory management or other logistics. Maybe ~75% of the time, that's it, no need for further improvement. Recently I chose to rewrite several thousands of lines of Python in Go, because we needed more speed and improved concurrency. Already having a working program and tests in Python was great. After figuring out a few Go-isms, it was a quick couple of days to port it all for big improvements.
- hsbauauvhabzb 4y ago
  When you say tests are you referring to end to end tests, did you rewrite unit tests or did you do some cross language magic?
  - nnadams 4y ago
    End to end tests mostly. Those were kept static throughout the process as a baseline and for benchmarking. That let us have simple metrics like "test 1 had a 100x speed up" and "test 3 took a way too long to finish before the rewrite." Any unit tests got rewritten along with the test's relevant code. Now that we are sticking with this Go based solution, adding more unit and regression feels more reasonable now.
alar44 4y ago
This is what I do. Hack it together in Python to get something running, then rewrite everything in C++.
- JonChesterfield 4y ago
  This works especially well if you test the python version as you go, then run the same python tests against the C++ replacement. The up front bother of pybind or similar is minor relative to not having to recompile the C++ to iterate on test scripts.
- trenchgun 4y ago
  Or even better, rewrite the python code in Rust! Like Asahi Lina did. https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/
therealdrag0 4y ago
Gp was saying their biggest complaint is better in JS and Ruby, so aren’t those just as good for velocity and not for scale?
nine_k 4y ago
The same thing can be said about Lisp, Ruby, or JS/TS. Start a REPL, shape things as you would clay. What Python gives you, and what's not easy to get elsewhere, is access to really high performance numerical code, wrapped into quite ergonomic interfaces: Numpy, Scipy, Pytorch, etc. Many other things choose to make Python the glue language, like above, or to embed it (from Gimp to Blender). This makes Python stand out, despite its shortcomings (which are well-known), and make it an even more reasonable interface language for whatever next big thing. Network effect in action.
mmcnl 4y ago
Notice the rewrite most often will never come when you do this because it will probably not be needed. And if it comes to it that you do need a rewrite, celebrate the success of your project!

nnadams 4y ago

I have embraced this workflow completely. I used to be more concerned about which language, but now I find I much more useful to just start immediately in Python. I spend most of the time working out the kinks and edge cases, instead of memory management or other logistics. Maybe ~75% of the time, that's it, no need for further improvement. Recently I chose to rewrite several thousands of lines of Python in Go, because we needed more speed and improved concurrency. Already having a working program and tests in Python was great. After figuring out a few Go-isms, it was a quick couple of days to port it all for big improvements.

hsbauauvhabzb 4y ago
When you say tests are you referring to end to end tests, did you rewrite unit tests or did you do some cross language magic?
- nnadams 4y ago
  End to end tests mostly. Those were kept static throughout the process as a baseline and for benchmarking. That let us have simple metrics like "test 1 had a 100x speed up" and "test 3 took a way too long to finish before the rewrite." Any unit tests got rewritten along with the test's relevant code. Now that we are sticking with this Go based solution, adding more unit and regression feels more reasonable now.

alar44 4y ago

This is what I do. Hack it together in Python to get something running, then rewrite everything in C++.

JonChesterfield 4y ago
This works especially well if you test the python version as you go, then run the same python tests against the C++ replacement. The up front bother of pybind or similar is minor relative to not having to recompile the C++ to iterate on test scripts.
trenchgun 4y ago
Or even better, rewrite the python code in Rust! Like Asahi Lina did. https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/

therealdrag0 4y ago

Gp was saying their biggest complaint is better in JS and Ruby, so aren’t those just as good for velocity and not for scale?

nine_k 4y ago

The same thing can be said about Lisp, Ruby, or JS/TS. Start a REPL, shape things as you would clay. What Python gives you, and what's not easy to get elsewhere, is access to really high performance numerical code, wrapped into quite ergonomic interfaces: Numpy, Scipy, Pytorch, etc. Many other things choose to make Python the glue language, like above, or to embed it (from Gimp to Blender). This makes Python stand out, despite its shortcomings (which are well-known), and make it an even more reasonable interface language for whatever next big thing. Network effect in action.

mmcnl 4y ago

Notice the rewrite most often will never come when you do this because it will probably not be needed. And if it comes to it that you do need a rewrite, celebrate the success of your project!