> Rust had like 3 allocating types total.

Seriously? Categories of types maybe, but literal types it's more than that.

Even closures allocate if they need to capture their environment.

It’s actually the opposite: the language has zero allocations in it. Allocation is entirely a library concern.

When you want to have a closure allocate an environment, the closure itself does not: the Box you wrap it in, which is a stdlib type, does.

Some of this surely stems from Rust not originally supporting allocators at the standard API level until later. You can manually create your own, and create/modify your own containers, but until GlobalAlloc came around it sometimes involved doing things like passing through Arc<Allocator> through to things if you wanted multiple things to use a single one.

Sometimes using a global one isn't the best thing (it's often a good idea to specialise base on allocation size, reuse and lifetimes), but I've used them quite a bit in C++ over the past 16 years doing HPC for graphics, rendering and simulation, so calling them only useful for "toy problems" likely shows you just haven't found a need for them in what you've been doing.

> and is barely even supported at all in the standard library.

What does that mean?

But that was has nothing to do with the incident in the Middle East, it's a more general one.

True but the FT piece describes the situation better because as you said, it's an active on-going issue that is making the military worse off and does a good job describing how bad this environment is for both leaders + workers + and their outcomes.

Back in 2023 when the previous issue happened, it didn't actually "crash", it detected what it perceived as an inconsistency (which was due to invalid waypoint logic for waypoint codes in multiple countries) and put itself in "maintenance mode".

My point was that it should not have happenned in the first place. It should have just rejected the flight plan, sent a notice to whatever coordination center would have been in charge of the flight and kept running.

The fact that it entered in maintenance mode still ruined a lot of people’s days.

I don’t think any flight crew or passenger cared about semantics back then.

It was blatantly obvious Iran would do that if attacked. This has been known for decades.

The only thing previously stopping them holding the strait "hostage" was the threat from the US of doing an "Operation Praying Mantis v2" and destroying their navy and attacking them.

And when the US did that anyway, they had nothing to lose.

And Iran attacked. Relentlessly every day up to that war. It does not get into western news much. But in Lebanon. In Yemen. In iraq. In ghaza. There proxies marched and attacked. The west is to weak, to wait for another pearl harbour.

The damage Iran did to the various US bases around the gulf is now visible to everyone, I just saw the images on CBS.

They've got the IDL files as well for the APIs, but you can't use them without their libs:

> The data model is defined using a custom format .rmodel based on the ddkit > framework (rmodel-api).

> Please note that the .rmodel data model is for documentation purposes only and > does not reflect the actual interface used on the communication layer. Network > communication is only possible through the provided libraries.

DDS sort of took over from CORBA in the military domain, and the statically-typed IDL was still quite similar to CORBA last time I looked at it, so that takes you back to around 1998 when CORBA was being used a lot in the military in my experience.

What other protocols and systems were you thinking of that can provide (depending on broker) hard-realtime delivery that can be used in safety-critical systems?

Stupid question, but why didn’t the DOD mandate IP compatibility for literally all comms like 20+ years ago? Is it pure corruption/incompetence or is there a good reason?

A lot of military comms are point-to-point or broadcast between radios where TCP/IP doesn’t really make sense. On top of that, you need to understand how much legacy military networking stuff is out there. This stuff long predates the internet. We had tactical data links and target tracking where a ground station could receive a target info from a remote radar array, and automatically direct fighters on autopilot on an intercept course with enemy contacts in like 1960 (see SAGE as an example). These systems have been around for decades and been continually improved on. There’s a lot of inertia to maintain compatibility. Because you really don’t want someone to die because your ally tried to warn you but their tactical data link isn’t compatible with yours.

I never said anything about mandating TCP too.

TCP/IP refers to the whole protocol stack, including UDP. That is a bit counterintuitive, but well established: https://en.wikipedia.org/wiki/Internet_protocol_suite

The DOD effectively can't "just mandate" things and it's because of politics (which is a superset of corruption and incompetence).

There's a very small number of major contractors and if you pick one of their APIs as the new standard, then you disadvantage all the others.

If you pick a greenfield project, then it will take a long time, and once you are done everybody will claim that they can't use it (see e.g. Ada; quick version they started working on a mandate for a programming language in 1975, mandated Ada in 1991 and by 1996 removed the Ada mandate).

actual or perceived realtime / determinism requirements

Its giraffe / grandfather clock one is pretty bad... (two necks? wearing a suit?)

Weird as well, it's clearly pulled out some 1884 patent on clock designs, and a quick ddg/google doesn't show it as anything to do with grandfather clocks.

Sounds like it might not have been fully fixed after 2023 then.