cpgxiii

I don't think that's the problem, at least not directly for us. The immediate interface between the languages is handled by a binding layer (e.g. pybind11 or nanobind), but that rarely lets you fully express object relationships (something that would be more possible without the binding layer) so it is very easy to either not capture ownership (and thus the C++ object is destroyed out from underneath you) or express a cycle that cpython can't understand (and thus the C++ objects are never destroyed and can leak a significant amount of memory). Explicit manual control would avoid that, but at a level of work that would be prohibitive of having extensive bindings in the first place.

Coming from an environment in which we extensively use mixed codebases (C++ and Python) to combine performance and ease of prototyping, one of the pain points is that there is almost always some impedance mismatch between the lifetime/ownership models of the two languages. When something goes wrong here, it's usually a real pain to debug and resolve, and often the resolution involves imposing constraints from one language onto the other (e.g. C++ that would idiomatically use unique_ptr instead needs to use shared_ptr because unique_ptr is essentially impossible to completely capture in Python).

Given the issues involved in mixing languages, there can be cases where sticking with one "good enough" GC'd language and having to write a few performance-sensitive parts in very unidiomatic form to minimize/eliminate GC work is preferable.

Of all the bits of software from big tech companies that I use/encounter, there are very few that I would say are better now than they were a decade ago. If anything, I think most of them were better a decade ago than they are now, and I don't think that's a particularly uncommon opinion. I think there's a good argument to be made that any "rationing" then had a positive effect on software quality (at least when compared to the lack thereof in the "post-rationing" era), and that should be a very cautionary tale that a massive increase in software written by AI tools is likely to result in much worse products.

I don't think the last decade of tech (particularly SV) hiring can in any way be defined as "rationing". If anything, we have seen large software companies grossly over-hire for all of the expected dumb reasons (mostly internal politics) and find themselves in the very predictable situation that more people != more productivity.

The Zhoushan "Completion Center" is not an assembly line - it only handles interior fitment and exterior paint on aircraft that are otherwise fully assembled and have been flown from the production lines in Renton or Everett. The Airbus assembly lines outside the EU perform actual assembly of fuselage and wing components into complete aircraft.

> How many aircraft can the world need that it commonly tops the export chart of the wealthiest country?

Airliners and military aircraft are expensive. Consider that nearly the entire aircraft production capacity of Boeing and Lockheed-Martin as well as the engine production capacity of GE and P&W are booked for years to come. Also, unlike Airbus which has multiple final assembly plants across the world, Boeing only does final assembly in the US.

Because a truly massive portion of managers/leaders in AI-adjacent work are heavily buzzword-driven. "System 1/system 2","agentic <buzzword>", etc; someone in the industry starts using it and then everyone else picks it up, regardless of how much (or little) they understand.

There is no mechanism. Finance and startup Bros want to dump their overvalued companies with deceitful accounting on public investors to make a quick profit and socialize the inevitable losses. SOX makes it harder for them to do that.

To whatever extent SOX compliance makes it more complex to go public, it has no meaningful effect on legitimate successful companies - if you think going public will allow you to raise the most money, you'll go public; if ZIRP meant you could indefinitely raise private money, you'd stay private. Finance and startup bros want to blame companies staying private on SOX, but it has everything to do with either (1) the companies being deeply questionable from an accounting perspective, or (2) the companies being able to raise whatever investments they wanted in private without taking any of the costs of an IPO (e.g. the IPO pop, which could (simplisticaly) be thought of as money being made by the banks underwriting the IPO rather than by the existing owners/investors).

There's a range of DDS implementations, definitely a number that are compatible with embedded and spaceflight applications that don't require dynamic memory allocations. You're going to take a hit on some DDS features, but then again you aren't going to need to handle a large queue of large dynamically-sized messages on some small embedded platform.

I think it's rarely the right choice - most of the hardware I've seen that uses embedded DDS probably should have used plain old UDP instead and then whatever client was running on beefier hardware then handled the translation into DDS - but there are shipping products that use embedded DDS.

Any of the integrated actuators on the market (e.g. Cubemars, zeroerr, myactuator, many more) do proper control and feedback.

In general implementing a weaker memory model (e.g. aarch64) on a stronger memory model (e.g. x86_64 or s390x) is fairly easy, while the reverse is more difficult (see Apple's processors which have a dedicated "stronger" mode to better support execution of translated x86_64 code). It all requires some additional complexity, but starting from a complicated high-performance CISC architecture which already supports a wide range of backwards compatibility modes you are already going to have many of the building blocks on hand to support something new.

The "naive notion of system performance" is that the system is primarily operating in the ideal regime, and thus all deviations deserve alerts (and receive attention). The reality is that often the system is operating often enough in some failure mode that any such alerts would be regularly triggered by accepted behavior, and thus the alerts are systematically ignored/disabled/normalized.

E.g. nominally you should never be mixing traffic types (aircraft and helicopters, civilian and military) in close proximity to a major airport and in a regime where TCAS is unlikely to offer sufficient protection. So in theory, any mixing should immediately trigger an alert and investigation to develop new procedures. But in practice, if you routinely allow such mixing under what you believe are "safe" practices (and get away with such mixing for a long time) then when a real accident happens you will have plenty of "proto-accidents" to look back on, but the warning signs from those near-accidents will have become accepted practice.

Either they believe their own hype and their reliability is a reflection of the real weaknesses of AI coding, or they're complete liars and doing far more traditional SWE than they claim. I think the former case is far more likely and that while they may have hired plenty of senior people from big companies, there's definitely a self-selection for "true believers" in AI coding baked into that hiring process.

To a first approximation, basically no one in the industry does. Users regularly report performance regressions in basically every major piece of software, most of which would have been caught by performance testing.

Indeed, regulation is the only way to protect passengers from market greed here, but the airplane makers play a critical role in what designs they make available to airlines. Airbus and Boeing both like to market their newer designs and interiors in terms of passenger comfort (lower cabin altitude, reduced noise, larger windows, etc) so clearly they (and their customers) understand that passenger comfort justifies spending somewhat more than the bare minimum. And given past designs (and designs still fitted in widebodies) they very much know how to build useful lavatories.

I suspect in time there will actually be safety consequences to the continued downsizing of airplane lavatories. There are already a number of serious incidents that have been caused by fluid leaks from galleys and lavatories (IIRC Quantas came pretty close to losing a 747-400 due to a kitchen leak leading to massive water intrusion into the main electrical/avionics bay - once you end up pouring large quantities of water on your avionics all bets are off about the systems failures that will happen and you are well beyond any backup/redundancy that has been designed in, and during the 60s and 70s the USAF experienced serious corrosion of flight control cables on C-130s due to urine "leakage"). Too-small lavatories basically guarantee that water and urine are going to end up in undesirable locations and at best they will cause expensive interior corrosion and at worst they will cause serious corrosion to the airframe or critical equipment.