--- title: Software is slow because of bad design, not slow languages description: Rewriting software in a faster language like C or Rust rarely delivers the dramatic speedups people expect. Most programs are I/O-bound, spending time waiting... canonical: https://daily.dev/posts/software-is-slow-because-of-bad-design-not-slow-languages-qnqp1oxqm twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Software is slow because of bad design, not slow languages | daily.dev og:description: Rewriting software in a faster language like C or Rust rarely delivers the dramatic speedups people expect. Most programs are I/O-bound, spending time waiting... og:url: https://daily.dev/posts/software-is-slow-because-of-bad-design-not-slow-languages-qnqp1oxqm og:image: https://api.daily.dev/og/posts/qnQp1oXqm.png og:image:alt: Software is slow because of bad design, not slow languages og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Software is slow because of bad design, not slow languages **[sean goedecke](https://daily.dev/sources/seangoedecke)** · 7 min read · 7 upvotes · 3 comments ## Summary Rewriting software in a faster language like C or Rust rarely delivers the dramatic speedups people expect. Most programs are I/O-bound, spending time waiting on databases or networks rather than computing, so a CRUD app might at best get 1.5x to 2x faster from a language switch. Slow languages like Python already delegate CPU-heavy work (matrix multiplication, markdown rendering) to fast C libraries. Bryan Cantrill once rewrote a C program in Rust expecting a 20% slowdown but got a 30% speedup, due to Rust's B-tree default being more cache-efficient, showing design beats language choice. Real speedups usually come from caching, async work, parallelism, and fixing N+1 SQL queries. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Will rewriting my Python or Ruby web app in Rust or C make it significantly faster? Usually not. Most real-world programs are I/O-bound, spending roughly half their request time on database queries, so even a perfect language rewrite can only speed up the remaining portion, yielding maybe 1.5x to 2x in practice, not an order-of-magnitude gain. Real speedups typically come from caching, async processing, parallelism, or fixing N+1 SQL queries instead. _Weighing a rewrite versus a redesign? daily.dev surfaces performance engineering takes like this one._ ### Why did Bryan Cantrill's C-to-Rust rewrite end up 30% faster instead of slower? The rewrite was expected to be 20% slower because the carefully optimized C design didn't fit Rust's borrow checker, so he wrote it naively instead. It ended up 30% faster because Rust's standard library defaults to a B-tree instead of a binary search tree, and the B-tree is more cache-efficient, showing that data structure design mattered more than raw language speed. _Debating language rewrites for performance? find deep dives like this on daily.dev._ ### What are the most effective ways to speed up a slow web application? Effective fixes are almost always redesigns rather than language changes: caching slow external API calls, performing slow operations asynchronously or in background jobs, running operations in parallel, replacing multiple SQL queries with one query to fix N+1 problems, replacing a slow SQL query with a faster one, and skipping unnecessary data fetches on paginated views. _Chasing real performance wins in your app? daily.dev tracks practical optimization techniques like these._ ## Community discussion Top comments from developers on daily.dev. **@justbrowsing** · 1 upvotes > I do agree in general with the overall point of this article. However, there are points that could be better presented. > > >Most real programs are I/O-bound > > > All these decades, still not a real programmer. > > >Python is famously a slow language, but it’s a competitive choice for CPU-bound workloads like machine learning and mathematics, because it has a [healthy](https://pytorch.org/) [set](https://www.tensorflow.org/) of libraries that let it offload these workloads to fast C code. > > > "Python is fast because it delegates heavy computation to C". In short, the computation-heavy portions are... **@diyweb** · 1 upvotes > The caching and N+1 query points match what I see most often: the slow part is usually a query or a network call, not the language. A cheap first step before any rewrite is to profile one real request and see where the time actually goes. ## Similar posts on daily.dev - [Rust is the answer to the wrong question](https://daily.dev/posts/rust-is-the-answer-to-the-wrong-question-aadz2zpg8) · RUBYLAND · 0 upvotes · 0 comments - [Rust is a disappointment](https://daily.dev/posts/rust-is-a-disappointment-stnsaxzae) · Hacker News · 26 upvotes · 9 comments - [The Programming Languages AI Still Gets Surprisingly Wrong](https://daily.dev/posts/the-programming-languages-ai-still-gets-surprisingly-wrong-lbxoqyzy8) · Code Like A Girl · 4 upvotes · 1 comments - [Python Is Only Slow If You are Still Using It The Way You Learned In 2018](https://daily.dev/posts/python-is-only-slow-if-you-are-still-using-it-the-way-you-learned-in-2018-8deliqhgs) · Medium · 2 upvotes · 0 comments --- Tags: [#general-programming](https://daily.dev/tags/general-programming), [#performance](https://daily.dev/tags/performance), [#ai-agents](https://daily.dev/tags/ai-agents), [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/software-is-slow-because-of-bad-design-not-slow-languages-qnqp1oxqm) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Software is slow because of bad design, not slow languages","url":"https://daily.dev/posts/software-is-slow-because-of-bad-design-not-slow-languages-qnqp1oxqm","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/software-is-slow-because-of-bad-design-not-slow-languages-qnqp1oxqm"},"datePublished":"2026-10-22T21:17:02.944Z","dateModified":"2026-10-22T21:19:01.151Z","description":"Rewriting software in a faster language like C or Rust rarely delivers the dramatic speedups people expect. Most programs are I/O-bound, spending time waiting...","image":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","thumbnailUrl":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","isAccessibleForFree":true,"articleSection":"sean goedecke","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"sean goedecke","logo":"https://media.daily.dev/image/upload/s--WNgiZyDx--/f_auto,q_auto/v1765713419/logos/seangoedecke","url":"https://daily.dev/sources/seangoedecke"},"commentCount":3,"discussionUrl":"https://daily.dev/posts/software-is-slow-because-of-bad-design-not-slow-languages-qnqp1oxqm","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":7},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":3}],"keywords":"general-programming,performance,ai-agents,rust","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"sean goedecke","item":"https://daily.dev/sources/seangoedecke"},{"@type":"ListItem","position":3,"name":"Software is slow because of bad design, not slow languages"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/software-is-slow-because-of-bad-design-not-slow-languages-qnqp1oxqm","comment":[{"@type":"Comment","text":"I do agree in general with the overall point of this article. However, there are points that could be better presented.\n\nMost real programs are I/O-bound\n\nAll these decades, still not a real programmer.\n\nPython is famously a slow language, but it’s a competitive choice for CPU-bound workloads like machine learning and mathematics, because it has a healthy set of libraries that let it offload these workloads to fast C code.\n\n“Python is fast because it delegates heavy computation to C”. In short, the computation-heavy portions are pre-written in C. The point lands, but also misses.\n\nDespite all this, I think most software is far slower than it could be.\n\nAbsolutely agree.\n\nIn a 2018 post, Bryan Cantrill described trying to rewrite a C program into Rust. It was difficult because the carefully-optimized design of the C program did not play well with the Rust borrow checker. Giving up, he simply wrote the program in Rust in the naive way, expecting a 20% slowdown or worse. Instead, it was 30% faster. The reasons boil down to Rust’s internal preference for a B-tree over a binary search tree, which happens to be a more cache-efficient data structure.\n\nHe could likely have gotten a similar speedup for much less effort by using a B-tree in C. This is why premature optimization is a root of programming evil; he committed to a heavy re-write before knowing where the slow-downs are. I say this as a Rust fan.\n\nOther commenters point out that languages come with ecosystems that make performance harder or easier. I agree with that, but to me that falls under design: in some languages, fast designs are more natural than slow designs. If changing languages makes it easier to change designs, then sure, changing languages might speed up your program.\n\nAgreed. Rust programs tend to be faster in part because it is easier, in general, to write fast Rust programs than slow Rust programs. But it is absolutely possible to write slow Rust code. Drop an O(n^2) algorithm into Rust code and an O(n log n) algorithm into Python code and you can watch Python “outdo” Rust at around 512 items. Which is trivially easy even in gamedev.\nI think the important take-away is that a re-write needs a purpose and reason to exist; and that reason and purpose needs to justify the effort spent, and test-proven optimization of algorithms will almost always outdo anything else, including language choice. As demonstrated in the above paragraph, and because compute-heavy portions can be offloaded.","datePublished":"2026-10-24T03:27:51.700Z","dateModified":"2026-10-24T03:28:21.656Z","url":"https://daily.dev/posts/qnQp1oXqm#c-g5aItzqew","author":{"@type":"Person","name":"JustBrowsing","url":"https://daily.dev/justbrowsing","image":"https://media.daily.dev/image/upload/s--O0TOmw4y--/f_auto/v1715772965/public/noProfile"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"The caching and N+1 query points match what I see most often: the slow part is usually a query or a network call, not the language. A cheap first step before any rewrite is to profile one real request and see where the time actually goes.","datePublished":"2026-10-24T19:10:13.588Z","url":"https://daily.dev/posts/qnQp1oXqm#c-BGg4E5q3C","author":{"@type":"Person","name":"DiyWeb","url":"https://daily.dev/diyweb","image":"https://media.daily.dev/image/upload/s--dgS6jDeN--/f_auto/v1790879420/avatars/avatar_774zDwMaRTNS1fv5OKStX?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/software-is-slow-because-of-bad-design-not-slow-languages-qnqp1oxqm#faq","mainEntity":[{"@type":"Question","name":"Will rewriting my Python or Ruby web app in Rust or C make it significantly faster?","acceptedAnswer":{"@type":"Answer","text":"Usually not. Most real-world programs are I/O-bound, spending roughly half their request time on database queries, so even a perfect language rewrite can only speed up the remaining portion, yielding maybe 1.5x to 2x in practice, not an order-of-magnitude gain. Real speedups typically come from caching, async processing, parallelism, or fixing N+1 SQL queries instead. Weighing a rewrite versus a redesign? daily.dev surfaces performance engineering takes like this one."}},{"@type":"Question","name":"Why did Bryan Cantrill's C-to-Rust rewrite end up 30% faster instead of slower?","acceptedAnswer":{"@type":"Answer","text":"The rewrite was expected to be 20% slower because the carefully optimized C design didn't fit Rust's borrow checker, so he wrote it naively instead. It ended up 30% faster because Rust's standard library defaults to a B-tree instead of a binary search tree, and the B-tree is more cache-efficient, showing that data structure design mattered more than raw language speed. Debating language rewrites for performance? find deep dives like this on daily.dev."}},{"@type":"Question","name":"What are the most effective ways to speed up a slow web application?","acceptedAnswer":{"@type":"Answer","text":"Effective fixes are almost always redesigns rather than language changes: caching slow external API calls, performing slow operations asynchronously or in background jobs, running operations in parallel, replacing multiple SQL queries with one query to fix N+1 problems, replacing a slow SQL query with a faster one, and skipping unnecessary data fetches on paginated views. Chasing real performance wins in your app? daily.dev tracks practical optimization techniques like these."}}]} ```