{"id":486,"date":"2025-11-13T01:02:55","date_gmt":"2025-11-12T17:02:55","guid":{"rendered":"https:\/\/www.shirui.me\/blog\/?p=486"},"modified":"2026-02-09T00:44:35","modified_gmt":"2026-02-08T16:44:35","slug":"why-scientists-are-not-turning-to-rust","status":"publish","type":"post","link":"https:\/\/www.shirui.me\/blog\/2025\/11\/13\/why-scientists-are-not-turning-to-rust\/","title":{"rendered":"Why scientists are NOT turning to Rust"},"content":{"rendered":"\n

I recently read “Why Scientists are Turning to Rust<\/a>” and found myself disagreeing with its core premise. At same time, there is also a broader pattern in the “Python vs. Rust” claiming that Rust is the future of scientific area–for Python+C\/Fortran is current optimal–discourse that fundamentally misunderstands how scientific computing actually works.<\/p>\n\n\n\n\n\n\n\n

The Article’s Main Arguments<\/h2>\n\n\n\n

The article presents four key points:<\/p>\n\n\n\n

    \n
  1. Performance Benefits<\/strong>: Examples include processing genomic data with claimed speedups (e.g., 4x improvement for geospatial coordinate conversion after 2-3 months of porting)<\/li>\n\n\n\n
  2. Memory Safety<\/strong>: Citing Microsoft’s data that 70% of security bugs relate to memory safety, with compile-time error catching as a major advantage<\/li>\n\n\n\n
  3. Superior Toolchain<\/strong>: Unified tooling with Cargo, excellent error messages, and an active ecosystem (50,000+ crates)<\/li>\n\n\n\n
  4. Real-World Adoption<\/strong>: Projects like Varlociraptor, Sourmash, Terminus, and production use at 10x Genomics<\/li>\n<\/ol>\n\n\n\n

    Why These Arguments Miss the Mark<\/h2>\n\n\n\n

    1. The Performance Argument is Misleading<\/h3>\n\n\n\n

    The article’s performance examples raise immediate questions:<\/p>\n\n\n\n

      \n
    • Why not simply write performance-critical components in C\/C++ with Python bindings, following the established pattern of tools like BWA and Minimap2?<\/li>\n\n\n\n
    • Were the Python implementations properly optimized using NumPy vectorization, Numba JIT, or Cython before comparison?<\/li>\n\n\n\n
    • Are we comparing Rust against naive Python implementations or against the optimized numerical libraries that scientists actually use?<\/li>\n<\/ul>\n\n\n\n

      The reality is that scientific Python already leverages highly optimized C\/C++ libraries (MKL, BLAS, LAPACK) through NumPy and SciPy. For specialized needs outside NumPy’s domain–like string-based sequence analysis in bioinformatics and $g(r)$ with complex exclusion rules–we have mature solutions: Numba (including CUDA support), Cython, or traditional C\/Fortran extensions.<\/p>\n\n\n\n

      2. Memory Safety is a Solution Looking for a Problem<\/h3>\n\n\n\n

      The article’s emphasis on memory safety reveals a fundamental misunderstanding of scientific computing:<\/p>\n\n\n\n

      # Scientific code reality:\n- Run once, get results, move on\n- Crashes mean \"rerun the experiment,\" not \"system failure\"\n- Rapid iteration matters more than bulletproof code\n- We're not building 24\/7 services<\/code><\/pre>\n\n\n\n
      Memory safety is crucial for operating systems and web servers. For research scripts that process data and produce plots? It’s over-engineering.<\/p>\n\n\n\n
      3. The Ecosystem Question Goes Unanswered<\/h3>\n\n\n\n
      The article never addresses the elephant in the room: Why abandon decades of optimized numerical libraries?<\/strong><\/p>\n\n\n\n
      Python’s scientific stack represents thousands of person-years of optimization work. There’s no compelling reason to reimplement NumPy, BLAS, or other battle-tested tools in Rust solely for theoretical safety benefits.<\/p>\n\n\n\n
      4. Selection Bias<\/h3>\n\n\n\n
      The article only interviews Rust converts. It doesn’t ask:<\/p>\n\n\n\n
        \n
      • How many scientists tried Rust and returned to Python?<\/li>\n\n\n\n
      • Why aren’t mainstream tools (BLAST, GATK, SAMtools) being rewritten in Rust?<\/li>\n\n\n\n
      • Why isn’t the NumPy\/SciPy community moving to Rust?<\/li>\n<\/ul>\n\n\n\n
        What the Article Gets Right<\/h2>\n\n\n\n
        To be fair, Rust does have legitimate use cases in scientific computing:<\/p>\n\n\n\n
          \n
        1. Long-term production tools<\/strong>: Companies like 10x Genomics need maintainable, performant code that teams can collaborate on. Here, Rust’s advantages over C++ are real.<\/li>\n\n\n\n
        2. Excellent tooling<\/strong>: Cargo is undeniably superior to CMake and the C++ build ecosystem.<\/li>\n\n\n\n
        3. Welcoming community<\/strong>: An inclusive community does matter for adoption.<\/li>\n<\/ol>\n\n\n\n
          The Real Story: Python + C\/Fortran Remains Optimal<\/h2>\n\n\n\n
          For most scientists, the established pattern works perfectly:<\/p>\n\n\n\n
          def scientific_analysis():\n    # Python: High-level orchestration and prototyping\n    data = load_and_preprocess()\n    # C\/Fortran: Performance-critical computation\n    results = optimized_library.compute(data)\n    # Python: Analysis and visualization\n    return analyze_and_plot(results)<\/code><\/pre>\n\n\n\n
          When specialized needs go beyond libraries like NumPy, the solution hierarchy is:<\/p>\n\n\n\n
            \n
          1. NumPy vectorization<\/li>\n\n\n\n
          2. Numba JIT compilation<\/li>\n\n\n\n
          3. Cython<\/li>\n\n\n\n
          4. C\/Fortran extensions<\/li>\n\n\n\n
          5. Existing optimized libraries<\/li>\n<\/ol>\n\n\n\n
            Rust might fit somewhere around #6.<\/p>\n\n\n\n
            The Fundamental Disconnect<\/h2>\n\n\n\n
            Rust solves problems scientists rarely face:<\/p>\n\n\n\n
              \n
            • Preventing data races in concurrent systems<\/li>\n\n\n\n
            • Ensuring memory safety in long-running services<\/li>\n\n\n\n
            • Compile-time guarantees for mission-critical software<\/li>\n<\/ul>\n\n\n\n
              Meanwhile, it introduces friction scientists can’t afford:<\/p>\n\n\n\n
                \n
              • Slow compilation times<\/li>\n\n\n\n
              • Steep learning curve<\/li>\n\n\n\n
              • Complex type system<\/li>\n\n\n\n
              • Fighting the borrow checker instead of exploring data<\/li>\n<\/ul>\n\n\n\n
                Conclusion<\/h2>\n\n\n\n
                This article reads more like Rust evangelism than rational analysis. The “Python is too slow” narrative misunderstands how scientific computing works: Python serves as an orchestration layer while optimized compiled code does the heavy lifting.<\/p>\n\n\n\n
                Most importantly, the article ignores that bottlenecks in scientific computing are usually algorithmic, not language-related<\/strong>. An $O(n^2)$ algorithm in Rust is still slower than an $O(n \\log n)$ algorithm in Python.<\/p>\n\n\n\n
                For individual developers who enjoy Rust? Go for it. But claiming it’s the future of scientific computing ignores the reality of how science is actually done. The Python + C\/Fortran combination remains the sweet spot for good reasons: it balances rapid prototyping, excellent performance through mature libraries, and “good enough” safety for research contexts.<\/p>\n\n\n\n
                In scientific computing, Rust is largely a solution in search of a problem.<\/p>\n","protected":false},"excerpt":{"rendered":"
                I recently read “Why Scientists are Turning to Rust” and found myself disagreeing with its core premise. At same time, there is also a broader pattern in the “Python vs. Rust” claiming that Rust is the future of scientific area–for Python+C\/Fortran is current optimal–discourse that fundamentally misunderstands how scientific computing actually works.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,9],"tags":[],"class_list":["post-486","post","type-post","status-publish","format-standard","hentry","category-misc","category-notes"],"_links":{"self":[{"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/posts\/486","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/comments?post=486"}],"version-history":[{"count":14,"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/posts\/486\/revisions"}],"predecessor-version":[{"id":543,"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/posts\/486\/revisions\/543"}],"wp:attachment":[{"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/media?parent=486"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/categories?post=486"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shirui.me\/blog\/wp-json\/wp\/v2\/tags?post=486"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}