TL;DR
Why Rust isn’t always the answer — and how to make smarter, cost-aware decisions about when and how to change languages. This post introduces a practical framework for evaluating software rewrite decisions using real-world factors like developer effort, learning curve, runtime performance, and memory safety trade-offs.
You’ll learn:
- Why “dollars per byte” (from Jim Gray’s classic economic model) still applies today
- How to estimate the cost of switching programming languages
- When it’s better to stick with dynamic languages like Python, Lisp, or Scheme
- Why rewriting in Rust may be premature for many real-world projects
- How fil-c, a GC-enhanced C/C++ extension, can deliver memory safety with minimal disruption
- How tools like AddressSanitizer and UBSan can solve 80% of memory bugs—without a full rewrite
This post is for CTOs, architects, and senior engineers who want a clear, economic approach to software rewrite decisions, without falling for hype or overengineering.
Introduction
In modern software development, we’re often told:
“Rewriting in Rust will solve your safety and performance problems.”
But language switching — especially rewriting large systems — is not free. It carries hidden costs in:
- Developer retraining
- Debugging regressions
- Lost velocity
- Technical debt handoffs
This post introduces a thinking framework:
Programming Language Switching Economics
Inspired by classic work like Jim Gray’s 2003 paper "Distributed Computing Economics", which uses:
- Instructions per byte (IPB) to measure computational density
- Dollars per byte to estimate real-world system cost
Let’s break it down into three layers:
- The cost of modern software development
- Language learning economics
- Rewriting cost vs payoff
The Real Cost of Modern Software Development
Modern software has two major costs:
- Human effort
- Machine effort
To unify both into a measurable lens, we introduce:
Dollars Per Byte = (Dev + Maintenance + Runtime + Rewrite) / TotalBytesProcessed
You don’t need precise values. It’s a thinking tool.
This allows you to ask:
- “Is our runtime too expensive per byte?”
- “Is our development effort justified?”
- “Should we optimize or rewrite?”
Language Learning Economics
Switching languages impacts team velocity.
Key Insight:
Learning a new language is not just syntax — it's tooling, debugging, deployment, library fluency, and team buy-in.
For a startup or product in active development:
- Switching to Rust may mean delayed shipping
- Retrofitting with fil-c may mean minimal code changes with memory safety
- Sticking with dynamic languages may mean faster iteration and survival
Economics of Rewriting
When does a rewrite pay off?
Use this formula:
OldTotalCost > RewriteCost + NewTotalCost
Components:
Rule of thumb: Rewrites only pay off when runtime or maintenance savings greatly outweigh the transition costs.
Use Sanitizers to Improve Memory Safety — No Full Rewrite Needed
Before rushing into rewriting your entire codebase in a new language, remember:
You don’t always need a whole new language to get memory safety.
Tools like AddressSanitizer (ASan), UndefinedBehaviorSanitizer (UBSan), and ThreadSanitizer (TSan) provide powerful, lightweight runtime checks that catch many common bugs in C and C++.
Why Use Sanitizers?
- Easy to enable: Just add sanitizer flags to your CI pipeline and compiler settings
- Incremental safety: Catch memory leaks, use-after-free, buffer overflows without rewriting code
- Low overhead: Minimal runtime cost during testing and CI — no need to slow down production builds
- Faster feedback: Detect bugs early, before they reach users or production systems
Using sanitizers helps you reduce your dollars per byte cost by preventing costly bugs and crashes — all without the high cost and risk of rewriting in Rust or other languages.
Fil-c: An Alternative to Rust That Respects Your Existing Code
fil-c is a GC-enhanced language extension of C/C++ that:
- Adds memory safety without dropping into Rust complexity
- Allows developers to keep most of their codebase unchanged
- Makes team onboarding easy for C/C++ veterans
- Works with existing toolchains and compilers
Paired with:
- Lightweight runtime checks
- Address sanitizers
- Safe allocation wrappers
You get:
- Memory safety
- Minimal rewrite effort
- Lower dev cost per byte
In contrast:
- Rust gives you safety and speed, but:
- Requires full rewrites
- Breaks legacy integrations
- Slows down early-stage velocity
The Role of Functional and Dynamic Languages
Languages like Lisp, Scheme, and Python still excel in:
- Expressive power
- Rapid prototyping
- Readability and changeability
In many domains:
- Cost per byte is dominated by developer time
- GC is not a deal-breaker
- Dynamic typing leads to faster innovation
Use these languages when:
- The system is evolving fast
- You’re still validating business logic
- Runtime cost is tolerable
Only optimize when the dollars per byte become too high.
Summary
Final Takeaway
Rewriting is expensive. Rust is powerful — but it’s not a silver bullet.
Dynamic languages and smart C extensions like fil-c may offer safer, cheaper, and faster paths to progress.
Use “dollars per byte” and “language learning cost” as your compass — not trends or cargo cults.
Refs:
Distributed Computing Economics - Jim Gray
Make C/C++ programs memory safe without changing any code
Filip Pizlo on fil-c's unstoppable GC
What is Stack-Use-After-Return
