Rust vs. C++: A Discussion on Language Choice for Software Development
This article discusses the merits of Rust and C++ for software development, particularly focusing on the trade-offs between memory safety, development speed, and ecosystem support. The analysis stems from a reaction to an article suggesting Rust hinders success and advocating for C++.
The "Religion" of Programming Languages
The article begins by addressing the often zealous attachment programmers develop towards their chosen languages. It reminds us that programming languages are tools, not religions. The origin of the word "religion" is explored, tracing it back to the Latin word religare, meaning "to bind fast," originally referring to holding onto a rope on a ship. This analogy relates to how developers might hold onto a tool (language) in the rough seas of software development.
The Borrow Checker and Development Speed
One of the main points of contention is Rust's borrow checker. The original article criticizes it as an overly cautious feature that slows down development by requiring developers to wrestle with the compiler to achieve memory safety. This can divert time from feature development, bug fixing, and overall product testing.
The counter-argument is that the borrow checker enforces safety at compile time, preventing runtime errors and memory leaks. However, it acknowledges that even safe programs can be difficult to express in Rust, leading to frustration. The sentiment, "if you're fighting with the borrow checker, you don't know Rust," is challenged; sufficiently large projects often require navigating the borrow checker's complexities, and refactoring can be challenging.
Perfection vs. Progress and MVP Considerations
The original article claims Rust encourages writing perfect code from the start, which isn't practical for startups and fast-paced environments. It argues that rapid prototyping and testing are crucial, and time spent wrestling with the borrow checker could be better used for market validation. Most products are simple and one should use the language they are most familiar with to achieve speed.
The article author agrees that for a Minimum Viable Product (MVP), the fastest language to use is the right one, be it PHP, Python, or JavaScript. The focus should be on getting a product to market quickly to assess its viability.
Ecosystem Support and Productivity
The original article argues that C++ and C have mature ecosystems, extensive libraries, and readily available solutions, making them more productive choices. Rust's ecosystem is growing but not as established.
The response concedes that C++ and C have a longer track record. However, the article author thinks the core of the problem is the language choice between C++ and a garbage collected language. The complexity of C++ is questioned, referencing the numerous ways of handling memory and the complexities of constructors (rule of five). The point is made that complex languages, like C++, are needed to solve difficult problems, so the trade-off is worth it.
Garbage Collection and Rapid Development
The original article states that garbage collection, while criticized by some, enables faster development. Quick websocket tests in Go were highlighted as an example of how rapidly a program can be written.
The speed and ease of use of garbage-collected languages are acknowledged, agreeing that a small memory leak in a non-critical path is an acceptable trade-off for faster time to market.
Final Verdict and Language Choice
The author concludes by stating that the best language depends on the developer's familiarity and skill. For speed, choose the language you're most proficient in. Even though languages like Go may be considered "boring," their simplicity and ease of use can be highly effective for rapid development. While Rust offers strong memory safety, and C++ offers broad ecosystem support, the right choice depends on the specific project requirements and the team's expertise. It is acknowledged that Go is easy to start with, but has some hidden problems in large projects that one should read about.
{# 
{#