The Feedback Loop

TC39 member here.

cwmma gets a lot right here: Promises have always been contentious in JS (and TC39) and Domenic has indeed had the patience of a saint attempting to wrangle the various points of view into a coherent proposal.

TC39 as a group is generally very motivated to find positive-sum outcomes and find solutions that address everyone's constraints in a satisfactory way. That doesn't usually mean design-by-committee: champions work on a coherent design that they feel hangs together, and the committee provides feedback on constraints, not solutions.

As a member of TC39, I'm usually representing ergonomic concerns and the small-company JavaScript developer perspective. I've had a lot of luck, over the years, in giving champions my perspective and letting them come back with an improved proposal.

The staging process (which I started sketching out on my blog[1]) has made the back-and-forth easier, which each stage representing further consensus that the constraints of individual members have been incorporated.

Unfortunately, I fear that promise cancellation may be a rare design problem with some zero-sum questions.

It's worth noting that there has been no objection, on the committee, to adding cancellation to the spec in some form.

The key questions have been:

First. Is cancellation a normal rejection (a regular exception, like from `throw`) or a new kind of abrupt completion (which `finally` would see but not `catch`). The current status quo on the committee, I…

> Of all the things I said, is that really the only one you want to address?

Yes, I guessed (correctly!) that others would inquire about the rest of the comment, I wanted the context. Thank you for taking the time to explain.

> Having said all of that, you probably think I'm in some rare position. However, it's a really big world, and you might be surprised how much sloppy C, C++, Fortran, and COBOL software is out there quietly getting the job done without the constant onslaught of black hats attacking it. We don't all write web browsers and servers. There are a lot of potentially profitable C++ targets in the finance industry, but somehow they survive.

I'm not surprised.

Your argument is something along the lines "a lot of code doesn't have particularly high security requirements" and "sandboxing/airgapping mitigates problems", which are both totally reasonable and indeed are things that Rust core team acknowledge (although the first is becoming less and less true, in "surprising" places, as more things are internet connected). Additionally, the latter is a "defense in depth" strategy that the Rust community is keen on (e.g. https://github.com/servo/gaol): it is understood that code can have bugs, inside unsafe code or not, and so limiting the interaction with things outside the program is always good.

However, neither of these facts support, for instance, an expert being able write a memory-safe regex library in C++ in a reasonable time (e.g. how long it took for…

You might be referring to this, which I think is even more accurate. Dave Herman quotes him:

https://www.thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/

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.

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.

Side note: Dave Herman is Rust's most unrecognized contributor: https://brson.github.io/2021/05/02/rusts-most-unrecognized-contributor

I often notice that the actual Rust authors and designers respect and are influenced by C++ very much. (Niko M is another C++ fan)

It's only the randoms online that like to start C++ vs. Rust arguments.

Another thing to note is that the Mozilla Rust is MUCH closer to C++ than Graydon's Rust was. Graydon's Rust was not at all about zero-cost abstraction, the shared motto of C++ and Rust.

> if you provide your own thin abstractions

Without generics these abstractions are hard to work with and hard to make work across libraries. I am reminded of https://thefeedbackloop.xyz/i-bet-that-almost-works/

> Take the rust compiler itself: AFAIK it's now implemented in C++

The compiler is written in Rust. It uses LLVM, which is in C++, for codegen, but in the future we might be able to turn that off too (https://internals.rust-lang.org/t/possible-alternative-compiler-backend-cretonne/4275/22)

Besides, the implementation language of a compiler does not make the compiler an "abstraction" over the language. Sort of, but not really.

I think ? is a perfect example of Stroustrup's Rule: https://thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/

> For new features, people insist on LOUD explicit syntax.

> For established features, people want terse notation.

I was pretty against ? when it was proposed. I liked try!. I thought ? was hard to read. I thought try! was concise enough. After writing (and reading) lots of code with ?, I'm all in. Heck, ? still isn't extendable for user-defined types, and now I want that! We made ? work in main, and in tests.

It's now one of my favorite features of Rust. YMMV.

Dave Herman has been a high signal-to-noise contributor to Lambda the Ultimate over the years; if you want to get an idea as to where he is coming from, looking at his contributions there [1], his slightly active blog [2], and on his now pretty much inactive joint blog [3] are good places to start.

[1]: http://lambda-the-ultimate.org/user/825/track?sort=desc&order=author

[2]: http://calculist.org/

[3]: https://www.thefeedbackloop.xyz/