Yea, it’s just encapsulation. Rust gives you some additional tools for achieving it though. Enums are very useful for this, as are the rules for handling shared and mutable references.
For some examples, imagine an HTTP server that answers requests from clients. You might imagine having a Response object that lets you set headers and the body, with a send method that sends the response back to the client that made the request. It would be an obvious sort of error to send the thing twice, so in C you would assert that send was only called once. In Rust, on the other hand, the send method can _consume_ the Response object. This takes it away from the caller, so the compiler will ensure that they can’t even write code with two calls to the send method. You can’t enforce this at compile time in C because in C all methods take a simple pointer to the object to act on.
Another invariant that you might want to enforce is that only one body gets attached to the Response, that the body is attached before the Response is sent, and that the user cannot forget to attach a body. You would start with a Response object that has methods for adding headers. It would also have a method that attaches a body. This body method would _consume_ the Response and return a ResponseWithBody object. The ResponseWithBody object doesn’t have any methods for adding headers, or for adding a body, so several of our requirements are now checked by the compiler. It does have the method for sending the response though, and the Response object does not. This satisfies the rest of the requirements. If you try to send a Response, it’ll fail to compile. If you try to add headers after the body, it’ll fail to compile. You literally just make a state machine out of types, with methods that consume one type and return another, and the compiler enforces that only valid state transitions are possible. This is usually called “typestate programming” if you want to search for more examples.
I think an object ownership system is something we should have in C. Otherwise, i am relatively unimpressed TBH. And readability of this is questionable:
With my ~2 weeks of Rust usage, that looks pretty readable. You can freely skip over reading some if not most of the boilerplate, reading just the bits actually doing the main stuff (and whatever context you desire), without fear of having skipped out on some safety-critical part.
It probably depends more on the ISP than on Netflix. Engineers over in my ISP’s subreddit are talking about how flows from Netflix jumped by over 450Gb/s and it was no big deal because it wasn’t enough to cause any congestion on any of their backbone links.
Yea, I think he has a knack for that. If you want some more I recommend a talk he gave a few years back called “Three Little Words” <https://www.youtube.com/watch?v=e1T7WbKox6s>.
Damian is an excellent writer and communicator for sure. But I don't know if it answers the question of what you would use these features in Raku for. If one wanted to compute e to higher precision, I feel like one would use a DSL. But we also don't need to compute e presently.
No, we don’t need to compute e very often; it’s value is pretty well known. The article is just showing off Raku (or Perl 6 as it was then known) by writing a small program of moderate complexity that still manages to show off some of Raku’s interesting features. Computing approximations of e is merely an interesting exercise; it’s not the point.
The question that justinator asked was what good uses Raku’s indefinite series have. This article points out that different ways of approximating e grow at different rates, so it is appropriate to associate a different range of trial values with each of those methods. Dörrie's bounds uses powers of 10 as shown. Others use powers of 2. Newton’s method uses sequential trial values, since it grows really fast:
#| Newton's series
assess -> \k=0..∞ { sum (0..k)»!»⁻¹ }
And several methods compute approximations in a single step, so they don’t take a trial value at all:
These are a lot of fun, but of course they can also be profound:
#| From Euler's Identity
assess { (-1+0i) ** (π×i)⁻¹ }
For those who are interested, the article shows off a lot of obvious syntactic features like superscripts and hyperoperators, but there are also things like classes and roles and new operators as well. It really is a nice tour.
Eh, it was struck by lightning. It lost several non–critical systems as a result. Both the HUD and the primary flight display turned off and came back on a few seconds later. Both showed numerous error messages and warnings when they came back on. Both failed a second time before he could read or understand all of the warnings. It was certainly suboptimal, but not necessarily indicative of a poorly designed or engineered aircraft. The report had several recommendations that were redacted; probably at least one of those was recommending specific fixes to make the display systems more reliable in the event of a lightning strike, or to make them recover more gracefully.
This is incorrect. He lost his HUD and the primary flight display, but not the standby instruments. Those are intended as a backup in case the other systems fail, and they did their job and kept operating. You can't use them to fire missiles or keep track of enemy anti–air radar systems, but you can use them to fly the plane, avoid terrain, and land safely. And he didn’t even check to see if they were still working before he ejected.
It’s possible. But note that there has been a lot of criticism of the F–35 since the inception of the program because it’s a multi–role fighter–bomber jack–of–all–trades that tries to satisfy everybody. Partly this is a political problem. Combat airplanes are expensive to design and need political approval. So you have to get every branch of the military to sign on to the project simultaneously, otherwise you’ll never even start. Therefore the thing has to be a ground–attack bomber for the Army, because they want to replace the Warthog. And it needs to be a VTOL for the Navy, so that they don’t have to build a supercarrier for it. And the Marines need X, the Coast Guard wants Y, the Girl Scouts really rely on Z, and on and on and on. And of course it goes without saying that you had better be able to mount any and every weapon system ever designed to the thing.
The US Navy does not operate the VTOL variant: they don't need to. The US Marines and the British and Japanese navies operate the VTOL variant (because they don't have supercarriers).
A lot of that criticism ended up being quite muted after the plane ended up being wildly successful after being put into service. It also ended up being much cheaper than the competition for many of allies that bought it as well.
Not to say that there weren't many issues with the program, but it seems like a lot of those requirements panned out.
No, the screens are a separate system from the fly–by–wire computer. You don’t throw your desktop computer out of a window just because one monitor goes out. You use the other monitor to order a replacement from IT or Newegg or whatever. In this case the F–35 has three independent displays that can all redundantly display the same information: the HUD in the pilot’s helmet, the primary display, and the standby display. The standby display is smaller and below the primary display in the cockpit, but it is designed to keep working even when everything else doesn’t. Their whole purpose is to be the backup in case the other displays fail.
> In this case the F–35 has three independent displays that can all redundantly display the same information
This is not true. The standby display is just a tiny artificial horizon by the pilot's right knee, so when HUD and primary display is out, all you're left with is your speed, altitude and attitude. This cannot in any way or form be considered "the same information" as the primary flight display of an F35B, and leaves you without a lot of control.
Whether you can limp along with such backup system depends entirely on what is going on at the time the primary flight displays go dark. In a fighter jet, that display may in some cases just tell you what angle and velocity you are going to die at. Furthermore, in challenging conditions you might have to make a decision very quickly and might not have time tuning yourself into the standby display and its degraded information.
This type of degraded backups exist in many aircrafts - you don't want the pilot of an Airbus you're in to be confronted with the plane dropping to mechanical law, or even direct law if taking off or landing, even if these modes are technically flyable and well documented.
The standby display is only “tiny” in comparison to the primary flight display, which is a 25” LCD panel. It’s actually the same size as the artificial horizon in most general aviation planes. The information shown on it was not degraded in any way. The accident investigators concluded that the pilot could have and should have relied on it to fly the plane. He just didn’t.
Furthermore, it’s not appropriate to compare the standby instruments with the alternate control law of Airbus airliners. I don't know if the F–35 has anything comparable with Airbus’s alternate law or direct law, but if it does it wasn’t activated during this incident. The pilot did not experience any loss of control of the aircraft.
But I agree with you that a lot of incidents involving Airbus aircraft have been related to alternate law. Pilots get caught out by it all the time, apparently.
As said elsewhere, it’s not that a plane can be kept in level flight with an artificial horizon that matters. As with the airbus pilots, it’s the surprise - especially when it happens in already stressful situations.
In this case we’re also dealing with an instrument SVTOL landing in terrible weather which cannot be flown with just an artificial horizon, repeated electrical failures in a short timespan, a disbelief that the aircraft correctly reverted from SVTOL to winged flight mode with all relevant instruments to confirm out - as the site says, “extremely challenging cognitive and flight conditions”. And, a manual that says if the aircraft goes out of control at low altitude, you must eject.
At a high altitude cruise it could have been flown just fine by the horizon while things get diagnosed and possibly diverted to a landing suite suitable for the remaining equipment.
> ... all you're left with is your speed, altitude and attitude.
Which is all you need. You have the same information in any other aircraft, most only have airspeed and altimeter info. An attitude indicator is of great help when you're flying through clouds so you can check that you're actually flying in level flight - it is pretty weird to find out you're actually flying banked but because you have coordinated flight you don't feel it.
Have you flown a modern fighter jet while suddenly your helmet integrated flight displays and navigation went out and you had to reorient yourself and rely entirely on nothing but your knee-mounted false horizon mid-maneuver, while attempting instrument landing under - and I quote - “extremely challenging cognitive and flight conditions” where you due to repeated electrical glitches have lost faith in the aircraft and in particular its ability to transition back from SVTOL to regular flight operation? Because that was the situation that you claim was fine.
You can keep an otherwise fully functional aircraft in stable level flight using a horizon, but that’s neither interesting nor relevant. This was not a lightweight aircraft cruising above the clouds with nothing around it.
He was doing an instrument landing at the time. When the ILS switched off, he automatically aborted the landing as trained. This is a go–around, so you apply TOGA thrust, point the nose up, level the wings, raise the gear, and climb to 4000’ or whatever is the correct altitude for the TOGA procedure at the airport you are at. He was already 1200’ above the ground and climbing when he ejected. He was in a perfect level climb, he just wasn’t looking at his standby instruments and so he lost situational awareness for a few seconds. Glass cockpit or not, the standby instruments and fly–by–wire system were completely reliable in spite of the lightning.
> He was doing an instrument landing at the time. When the ILS switched off, he automatically aborted the landing as trained.
No, if you read the report, he was on final and, for whatever reason, instead of continuing the landing procedure he decided to change the aircraft mode to vertical landing and this caused the helmet to glitch.
The redacted version of the report does not state that there was any causal link between switching to SVTOL and the failure of the HMD. Only that the HMD happened to fail shortly after he switched modes:
95. Approaching the final approach fix, the MFL made the radio call
to convert the flight to Mode 4 (STOVL) and slow the flight to 150
knots in preparation for the 100-knot slow landing. This was the last
radio call Swede 12 heard from Swede 11. [Encl (17), (19)]
98. MP reported his HMD flickered shortly after converting. Near
simultaneously, a momentary caution displayed in his HMD that he
perceived to be engine-related and then the HMD flickered out. While
MP considered missed approach options, the HMD came back. [Encl (17)]
And from the evaluation:
19. Primary factors contributing to the mishap can be traced back to
event that occurred at 13:32:05. This event induced
failures of both primary radios, the TACAN, and
the ILS. [FF 100, 101, 126-129]
20. Additionally, it is probable that the HMD and PCDs were not
operational for at least three distinct periods. [FF 98, 103, 104,
106, 114, 132-136, 141]
The book said that ejecting is the correct action when the plane is “unresponsive to the pilot’s commands“. This simple, straight forward statement turns out to be more ambiguous than they intended. Do you eject if the radio doesn’t change channel? No, that would be silly, even though the plane didn’t respond to your command to change the channel. The plane is still flyable without the radio! Common sense says that you should just land and get the radio fixed. There’s even a whole procedure that pilots have to memorize about how to land at an airport safely even if you have no radio.
In this case the pilot changed from mode 4 (SVTOL for landing) to mode 1 (normal flight) when the ILS system went offline. But because the HUD blinked on and off several times, he didn’t realize that the plane was actually transitioning back to mode 1. He didn’t wait long enough for it to finish, and without his HUD he thought that the plane was unresponsive, so he ejected. But the plane was still flyable, even if it had actually been stuck in mode 4! You probably can’t dogfight in mode 4, but you can certainly fly to your alternate airport and land.
So instead of penalizing him for following his training to the letter, they changed the manual to state that ejecting is the correct course of action if the plane is unresponsive to the pilot’s “pitch, roll, or yaw commands” specifically.
He wasn’t disciplined. But he was penalised. Which strikes me as the right balance given the facts.
There are two kinds of jobs: those where the person’s employment is more important than their work, and those where it isn’t. This is the latter. He’s still getting paid. But he should not have this responsibility. It you’re making excuses after losing a plane when you shouldn’t have, because you were following bad instructions, you should not have an operational command.
The procedures were not bad, they were ambiguous: I think most pilots understand what “unresponsive to the pilot’s commands“ means (that they should check if the plane responds to basic controls like pitch, roll and yaw before ejecting), but it leaves room to wiggle out of your responsibility by saying that you misunderstood this statement. And if someone is willing to do that, you might conclude that he is not a good fit for a leadership role...
Lots of armchair admirals in here, but as a former naval officer your answer is the correct one. The pilot should have tried the flight controls, if I had abandoned ship because my displays turned off but we could still control the helm, I’d be drummed out too.
> Also, a pilot blaming procedure for a bad call is ass covering.
Huh, is that a specific thing for military pilots? Just watched the latest MentourPilot's video and there the french equivalent of the FAA found that the pilots were told to improvise too much, and should have followed the procedures better.
Isn't this a catch22 with hindsight based judgement?
The prime rule, which supersedes all others, is to not have shit go wrong. That's more important than following any of the other rules; if you follow all the other rules, the rules which you think are important because they're written down, but miss on the prime rule, then your ass is in trouble. Even if it doesn't end your career, it will still hurt it.
When things really matter the foremost objective is never "follow the rules so your ass is covered", it's to not have a situation where that ass covering is relevant in the first place. Outcomes matter more than preforming according to the book.
Somewhere in the middle. You don't want to turn your brain off and bail out of a perfectly good airplane, but at the same time if the very first step of the checklist says “LAND ASAP” in giant red letters then maybe you should just divert to your alternate and land.
> Also, a pilot blaming procedure for a bad call is ass covering
Ultimately pilots are humans, being asked to make split second decisions. A certain percent of the time decisions are going to be bad. That is why we have procedures. In pretty much every other field we recognize that. Ignoring that fact is incompetence on the part of military command.
There are of course situations that cannot be covered by procedures, however this doesn't seem like one of them.
Oh, i think there is tremendous value in that if you can do it. However i don't think humans work that way, and what is really happening is survivorship bias. This reduces combat effectiveness as it sweeps opportunity for organizational improvement under the rug.
Yup. Some humans make okay split-second decisions. Some make great ones. That this difference is unfair is irrelevant. Nobody should be entitled to be a commander.
As a civilian, I would have expected that if there's anywhere where you're supposed to follow protocol even if it means expensive mistakes happen, it's the Marines. My mental model of the military, and especially the Marines, is that it's an organization that values discipline and prioritizes following the chain of command.
That's even more true if getting it wrong means you could die.
A pilot is expected to follow procedure when that's called for but ultimately has full responsibility and can make any call they want. Procedure is never going to cover the range of scenarios you can run against and there's no time to reach out to the chain of command when something goes wrong.
Ejecting could save you but send the plane crashing into a city, and that's just one of many scenarios.
If he was flying with instruments in bad weather and felt that he could not trust those instruments that seems like a good reason to eject since you can easily end up in the ground or a mountain. I don't know if switching modes like he did was standard procedure and if the resulting failure was unusual or not. Maybe he wasn't familiar enough with the airplane's systems. That said, there was a real failure that seems to have happened at the worst possible times.
At the end of the day, the bar is set really high for someone in this position.
A stimulator comfortably positioned at FL000 is much more amenable to troubleshooting multiple electrical failures than a tin can balancing on computer-controlled thrust differentiating, 1900 feet in the air well below stall speed.
You are missing the point. Incidents do happen, but you just don't get to fly a fighter jet until you proved in a simulator that you are capable of flying it and troubleshooting it. What the simulator does is to see if you can be entrusted with the aircraft.
Yes, but decades of experience have shown that pilots are far braver and willing to risk their skin in a simulator than they are in the air. And for good reason.
But I served three years in the Swedish army and wasn’t taught to obediently follow command when it makes no sense. I was taught to disobey illegal orders.
I can’t imagine a fighter pilot has so little authority over their actions like you describe.
Actually, the US military is successful more because they prioritize on the spot thinking and only deferring to the chain of command in specific circumstances. As much authority is pushed downwards to the lowest level possible. That’s why the military is so effective tactically, though the high level strategy lately has been rough. The war on terror was overall ineffective, for example, but the troops had a ridiculous k/d ratio. Another part of the success is from training. There aren’t many militaries who train as much as the US military.
That's because you're a civilian and you don't understand how Naval Aviation works. Reading straight from the NATOPS manual for my old aircraft: "It provides the best available operating instructions for most circumstances, but no manual is a substitute for sound judgement. Operational necessity may require modification of the procedures contained herein."
Aviators are not expected to be checklist-executing drones who "follow protocol." They are expected to have an encyclopedic knowledge of their aircraft's systems so that they know when to follow procedure, what the procedures are designed to do, and what to do when they have a situation where the existing procedures don't apply or conflict with each other.
In my old community, it was a commonplace occurrence when requalifying in the simulator for instructors to deliberately insert situations involving multiple malfunctions whose emergency procedures conflicted with each other, such that blindly "following protocol" would cause you to die.
That’s true if it’s the same organization doing both things. In the case of aircraft accidents, we deliberately separate out the investigators from everyone else precisely to avoid that problem. The investigators make recommendations for actions that should be taken to prevent future incidents of the same type. Firing the pilot doesn’t accomplish that, so the investigators didn’t recommend it. That doesn’t mean that firing the pilot is inappropriate though, only that doing that wouldn’t prevent future accidents of this type.
The procedures are never finished. They’ll be updated as needed for as long as anyone flies the airplane. The final revision could be a century or more from now, long after the airplane is out of active service. The updates it receives in that time depend on what accidents happen during that time, as well as how the systems change during that time.
I think this comment helps to contextualize the decision in a balanced fashion. If you just read the article probably you come to the conclusion that he should not have been relieved. This helps explain why he was relieved
You have a good point in that it was supposed to replace all kinds of aircraft. That was kind of its thing.
“ intended to replace a wide range of existing fighter, strike, and ground attack aircraft …”
One aircraft for the navy, marines and air force would save money was the thinking I imagine.
I remember the competition for the design many year ago (there was a Nova tv program) but haven’t been following too closely but it’s had issues filling all the roles.
It's a little too late for that. The JSF program probably should have been cancelled or completely restructured circa 1996. But now there's no remaining alternative. The inventory of legacy AV-8, F-16, and A-10 aircraft are going to be retired no matter what because they're literally falling apart and it's impossible to keep extending their service lives.
Wrong. The current unit cost for an F-35B is about $109M while an F/A-18E/F is about $55M. That's a difference of 2×, not 5×. And more importantly, the F/A-18 can't operate from amphibious ships to support Marine Corps ground forces. If it can't accomplish the required mission then the cost is moot.
It's extremely practical and a good aircraft. Not to mention cheap, now that the development costs are paid for.
There is no aircraft in history that did not have hiccups during procurement. Even "ol reliable" platforms like the Blackhawk or the F-16 had much worse reputations when they were first introduced.
I’d argue that this is exactly who you want testing potentially malfunctioning planes? The alternative leads to jocks crashing into the runway when they desperately try to control a runaway plane.
Fully agree but as usual it was more complicated than this even. Losing controls and instruments in IMC conditions could mean you're straight and level with many minutes to troubleshoot and try things off book, or maybe another attitude like a graveyard spiral towards the deck with seconds to decide. We might not have all the details to armchair fly it.
He didn’t lose the controls _or_ the instruments. He lost his HUD and the primary flight display. But the standby instrument display was still working correctly, and the fly–by–wire system was still accepting input and acting on it correctly. Sure, if those things had failed then ejecting would have been fine. But he didn’t even check them to see if they were still working or not, he just bailed out of a flyable plane.
I'm willing to give him the benefit of the doubt. I've seen too many software systems that failed in undetectable ways, and the user was disbelieved. The damn thing is fly-by-wire and if the instruments are failing for unknown reasons, then I could easily believe that the controls started glitching too, and that this isn't reflected anywhere.
Thrust is important but actually secondary to steering. You don’t necessarily bail right away if you lose thrust because you could still be able to glide to somewhere you can land. You might also be able to fix the problem. Of course if you’re already at low altitude or you’re in bad weather then you might not have a lot of time to try such things, but the rest of the time you do.
They gilde better than the space shuttle and that got deadsticked every time it got flown (well, almost every time).
The aerodynamic properties make both high speeds possible while retaining maneuverability at low speeds tend to lend themselves well to decent (for a jet) glide performance. What they trade off is stability.
Not these fighter planes. They literally need both the propulsion and an active flight computer to fly stably. Without the flight computer, they are uncontrollable. Think balancing a pencil on your finger - if your finger is immobilized or loses control, that pencil will fall almost immediately. The plane's controls are much more complex and unforgiving.
And without propulsion, they are just flying rocks. No gliding.
No. As long as it has electrical power and the flight controls are working it can remain stable and glide even with a complete engine failure. Of course the glide ratio is fairly low but it's totally possible for a skilled pilot to make a dead stick landing provided there's a suitable site nearby with acceptable weather conditions.
He was transitioning the aircraft from mode 4 (STOL) to mode 1 (normal flight) when he made the decision to bail. The wings were not generating lift - without computer control the aircraft could have rolled severely.
Pilots eject when the wings are level. If he was facing the possibility of severe uncontrolled roll (or believed he was) then ejecting now before the roll was a good call. At least so far as his wife and children are concerned.
Going from mode 4 to mode 1 on the F-35B (I don't know about the AV-8 family) has a significant portion of the flight below stall speed. I don't think that we know at what portion of the flight this happened.
And that's an insignificant detail in the rest of the post anyway, a nuance that does not invalidate the rest of the points made in the post you are replying to.
We do know at what portion of the flight this happened. It's right there in the report. The airplane was in stable forward flight, not stalled. You did not make any valid points.
> No. As long as it has electrical power and the flight controls are working it can remain stable and glide even with a complete engine failure.
I'm not so sure about that. I'm pretty sure that flight controls are directly tied to thrust, because it would be the engine that also drives the hydraulic system.
It's like that even on passenger jets. If you lose both engines, you also lose hydraulics (aside from whatever little hydraulic pressure the ram air turbine provides). I would not expect there to be a ram air turbine on a fighter jet, which would mean complete engine failure = complete loss of hydraulics = complete loss of flight controls.
Nope. While it's true that the F-35 lacks a ram air turbine (RAT), it does have an auxiliary power unit (APU) that can power the flight controls, avionics, and electro-hydrostatic actuators as long as fuel remains. It also has a battery that can power critical systems for a few minutes when all else fails.
That depends what you mean by "low". The F-35B (like any fixed-wing aircraft) is perfectly well flyable down to stall speed, and below stall speed it doesn't fly at all. For the conditions described, stall speed would probably be something close to 120kn (exact performance parameters are classified). (Some fighters can use thrust vectoring and other aerodynamic tricks to retain a limited amount of post-stall maneuverability but that doesn't really apply in this case.) In an engine failure situation, pilots are trained to trim the aircraft to the speed that will give the best glide ratio and that's going to be well above stall speed.
Vertical flight mode wouldn't be usable in a situation like this. They only transition to vertical flight at low altitude with the landing site in sight.
Every plane has what is called a stall speed, which if you go below it it loses its ability to stay in the air. Above that, even 1kt above, the plane will still fly. Also, to make sure you can fly the longest possible distance to have time to troubleshoot any issues, planes also have what is called best glide speed. If you maintain that, you’re golden.
There are a lot of factors that come into play when you lose the engine, but unless there is a serious issue, you still have control over the flight surfaces.
For some examples, imagine an HTTP server that answers requests from clients. You might imagine having a Response object that lets you set headers and the body, with a send method that sends the response back to the client that made the request. It would be an obvious sort of error to send the thing twice, so in C you would assert that send was only called once. In Rust, on the other hand, the send method can _consume_ the Response object. This takes it away from the caller, so the compiler will ensure that they can’t even write code with two calls to the send method. You can’t enforce this at compile time in C because in C all methods take a simple pointer to the object to act on.
Another invariant that you might want to enforce is that only one body gets attached to the Response, that the body is attached before the Response is sent, and that the user cannot forget to attach a body. You would start with a Response object that has methods for adding headers. It would also have a method that attaches a body. This body method would _consume_ the Response and return a ResponseWithBody object. The ResponseWithBody object doesn’t have any methods for adding headers, or for adding a body, so several of our requirements are now checked by the compiler. It does have the method for sending the response though, and the Response object does not. This satisfies the rest of the requirements. If you try to send a Response, it’ll fail to compile. If you try to add headers after the body, it’ll fail to compile. You literally just make a state machine out of types, with methods that consume one type and return another, and the compiler enforces that only valid state transitions are possible. This is usually called “typestate programming” if you want to search for more examples.
reply