Several air launch systems have been tried, with limited but non-zero commercial success. The altitude and speed you get from the plane is very small compared to the total work the rocket needs to do, so the benefit in terms of "the rocket can be smaller" is minimal. The main benefit in practice has been launching from ~wherever you like, since regular fixed launch sites usually have strict limits about the direction you have to fly to avoid people. But the economics of reusability are pushing rockets to get bigger, and no air launch system can fly anything nearly as big as a Falcon 9, much less a Starship + Super Heavy. Other scattered problems:
- 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.
You can see a similar effect after the explosion at the end of last week's Starship test flight. If you look at where the flames are coming out after the first fireball clears, it kind of pancakes under its own weight there: https://www.youtube.com/live/Zi2SU98BAD8?t=5735s
The vehicle is designed to hold all that fuel, plus whatever payload it carries on top, but it's not designed to have heavy loads attached to it in any other way. Rockets are so intensely optimized for weight that sometimes they're barely strong enough to stand upright if you fuel them the wrong way: https://www.youtube.com/watch?v=imkdz63agHY.
> 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.
I don't know anything about this particular launch, but one reason static fires sometimes load more fuel than you'd think is that the hold-down clamps aren't rated for the total thrust of the vehicle. Launch thrust is usually 1.2-1.6x the launch weight (if it's <1x you will not go to space today), so after subtracting gravity you've got 0.2-0.6x the weight acting upwards on the clamps. But rockets are mostly fuel by weight, so if you static fire it nearly empty, then that gravity term goes to ~zero, and the clamps have to hold the full 1.2-1.6x. You could overbuild them to handle that -- which isn't the end of the world, because they don't need to fly -- but it can be easier to just add extra fuel and detank it afterwards.
Bear in mind that a lot of what's happening to the tiles now is deliberate experiments to see how much weight they can shave off and how many failed tiles they can survive. Given that the vehicle is routinely surviving reentry at this point, it doesn't seem "hard" to make the tiles more robust by paying for it with added weight. The question is whether they'll have enough weight budget to pay for it? But at this point...probably? Not my area ofc.
Scott Manley pointed out that it seemed to flip in the wrong direction, with one of the grid fins passing through the plume and inducing a roll. Will be interesting to hear more about that.
Some weird nils don't compare equal to other nils. It's surprisingly easy to construct the weird kind by accident, because the conversion is automatic and invisible.
> async/await introduced entirely new categories of bugs that threads don’t have. O’Connor documents a class of async Rust deadlocks he calls “futurelocks”
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.
I question the choice of the phrase "to the Moon". I get it, it's technically true, but ~100% of normal people hear that and assume it means boots on the ground. Every single time it gets mentioned, it's immediately followed by a clarification that disappoints the audience. This isn't the sort of marketing choice that a self-confident program makes.
I wouldn't read too much into pre-1.0 versions. Folks take SemVer pretty seriously, and that makes some folks reluctant to declare v1.0 even when a crate has been in use and "mostly stable" for years. There can also be compatibility issues with a 1.0 bump if a crate's types are common in public APIs, e.g. the `libc` crate. I'm a big fan of the curated list of crates at blessed.rs, or honestly just looking at download numbers. (Obviously not a perfect system.)
I had a similar first reaction. It seemed like the AI used some particular buzzwords and forced the initial response to be deferential:
- "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."
Infant mortality was also 1.5x higher in the US than it is today. (Depending on who we mean by "we", this difference can be much larger.) Cystic fibrosis was a death sentence. "Late 90's" barely includes the development of effective AIDS treatment, though certainly not the rollout. (Maybe part of what you were getting at above, besides gay marriage.) Etc etc.
It's mixed. You get something in the neighborhood of a 3-4x speedup with SHA-NI, but the algorithm is fundamentally serial. Fully parallel algorithms like BLAKE3 and K12, which can use wide vector extensions like AVX-512, can be substantially faster (10x+) even on one core. And multithreading compounds with that, if you have enough input to keep a lot of cores occupied. On the other hand, if you're limited to one thread and older/smaller vector extensions (SSE, NEON), hardware-accelerated SHA-256 can win. It can also win in the short input regime where parallelism isn't possible (< 4 KiB for BLAKE3).
As far as I know, most CDC schemes requires a single-threaded pass over the whole file to find the chunk boundaries? (You can try to "jump to the middle", but usually there's an upper bound on chunk length, so you might need to backtrack depending on what you learn later about the last chunk you skipped?) The more cores you have, the more of a bottleneck that becomes.
It's important to think about the exact procedure you want to use for verifying something. Running with your thought experiment, let's say we publish "the root hash of the whole world" (not too far off from what Keybase did) each day in the Times. Now I open my phone to read some messages from Billy Bob, and my phone needs to get that hash somehow. This is just a thought experiment, so let's say for the sake of argument that it tells me to walk down to the convenience store, buy a copy of the day's paper, and scan a QR code on page 12. The problem with that arrangement (even in thought experiment land, where I'm happy to perform these steps every day) is that all the evil server needs to do to trick me is to put a doctored copy of the Times in that one newspaper stand. That's not the level of security we were hoping for. To get real security here, I'd need to do some sort of random sampling of newspaper stands distributed across the country, to build confidence that whatever QR code I'm seeing is the same one that everyone else is seeing. And the kicker is, everyone has to do this. We can't just pay one guy to sample the papers every day and tell us what the QR code was, because now our security depends on trusting that one guy, and the whole point of peer-to-peer security is avoiding that kind of centralized trust.
I think this is actually a great way to talk about the difficulty of the problem that Bitcoin solved, and why so many nerds were so interested in the whitepaper, long before all the real money got involved.
- 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.