David Adeneye Abiodun
Jul 12, 2022 ⋅ 6 min read

Rust vs. Python: Could Rust replace Python?

David Adeneye Abiodun David Adeneye Abiodun is a software engineer and technical writer with a passion for making the web accessible for everyone.

Recent posts:

Dom Scandinaro Leader Spotlight

Leader Spotlight: Leading by experience with Dom Scandinaro

We spoke with Dom about his approach to balancing innovation with handling tech debt and to learn how he stays current with technology.

Jessica Srinivas
Nov 30, 2023 ⋅ 6 min read
Vite Adoption Guide Overview Examples And Alternatives

Vite adoption guide: Overview, examples, and alternatives

Vite is a versatile, fast, lightweight build tool with an exceptional DX. Let’s explore when and why you should adopt Vite in your projects.

David Omotayo
Nov 29, 2023 ⋅ 16 min read
Implementing Advanced Features With The Navigator.Share API

Implementing advanced features with the navigator.share API

Explore advanced capabilities for content sharing with the navigator.share API, including dynamic content sharing, custom share targets, and batch sharing.

David Omotayo
Nov 29, 2023 ⋅ 10 min read
Chas Peacock Leader Spotlight

Leader Spotlight: Scaling for the next phase of growth with Chas Peacock

We spoke with Chas to get his insights on building technology and internal processes for companies that are scaling quickly.

Jessica Srinivas
Nov 29, 2023 ⋅ 7 min read
View all posts

44 Replies to "Rust vs. Python: Could Rust replace Python?"

  1. This article reminds me of a flat earther projecting that his “believe” finds widespread adoption within the next couple of years.

  2. First of all 0.0086ms is 0.000086s.
    Secondly, use list comprehension, numpy or Numba, they exist in Python for that reason.
    If you do that you will get a performance close to Rust performance.

    Finally, I like Rust, but it has nothing to do with Python use cases. If you work on big data, pyspark, computer visions projects, you know that comparison between Rust and Python is absolutely none scenes.

  3. This article must be a joke. Even the most amateur developer knows that the two languages have completely different domains that do not intersect. Rust chances to replace Python are no more than C++ replacing VBA. Python is about simplicity and high level tasks. Rust is a modern take on C++. I fail to understand how a comparison can be drawn on the first place.

  4. Rust is no doubt accelerating in popularity but I doubt it will ever pass python. Primarily because of options simplicity to learn. In an ideal world everyone would learn rust instead of python and we would have faster and more reliable code bases.

  5. For Python, result ils 0.0086ms so that to say 0.0000086 s !
    Rust result is 0,0000046 s.
    On this test, Rust is twice faster. And if you suppress Python module loading time, Python is as faster as Rust…..

    For performance comparison, you must try differents tests with differents cyclomatic complexity, and different compilation options. In Python you need to perform a lot of tests or suppress modules loading time. Or don’t speak about performance, but end to end time.

  6. What… No it could not. You don’t use Rust and Python in the same situations and for the same purposes and you know this perfectly well, you even explain it yourself in your post.

  7. There’s something wrong with your benchmarks.

    “It took Rust 0.0000046 seconds to complete the task compared to 0.0086 seconds for Python.
    It is evident that Rust outperforms Python.”

    The python output states: “It took 0.0086ms to search”. That’s 8.6 microseconds.

    I’d also suggest running something that takes at least a few seconds to complete. As too many factors could easily eschew the results of such a miniscule time frame.

  8. Please verify the time comparison between rust and python execution… I think there is conflict between second and milliseconds

  9. There is a mistake, in your Screenshot the python O(logn) Programm took 0,0086milliseconds but later in the article you were talking about 0,0086 seconds. So actually the rust program was just twice as fast.

  10. There is no logical way Rust could or would replace Python. They’re completely different languages with different purposes.

    Python is a high level language that is designed to be incredibly readable. It’s interpreted, which makes it usable (and extremely powerful) as a scripting language, something Rust can’t do. Its popularity in AI and Data Science is driven by how easy it is for someone who isn’t a full-time developer to write and understand, while the underlying libraries (tensorflow, numpy, etc) are written in C to give the performance of a native language with the usability of Python.

    Rust is designed to be a high performance, memory safe language without garbage collection for writing system code and applications. You could use Rust for Data Science, but the learning curve would be much steeper and if all you’re doing is creating bindings to existing frameworks, what’s the point?

    It’s nonsensical to consider replacing Python with Rust. A Python interpreter written in Rust however, is a lot more interesting to think about (e.g. RustPython).

  11. When you compare speed for O(logn) programs in Python an Rust I think you did a mistake in conclusion. In Python the script need 0.0086 ms to complete.”ms” stands for millisecond not second as you said in your conclusion. So the Python script take 8.6 micro seconds to complete and the Rust one 4.6 micro seconds. So yes Rust was quicker but not as you stated in your conclusion…

  12. Hi David, really interesting article! 🙂

    I think there is a little mistake in your first benchmark.
    Console output:
    Python: 0.0086 ms
    Rust: 4.6 us

    So basically it’s 8.6 us VS. 4.6 us (~2x speed-up), not 8.6 ms VS. 4.6us (~2000x speed-up). So either the units are wrong in the benchmark or in the text.

    Would be interested in the actual speed-up, though!

  13. Check your units on performance. 0.0086 milliseconds is 8.6 microseconds, so your example shows a 2x performance gain in Rust, not the orders of magnitude you’ve shown in your analysis.

  14. No, just read your examples, the Python array search is indeed slower but that syntactic mess is exactly why I chose Python. Your article has confirmed my choice, thanks.

  15. There is a mistake in error checking paragraph. Python code is written without any mistakes and it’s output should be clear. Also, presented traceback output clearly indicates the error, giving its name + description, what a developer needs. I would recommend author to read Python official docs and practice more if he wants to become a better programmer, because all these indicate that he is a complete idiot in this particular language.

  16. Sorry to say but these benchmarks are meaningless.

    1. Rust benchmark is a dev build. Use –release: it’s a huge amount faster. Dev is unoptimised.
    2. You can’t measure a single shot, especially with python
    3. Millisecond and microsecond confusion
    4. Have to use a variety of inputs and many thousands of samples: find different numbers each time in the search.
    5. System timer can be quite inaccurate (pretty sure that’s what datetime in python means)

    Benchmarking is hard, and I hardly ever see it done correctly. Experiments are hard to get valid results out of, in general.

    The best approach is to use some proper tools to do this stuff, and follow the advice carefully. Criterion for Rust is good. I forget what the Python options are, but they’re there too. They address the sampling issues, timer accuracy, etc.

  17. You write about the Olog(n) program example: “It took Rust 0.0000046 seconds to complete the task compared to 0.0086 seconds for Python”, but the code snippet for Python returned “It took 0.0086ms to search”. So the execution speed difference seems a factor 2 different, not a factor 2000. That is an important difference if your main argument boils down to execution speed of Rust VS Python.

  18. Surely you must be joking? You can replace Rust with Java, or Go, or even C++, and the arguments would still hold; and yet none of those languages have replaced Python and so neither will Rust, just as none of those languages have replaced, or will replace sh/bash, for similar reasons.

    Also, you may want to measure the wall clock with time for both Python and `cargo run` — it could well turn out that Python was overall faster since it didn’t have to spend time on optimization.

  19. If I read the graphs correctly, it looks like Rust has actually slipped in popularity by a couple percentage points as the language programmers want to learn next from 2019 to 2020. You need to compare the lengths of the bars, not the order it appears in a unsorted list. And ditto on the performance metrics snafu. This article presents evidence that contradicts its claims leaving any sharp reader with the sense that the author shouldn’t be a writer.

  20. It is possible that Python is replaced by another interpreted language, but it is silly to say a compiled language replaces Python. Every one know that compiled languages run faster than interpreted ones, but there still exists a lot of interpreted languages next to compiled one without being replaced. There are cases that runtime speed is not so important as development time and people have to invent interpreter languages for it.

  21. Same. Also, there is a bug in Python example, where author tries to throw an variable error ‘aple’, but the code has everything spelled right, so there should be no error in console output.

  22. Wow, this article has already been ripped to shreds, but I want to add one more thing. As someone else pointed out, the benchmark test is completely meaningless since it’s such a small sample. However, even if it’s accurate and if Rust is two times faster than Python when accessing some memory (which probably isn’t the case), the likelihood of that making a measurable difference in a real application is slim. With the exception of compute-heavy applications, the biggest bottleneck is likely to be IO. Having the fastest sorting algorithm in the world doesn’t matter when your code is twiddling its thumbs waiting to load a file or get the results of a database query.

    Why must we endure so many “I like this more so I’m going to tell the internet it’s better and will win” articles? Please stop.

  23. The performance test is just completely wrong. The binary search has complexity O(log n), but the initialization of the array is O(n), so you are basically measuring array initialization time only.

    Moreover, the published python code does not seem to be complete.

  24. Python doesn’t do garbage collection. CPython (aka python, the default implementation) uses reference counting, which is why it needs the Global Interpreter Lock.

    IronPython and Jython (.NET and Java based Python respectively) use garbage collection.

  25. Finally someone who makes sense. Obviously, comparing these two is idiotic. Nobody will use Rust instead of Python. They are completely unrelated in their use. Python is slow but easy to use, Rust seems a bit faster, although this here example script is probably irrelevant, cuz being twice faster than Python still means horribly slow.. but Rust is ugh, hard to read, hard to write. It’s like comparing apples and airplanes.

  26. It looks like the author fixed the runtime comparison error in their writing, but the code examples are still riddled with errors.

  27. Python is as simple as a programming language can get. On the other hand Rust is low level, systems language. I used it a bit and it takes time to get a handle on. I don’t see what simplicity you’re talking about

  28. CPython has had garbage collection for several years. It still has reference counting, which can be used to delay (or even eliminate) garbage collection.
    It still has the Global Interpreter Lock, for reasons that have nothing to do with garbage collection.

  29. I’d love to use Rust more, but the lack of dictionary support is painful. Yes, you can use hashmaps and jump through hoops to create objects that work a bit like proper dictionaries, but all that extra work means third party libraries (crates?) don’t use them for results in regex or sql queries. And if you’ve ever used languages with dictionary support for queries, you know its rough to go back.

  30. Rust has 0 chance of replacing Python.

    The actual competition for Rust isn’t Python, but C, C++, GO, etc…

    People who use Python usually don’t care about absolute speed. Or rather they care more about development productivity over run speed. Unless your program has some massive computing tasks to do or has to run on severely constrained hardware run times like in the example are utterly irrelevant.

    The power of Python is its readability and productivity – the run speed only needs to be ok. And it’s usually more than ok and can relatively easily be optimized by using a specialized module (which then is written in C or Rust) for the tiny parts that actually need to run extremely fast. And mostly you don’t even need that.

    But if your function is not called a zillion times in a loop its run speed is usually of next to no importance.

    Nobody will write the Linux kernel in Python. But most applications don’t need what Rust and C++ can do. And with Python you get quickly to running applications whose code is very easy to read and understand. *Much* easier than Rust.

    That the speed part is not that relevant has already been proven by C or Cpp failing to eradicate Python. To the contrary actually.

    Rust’s improved error messages are nice, but they are not an inherent part of the language. You could do the same in Python – or most other languages.

    Compiler vs interpreter has different trade-offs. With compiled Rust you get speed which you often don’t need. With Python interpreter you get repl and introspection

    Rust is a cool language. But I wouldn’t use it for the kind of programs I currently use Python for.

  31. IPython as hell ,here but , ya I agree, Rust is a monster, i
    t is highly valued in blockchain technology. Youngest startupss have already taken advantage of this.
    Web3 is tomorrow …

Leave a Reply