Programming language experts like to claim that syntax doesn't matter, that semantics is all that counts. Don't believe them! They're overrotating on a common, pre-rigorous misunderstanding of language design as superficially aesthetic. The study of semantics does provide deep insights into the mechanics of languages—but the mechanism is not the mental model. Design requires engaging with the way people express their programs, and syntax is a "tool of thought".

One of my favorite insights about syntax design appeared in a retrospective on C++ by Bjarne Stroustrup:

For new features, people insist on LOUD explicit syntax.

explicit syntax. For established features, people want terse notation.

I call this Stroustrup's Rule. Part of what I love about his observation is that it acknowledges that design takes place over time, and that the audience it addresses evolves. Software is for people and people grow.

A cynic might take the rule as license to do anything, since it seems like someone will always be mad anyway. But I think Stroustrup's Rule is really begging designers to plan for growth and layer their abstractions over time. This allows designs to start at lower layers and be more explicit, but gradually introduce more concise idioms at higher layers over time.

Rust has demonstrated a nice case in point with its error-handling story. As a systems language aiming for low-level control over performance and maximum portability, Rust opted for explicit error types rather than exceptions:

let file = match File::open("file.txt") { Ok(file) => file, Err(err) => { return err; } }

This was a fine starting point, but it does not take long to feel yourself drowning in error-handling boilerplate. So Rust designers developed an idiom for concisely propagating errors outwards with a macro called try! :

let file = try!(File::open("file.txt"));

More recently, Rust shipped an even more concise notation for error propagation, the postfix ? operator:

let file = File::open("file.txt")?;

Even with a couple years of Rust ecosystem growth, there were still people uncomfortable with this level of conciseness in the RFC discussion thread. As Stroustrup's Rule suggests, it likely would have been far more difficult to propose the feature on day 1.