7 ms·

If you're going to rewrite large chunks anyway, I'd use Go from the start.

• carlmr 2y ago
  This is something I find quite fascinating. I've seen so much time wasted on Python this way it's incredible. Insanely smart optimizations done. But then you rewrite the whole thing in vanilla Rust without profiling once and it's still 20x faster, and much more readable than the mix of numpy vectorization and C-routines. It's kind of knowingly entering a sunk-cost fallacy for convenience. Before the cost is even sunk. Python is often just the wrong choice. And it's not even that much simpler if you ask me. In a language where you use value-based errors, have powerful sum types and strong typing guarantees, you can often get there faster, too IMO, because you can avoid a lot of mistakes by using the strictness of the compiler in your favor.
  • lpapez 2y ago
    > Insanely smart optimizations done. But then you rewrite the whole thing in vanilla Rust without profiling once and it's still 20x faster, and much more readable than the mix of numpy vectorization and C-routines. I'd argue that if you can rewrite the whole thing in Rust (or any other language), then it's not really a large project and it doesn't matter what you originally wrote it in. On multiple occassions I had to port parts of Python projects to C++ for performance reasons, and the amount of code you have to write (and time you need to spend) is mind blowing. Sometimes a single line of Python would expand to several files of C++, and you always had to redesign it somehow so that memory and lifetime management becomes feasible. Python is often the right choice IMO, because most of the time the convenience you mention trumps all other concerns, including performance. I bet you would get tons of examples from people if you "Ask HN" about "how many quickly written Python prototypes are still out there years later because their C++ replacement could never be implemented on time?"
    • maccard 2y ago
      There's a huge swathe of languages between Python and C++. On threads about Node's performance (which is somewhere in between) people regularly say that it's unfair of developers to solely focus on devex, which is the argument here. > On multiple occassions I had to port parts of Python projects to C++ for performance reasons, and the amount of code you have to write (and time you need to spend) is mind blowing. Sometimes a single line of Python would expand to several files of C++, and you always had to redesign it somehow so that memory and lifetime management becomes feasible. Part of that is because it's designed for python. Using this benchmark example, the python code (without imports) is 36 lines and the go code is 70. Except, we're doing a 1:1 copy of python to go here, not writing it like you would write go. Most of the difference is braces, and the test scaffold. I'd also argue the go code is more readable than the python code, doubly so when it scales.
      • rbanffy 2y ago
        > it's unfair of developers to solely focus on devex, which is the argument here. For most companies and applications, developer time is many orders of magnitude more expensive than machine time. I agree that, if are running applications that run across thousands of servers, then it's worth writing it in the most performant way possible. If your app runs on half a dozen average instances in a dozen-node K8s cluster, it's often cheaper to add more metal than to rewrite a large app.
        • PhilipRoman 2y ago
          There is more to it than just time. If your app is customer facing (or even worse, runs on your customer's own resources), high latency and general slowness is a great way to make your users hate it. That can cost a lot more than few days of developer time for optimization.
          • rbanffy 2y ago
            There is, of course, a limit. OTOH, if your devex is so terrible you can’t push out improvements at the same cadence of your competitors, you are doomed as well.
    • visarga 2y ago
      It all depends on execution time. If you run it just a few times or the total execution time doesn't take days, you can do it faster in Python end-to-end.
    • KolenCh 2y ago
      I have an example to support: https://github.com/hpc4cmb/toast/pull/380/commits/a38d1d6dbcc97001a1ad1c315bb08cf1eecc74c7?diff=unified&w=1 https://github.com/hpc4cmb/toast/pull/380/commits/a38d1d6dbc... A one-liner in Python is replaced by hundreds of lines of changes to implement in C++. (The one-liner has some boilerplates around it too, but the C++ function itself is longer and the boilerplates around is even more.) Edit: 230 additions and 36 deletions in 14 files.
      • maccard 2y ago
        That’s replacing one line which calls a a third party dependency with a manual implementation in native code.
        • KolenCh 2y ago
          Technically right, but the original code only optionally depends on Numba, and Numpy is ubiquitous in scientific Python. The problem I was trying to solve in all those boilerplates is basically that Numpy still has overhead and dropping it to lower level is trivial if Numba is used, but the package maintainers doesn’t want to introduce Numba dependency for various reasons. And the diff is showing that change from Numpy/Numba to C++ with pybind11.
          • maccard 2y ago
            That doesn't change the fact that it's not representative of how many lines something takes in python vs C++. If you replaced it with a call to native that used a third party library it would be back to being one line.
            • KolenCh 2y ago
              First, no sane mind will think one single example will be representative to anything. Second, if you want to focus on 3rd party or not, sure. But you could also think Numba jit vs C++ and in this case it puts them on a more equal footing to compare them. As far as Numba is concerned, numpy is in its stdlib as it aren’t calling Numpy but jit compile it. You may say Numba is not Python, true, but you could consider Numba an implementation of a subset of Python. We can argue about the details but the example is not that long to read. My summary and your summary are both at best distilled through our own point of view a.k.a. biases. Anyone can read the diff itself to judge. That’s why I link to it.
  • Quothling 2y ago
    > I've seen so much time wasted on Python this way it's incredible. It sort of goes both ways. You'll see a lot of time wasted on Python when the developers probably could have know it would need better performance. On the flip side you also see teams choosing a performant language for something which will never need it. One of the reasons I've come to prefer Go over Python is that you sort of get the best of both worlds with an amazing STL. The biggest advantage is probably that it's harder to fuck things up with Go. I've seen a lot of Python code where the developer used a List rather than a generator, loops instead of build in functions and so on. That being said, I think we'll see a lot more Rust/Zig/C/C++ as things like ESG slowly makes its way into digitalisation decisions in some organisations. Not that it'll necessarily making things more performant but it sounds good to say that you're using the climate friendly programming language. With upper management rarely caring about IT... well...
    • maccard 2y ago
      That reasoning is why I mentioned go - .net is another ecosystem that offers excellent bang for buck.
  • v3ss0n 2y ago
    You can enforce strict typing by using MyPy and Rust. Those are part of modern python development stack. If your program can be rewritten in python you are definitely not developing Fullstack Web Development or DataScience / Machine Learning. Rust isn't good at those since there are no good framework for DL/ML stuff - and working with unstructured data is very much necessary in those field where it is against Rust .
    • v3ss0n 2y ago
      i meant Ruff in first line.
  • sgarland 2y ago
    A lot comes down to familiarity, to be fair. I’m not a SWE by trade, I’m an SRE / DBRE. I can read code in just about any language, but the only one I consider myself really good in is Python. I could and should learn another (Rust seems very appealing, yes), but at the same time, I find joy in getting Python to be faster than people expect. C being leaned on is cheating a bit, of course, but even within pure Python, there are plenty of ways to gain speedups that aren’t often considered.
  • albrewer 2y ago
    > But then you rewrite the whole thing in vanilla Rust without profiling once and it's still 20x faster The main reason Python is used is because developer time is expensive and computer time is cheap. When that balance shifts the other way (i.e. the compute slowdown is more expensive then the dev time), Python is no longer the right choice. There's no point in developing at half speed or less in Rust compared to Python if your code only runs a few times, or if the 20x performance gains only results in 60 minutes of total compute time saved.
    • carlmr 2y ago
      >There's no point in developing at half speed or less in Rust compared to Python In a lot of cases the Rust development speed is faster IME, because you can really get the correctness on the first go much more often than with Python. Also proc-macros make dealing with serialization and deserialization or CLI parameters a breeze.
      • albrewer 2y ago
        > because you can really get the correctness on the first go much more often than with Python Helpful only when you have a full-ish picture of the problem ahead of you and know what's correct when you start programming.
• sgarland 2y ago
  I dislike Go as a language for a variety of reasons, but nothing really objective. I can agree with your sentiment that if performance is important from the outset, that writing everything in a language more performant by default is a smart move. In a particular case for me, the project evolved organically, and I learned performance bottlenecks along the way. The actual functions I rewrote in C were fairly small.
  • maccard 2y ago
    If you dislike go, then c# is another great alternative. I chose go because it’s fast, simple and the iteration times for go are often quicker than python apps in my experience