Had the same thought. I don’t show up on this leaderboard, but I’m #42 on the “more complete” leaderboard. I’m #8 when sorting by max in a single comment—which makes even me think I may have overdone it. Finally—HN top 50 and top 10 in something I love!
Yeah. I was there and this demo was a jolt. More so was the phrasing we were witnessing the end of our punchcard era. I don’t know if it’s the history nerd in me or what, but that thought has been living in my head ever since. Looking forward to playing with Phoenix.new—and keeping an eye out for looms to smash. Kudos, Chris.
Is this another in the string of 737 MAX issues? Or would other aircraft have experienced the same event under the same conditions?
Edit: Aplogies for asking about content that was obvious, but behind a paywall. Thanks to the archive link shared, it sounds like it was (inexperienced) human error.
Seriously, after seeing several Boeing engineers saying they wouldn't fly on a Boeing aircraft, and seeing how their management has handled their crises, I'm not flying Boeing. That company needs a major restructure and "come to Jesus" moment before I'll ever trust them again. So far, that isn't even on the horizon.
I'm all for backing the regulatory pressure that has allowed this constant improvement (consider that flights per year have increased while the trendlines in those graphs have decreased) but I'm going to need to see that accident number reach about 100x what it is right now before I care about it enough to personally switch flights. The commercial aerospace side of Boeing has over 10,000 engineers, several of them have probably said we didn't land on the moon too. The way their management has handled decline in their record is at least a fair point just not nearly bad enough yet for me to really care as often as articles about it get posted here or enough to switch flights yet.
Was just playing with some other NTSB statistics and noticed the graph range doesn't shrink to fit, here's the continued risk decline: https://i.imgur.com/gKomsVa.png
I've had similar thoughts, but how does that work for you in practice?
If you book a flight that says it's an airbus plane and then you show up and the airline had to sub in a boeing plane, do you just cancel your trip?
If you don't have the expensive tickets that allow same-day rebooking, I can't imagine any airline would humor an attempt to get a refund or to have them waive a rebooking fee.
Similarly if you're traveling for business and your company has paid for the ticket, some companies let you book your own travel and then get it reimbursed, but presumably you're needed at the destination so if the day of travel comes and the plane is an airbus and you "nope" out of there, you're going to have to hope that your work is okay with your explanation.
All of this is because "if it's boeing, I ain't going" can seem alarmist or reactionary since the FAA has so far declined to drop the hammer on them.
In practice, you can only (reasonably) minimize your odds of flying on Boeing. That means "no" to Southwest Airlines. It means "yes" to Frontier Airlines, whose entire fleet consists only of Airbus planes. Thank goodness where I'm located and often need to go to are well-served by Frontier Airlines!
BUT - many airlines operate a mixed fleet. Book on an Airbus. They rarely change planes, but if they do, say your prayers! Unless you have tickets easily allowing you to re-book, which most of us aren't purchasing.
It’s often possible to take a suboptimal route to avoid a Boeing. For example, if I fly Austin to San Francisco, it could well be a MAX, but if I go to SJC via LAX instead it is almost guaranteed not to be.
How much more dangerous is it to take two flights (and two different planes with varying ages and maintenance records, plus two landings and take offs), than to take one Boeing?
I am ok with older Boeing airplanes. While I am skeptical of the company's current safety program, and attention to detail, I think the older planes - with many C checks done - are safe to fly. Something happened with the 737 Max, clearly a management decision, that increased risk or perhaps inattention to detail.
My opinion is that the company was run by bean counters instead of engineers, and the stock market convinced the business people that changing the way they made airplanes, made sense.
As I mentioned, older Boeing's. The Dreamliner been flying since 2011, that's an older Boeing for me, compared to the 737 Max which has only been flying commercially since 2016.
My bad. The article makes that clear behind a paywall. I could only read the first two paragraphs before I asked the question. Luckily the archive link shared had the full text and I was able to read the full incident description. Thank you!
That was determined after an independent investigation by both the FAA and NTSB. This incident hasn't been investigated by anyone but Southwest Airlines.
> The captain opted to put the “newer” first officer in command on the short flight to Lihue despite the forecasts, according to the memo.
The less-experienced first officer “inadvertently” pushed forward on the control column, then cut the speed causing the airplane to descend. Soon after, a warning system sounded alarms the jet was getting too close to the surface and the captain ordered the first officer to increase thrust. The plane then “climbed aggressively” at 8,500 feet per minute, the memo said.
My apologies for asking the question when I could only read the first two paragraphs due to paywall. The archive link shared cleared up my concern, and makes it clear that it was human error during a weather-related re-approach. Thanks, though!
> We present a gradual type system for Elixir, based on the framework of semantic subtyping ... [which] provides a type system centered on the use of set-theoretic types (unions, intersections, negations) that satisfy the commutativity and distributivity properties of the corresponding set-theoretic operations. The system is a polymorphic type system with local type inference, that is, functions are explicitly annotated with types that may contain type variables, but their applications do not require explicit instantiations: the system deduces the right instantiations of every type variable. It also features precise typing of pattern matching combined with type narrowing: the types of the capture variables of the pattern and of some variables of the matched expression are refined in the branches to take into account the results of pattern matching.
sounds like what typescript does, I'm not clear if the Elixir approach is different from "structural typing" (as TS calls it) or if they're rediscovering the same thing. Either way, I'm happy it's the way they're going
While both Elixir and TypeScript are structural, they are different type systems. A set-theoretic type system is not one that has unions, intersections, negations, but rather one where the foundation of the type system is represented on top of unions, intersections, and negations. Even relations such as subtyping, compatibility, etc. are expressed as set-theoretic. We also have a very different approach to dynamic/gradual typing (which is sound): https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua...
I recommend reading Giuseppe Castagna's work for those who want to dig deeper: https://www.irif.fr/~gc/
I did read your article, and it’s actually how I came out with the idea that Elixir had come up with the same idea as TS haha!
I’m sure I’m missing something as I have no doubt you’re by far more knowledgeable than I am, but TS also represents types as sets (semantically, dunno about internal implementation), structural typing seems to inherently map to set theory
For example, about bounded polymorphism the article says “Of course, we can provide syntax sugar for those constraints”: seems like this sugar could be ‘a extends number’ to me, like typescript does. I don’t see how TS does _not_ map to set operations
Sorry for the late reply but I wanted to double check before following up. And I am glad I did because I was told my first response was inaccurate. :)
It is fair to call both TypeScript and Elixir as set-theoretic type system. The big difference is that Elixir's implements semantic subtyping. Here is the paper you can use to dig deeper. I hope it helps: https://www.irif.fr/~gc/papers/lics02.pdf
Elixir is going to be fundamentally different from TS though. The base set of datatypes is quite well defined, and function activities are rather composable unlike JS where "basically anything can happen".
For more information about what that means, see this playground [0] from the TypeScript docs. PL people often make a big deal about TypeScript's lack of soundness as though it was some kind of mistake, but it was very much an intentional choice given the trade-offs they were making at the time.
If Elixir can pull off soundness without compromising expressivity that will be a huge feat, and I'm excited to see it!
Yea I never bought this assertion from the TS team, saying “given the trade-offs at the time” is the same as saying “we’re already backed into a corner by previous decisions” - the decision(s) may have been intentional at each step but the design itself probably was not. Given the choice of sound or unsound, considering that the purpose of a type system is to give certain guarantees, a type system design must always choose soundness to be considered reasonable.
That being said, I don’t think it’s possible to “pull off soundness without compromising expressivity” because the expressivity in this context is self-referential types which equate to non-terminating unification logic (and thus, unsoundness). Still, I’m excited to see what they do with this type system! Reminds me a bit of Shen’s type system.
Is the TypeScript team correct in explaining that soundness would exclude functions accepting subtypes as laid out there? If so, it seems like any type system that was meant to be able to type common JavaScript idioms would have to be unsound.
Yes and no - you can't have bi-variant argument types as shown here and be sound, but that does not mean you can't type those idioms. You just need the type system to be able to express a dependency between the name of the event handler and the type of the associated function. It is not exactly straightforward (this is a complex type system feature) though, I don't blame the TS devs for going for an escape hatch there.
(Edit: to be clear, allowing to refine function types in the way they do is part of the solution, the unsound part is that it is not checked afaik)
Sub-types can be represented with algebraic types so I’m not sure that’s necessarily true, for example an abstract class with subclasses can be represented as a sum type
