- Hanging under-wing is a totally different set of forces than standing vertically, especially for a big rocket with thin walls. You're more like a bridge than a tower, or rather like a bridge one moment and then a tower the next. You need reinforcement for that, which makes the vehicle heavier.

- Modern reusable rockets do quick "load and go" filling to keep their propellant as cold and dense as possible. You can't do that if you need to fuel on the ground and then hang off an airplane for ~an hour while it climbs.

> The percent propellant has huge implications on the ease of fabrication and robustness in achieving the engineering design (and cost). If a vehicle is less than 10% propellant, it is typically made from billets of steel. Changes to its structure are readily done without engineering analysis; you simple weld on another hunk of steel to reinforce the frame according to what your intuition might say. I can easily overload my ¾ ton pickup by a factor of two. It might be moving slowly but it is hauling the load.

> Once the vehicles become airborne, the engineering becomes more serious. Light weight structures made of aluminum, magnesium, titanium, epoxy-graphite composites are the norm. To alter the structure takes significant engineering; one does not simply weld on another chunk to your airframe if you want to live (or drill a hole through some convenient section). These vehicles cannot operate far from their designed limits; overloading an airplane by a factor of two results in disaster. Even though these vehicles are 30 to 40% propellant (60 to 70% structure and payload), there is room for engineering to comfortably operate thus there is a robust, safe, and cost effective aviation industry.

> Rockets at 85% propellant and 15% structure and payload are on the extreme edge of our engineering ability to even fabricate (and to pay for!). They require constant engineering to keep flying. The seemingly smallest modifications require monumental analysis and testing of prototypes in vacuum chambers, shaker tables, and sometimes test launches in desert regions. Typical margins in structural design are 40%. Often, testing and analysis are only taken to 10% above the designed limit. For a Space Shuttle launch, 3 g’s are the designed limit of acceleration. The stack has been certified (meaning tested to the point that we know it will keep working) to 3.3 g’s. This operation has a 10% envelope for error. Imagine driving your car at 60 mph and then drifting to 66 mph, only to have your car self-destruct. This is life riding rockets, compliments of the rocket equation.

That's kind of horrifying. Is there a reliable list somewhere of all the functions that do that? Is that list considered stable?

I didn't coin that term, the Oxide folks did: https://rfd.shared.oxide.computer/rfd/0609. I want to emphasize that I don't think futurelocks represent a "fundamental mistake" or anything like that in Rust's async model. Instead, I believe they can be fixed reliably with a combination of some new lint rules and some replacement helper functions and macros that play nicely with the lints. The one part of async Rust that I think will need somewhat painful changes is Stream/AsyncIterator (https://github.com/rust-lang/rust/issues/79024#issuecomment-...), but those aren't yet stable, so hopefully some transition pain is tolerable there.

> The pattern scales poorly beyond small examples. In a real application with dozens of async calls, determining which operations are independent and can be parallelized requires the programmer to manually analyze dependencies and restructure the code accordingly.

I think Rust is in an interesting position here. On the one hand, running things concurrently absolutely does take deliberate effort on the programmer's part. (As it does with threads or goroutines.) But on the other hand, we have the borrow checker and its strict aliasing rules watching our back when we do choose to put in that effort. Writing any sort of Rust program comes with cognitive overhead to keep the aliasing and mutation details straight. But since we pay that overhead either way (for better or worse), the additional complexity of making things parallel or concurrent is actually a lot less.

> At the function level, adding a single i/o call to a previously synchronous function changes its signature, its return type, and its calling convention. Every caller must be updated, and their callers must be updated.

This is part of the original function coloring story in JS ("you can only call a red function from within another red function") that I think gets over-applied to other languages. You absolutely can call an async function from a regular function in Rust, by spinning up a runtime and using `block_on` or similar. You can also call a regular function from an async function by using `spawn_blocking` or similar. It's not wonderful style to cross back and forth across that boundary all the time, and it's not free either. (Tokio can also get mad at you if you nest runtimes within one another on the same thread.) But in general you don't need to refactor your whole codebase the first time you run into a mismatch here.

Comments URL: https://news.ycombinator.com/item?id=47217550

Points: 4

# Comments: 0

- "kindly ask you to reconsider your position"

- "While this is fundamentally the right approach..."

On the other hand, Scott's response did eventually get firmer:

- "Publishing a public blog post accusing a maintainer of prejudice is a wholly inappropriate response to having a PR closed. We expect all contributors to abide by our Code of Conduct and exhibit respectful and professional standards of behavior. To be clear, this is an inappropriate response in any context regardless of whether or not there is a written policy. Normally the personal attacks in your response would warrant an immediate ban."

Sounds about right to me.