Should programming languages be safe or powerful?
Whether programming languages should prioritize safety or raw power draws sharply divided views here. Some argue for safe-by-default designs that prevent common errors and improve robustness, noting that humans routinely fail to write secure C/C++ even with expertise, while others insist safety is primarily a matter of programmer skill and good engineering practice. Examples from Rust, Racket, Zig and Ada are used to show that strong safety guarantees and expressive power can often coexist, but participants also stress that broader issues—like specifications, tooling, and industry maturity—matter at least as much as language choice for building reliable software.
Safety vs Power Tradeoff
- Many argue safety and power are not inherently opposed. High‑level features (e.g., APL‑style array ops) can simultaneously increase expressiveness and eliminate entire bug classes.
- A narrower view sees conflict only when accessing low‑level, hardware‑specific features; here portability vs. safety is the real tension.
- Some participants insist languages should be safe by default, with explicitly marked unsafe regions. Others prioritize raw power and accept that unsafe constructs are sometimes necessary.
Role of Languages vs Programmers
- One camp: unsafe languages can’t be used “safely” in practice; humans are too error‑prone, as evidenced by persistent C bugs even in expert code.
- Opposing camp: safety comes from programmer skill and discipline, not from the language; “guard rails” risk masking bad habits.
- There’s discussion of robustness (graceful handling of bad inputs) vs correctness (meeting specs on valid input); safe languages tend to enforce robustness as a default expectation.
Racket, Macros, and Expressiveness
- The article is seen as mostly an ode to Racket, immutability, and its macro system rather than a deep exploration of the tradeoff.
- Some praise Racket as combining Lisp/Scheme expressiveness with safety, including typed variants and safe macro‑based type systems.
- Others note macros (in Lisp, C++, Rust) can be hard to read and reason about, though still powerful.
Systems Programming: C, Rust, Zig, etc.
- The claim “C is great for drivers” is strongly challenged. Alternatives suggested include Rust, Zig, C++, Nim, depending on platform support.
- Even where C is the only official option, some argue it should be seen as a necessary evil, not “great.”
LLMs, Static Analysis, and Safety
- One view: LLM‑integrated IDEs could turn unsafe languages like C into effectively safe environments by detecting dangerous patterns.
- Skeptics counter that probabilistic tools can’t replace formal methods and that C is “unsafe by design.” AI may help migrate to safer languages or improve analyzers, but doesn’t fix C’s core issues.
Software Engineering Perspective
- Several comments argue that language choice is secondary to proper engineering: clear specs, modeling domains correctly, and rigorous testing.
- Comparisons to civil engineering highlight how immature software practice and standards still are, especially for safety‑critical systems.