Somewhat related - but there are a ridiculous number of platform/systems that ship with derivative of Dinkum C++ standard library - MSVC (included). When you lookup the company behind it - it's basically small shop that seems to be primarily one guy up in MA.
He wrote a very lovely book called "The C standard library". It contains a full implementation of the c standard library with lots of explenations and excerpts from the C standard.
Alternatively - you can get an export license for information to the particular person. Kind of like a TAA for a foreign employee. Previous employer had a European EW expert in the US office temporarily. Still not fast and lots of paperwork and limitations.
Generally speaking, F# was actually very fast, and had nice concurrency support, but there were times that wasn't the case.
For example, in 2016 I was part of the initiative to rewrite the ad feed. We had to read in several Kafka topics, do some joining on our end, and emit to a separate Kafka topic. This isn't terribly hard to write, but we were dealing on the order of about ~100gb of data being pushed into memory. This is hardly "big data" stuff, but it's enough to highlight some issues.
Specifically, the built F# persistent map structure was simply too slow to get the performance we wanted. I really like that structure, it's really handy and nice, but I ended up having to make heavy use of the ConcurrentDictionary that was built into .NET. This wasn't that hard or anything, but it made me a little sad that I had to move to a mutable store to get the performance I needed.
There was also the fact that the `async` monad, while generally very good and useful, had bizarre bottlenecks that were hard to measure. It was difficult to know when the async task was actually started, and when you tried to measure performance bottlenecks you were really only measuring the scheduler, not the actual performance. This isn't really F#'s fault, this is an issue with any kind of cooperative scheduling system, but occasionally to get the performance we needed we'd have to move to lower level threads instead of the pretty monadic stuff. Microsoft eventually released the Task monad which generally performed a bit better.
There were other things here and there; the Kafka client libraries for .NET simply aren't as good as the Java ones. Jet actually open-sourced their own (https://github.com/jet/kafunk) which did make it a bit more functional and nice, but it had performance issues as well, so a lot of us ended up using Confluent.
There were little annoyances specific to F# as well; there's no real concept of a monad transformer, so if you wanted to do something like, for example, combine an Option and an Async into generalized syntax, you'd have to write your own wrapper monad thing, which wasn't that hard but was sort of ad hoc.
The general rule of thumb was that the first draft of software, we would try and keep as functional and pretty. If that was too slow, we allowed mutation but only within a function. If that was too slow, we'd allow global mutation but only with thread-safe stuff.
I've found Analog Discovery true to its name -- great for exploring analog. The scope portion is limited in channel sensitivity and frequency. It's also a bit of a kludge, in that the probes attach via a 2x20 (?) front-panel 0.1" center connector to an adaptor board that has BNC females for the scope probes.
I have one of those (AD2; there is a newer AD3 available), and it's quite a lot of 'stuff' in one package. I wish I had one when I was learning EE. But these days, I use them as 'data acquisition and control' modules to generate and capture signals under program (Python) control. I think of them sort of as a fancy Arduino -- although it can do many more analog tricks. Recommended.
Thanks for this comment. It seems that ARINC 429 has been replaced by ARINC 644 in most new aircraft.
From reading the Wikipedia article, they are indeed logically one-way (although the underlying protocol involves two-way communication). It has no security at all.
However, it seems that communication between any avionics systems and anything user-accessible goes through a Network Extension Device (NED). These are required to either be physically (not only logically) unidirectional _or_ have built-in security.
So it might be physically impermeable or it might be a buggy 10-year old firewall. Doesn't exactly inspire confidence given the subject of the article.
