I read, and then I posted. Is there anything in my reply that I can explain to you?

You do actually understand that languages that aren’t JavaScript don’t have built in async runtimes and they need to be provided by a library, right?

How do you explain C#?

Does anyone have any good sources or suggestions on how I could look to try and begin to improve documentation within my team?

Documentation in software projecte, more often than not, is a huge waste of time and resources.

If you expect your docs to go too much into detail, they will quickly become obsolete and dissociated from the actual project. You will need to waste a lot of work keeping them in sync with the project, with little to no benefit at all.

If you expect your docs to stick with high-level descriptions and overviews, they quickly lose relevance and become useless after you onboard to a project.

If you expect your docs to document usecases, you're doing it wrong. That's the job of automated test suites.

The hard truth is that the only people who think they benefit from documentation are junior devs just starting out their career. Their need for docs is a proxy for the challenges they face reading the source code and understanding how the technology is being used and how things work and are expected to work. Once they go through onboarding, documentation quickly vanishes from their concerns.

Nowadays software is self-documenting with combination of three tools: the software projects themselves, version control systems, and ticketing systems. A PR shows you what code changes were involved in implementing a feature/fixing a bug, the commit logs touching some component tells you how that component can and does change, and ticketing shows you the motivation and the context for some changes. Automated test suites track the conditions the software must meet and which the development team feels must be ensured in order for the software to work. The higher you are in the testing pyramid, the closer you are to document usecases.

If you care about improving your team's ability to document their work, you focus on ticketing, commit etiquette, automated tests, and writing clean code.

Erm yeah because the whole point of monorepos is that you don’t use submodules. What?

Not true. The whole point of monorepos is that you track everything in a single repo. There is absolutely no requirement or constraint to avoid using specific features of specific VCSs or even package managers.

You are making an extreme assumption, and it also sounds like you’ve misread what I wrote. The “attempts” I’m talking about are studies (formal and informal) to measure the root causes of bugs, not the C or C++ projects themselves.

I think you're talking past the point I've made.

The point I've made is that the bulk of these attempts don't even consider onboarding basic static analysis tools for projects. Do you agree?

If you read the post of other studies you've quoted, you'd be aware that some of them quite literally report results of onboarding a single static analysis tool to C or C++ projects. The very first study in your list is quite literally the results of onboarding projects to Hardware-assisted AddressSanitizer, after acknowledging that they haven't onboarded AddressSanitizer due to performance reasons. The second study in your list reports results of enabling LLVM’s bound sanitizer.

Yet, your personal claim over "the lack of memory safety" in languages like C or C++ is unexplainably based on failing to follow very basic and simple steps like onboarding any static analysis tool, which is trivial to do. Yet, your assertion doesn't cover that simple step. Why is that?

Again, I think this comparison is disingenuous. You take zero effort to address whole family of errors and then proceed to claim that whole family of errors are not addressed, even though nowadays there's a myriad of ways to tackle those. That doesn't sound like a honest comparison to me.

C syntax is simple, yes, but C semantics are not; there have been numerous attempts to quantify what percentage of C and C++ software bugs and/or security vulnerabilities are due to the lack of memory safety in these languages, and (...)

...and the bulk of these attempts don't even consider onboarding basic static analysis tools to projects.

I think this comparison is disingenuous. Rust has static code analysis checks built into the compiler, while C compilers don't. Yet, you can still add static code analysis checks to projects, and from my experience they do a pretty good job flagging everything ranging from Critical double-frees to newlines showing up where they shouldn't. How come these tools are kept out of the equation?

Are you going to post links to all Wikipedia articles here?

What problem do you have with Wikipedia?

I'm not sure I'm expressing this in clear terms. The same company is collecting data and anonymizing it. They have people dedicated to review which data a service is designed to store, to classify that data according to their privacy implications, and to anonymize all data they have in order to comply with all sorts of legislation.

If the data they are collecting isn't anonymous, or could be deanonimized, they are liable to pay huge fines and suffer other painful legal consequences.

This is not about hypothetical scenarios where you can argue that tracking random brower fingerprints can pinpoint who you are. This is about a single company having to legally demonstrate they do not directly or indirectly abuse personally identifiable information, otherwise they have to pay a fortune in fines for no good reason.

I’m sorry, which of those recent commits aren’t things a single linter run would catch?

Ask yourself why the code still had those typos, and why nobody did anything about it except the guy contributing code cleanup commits.

This is a ridiculous definition of “real-time”. To accomplish this you’d need to subvert the kernal’s scheduler (...)

You missed the whole point of the article.

It makes no sense to read the article and arrive at the conclusion that "I need to subvert the Kernel's scheduler". The whole point of the real-time analogy is that handlers have a hard constraint on the time budget allocated to execute each handler. If your handler is within budget them it's perfectly reasonable to run on the UI thread. If your handler exceeds the budget then user experience starts to suffer, and you need to rework your implementation to run stuff async.

Keep in mind that each mouse click/hover/move/sneeze triggers a handler on GUI applications. Clicking on a button can trigger small, instant changes like updating UI, or can trigger expensive operations like running an expensive task. Some handlers start off as doing small UI updates but end up doing more and more stuff that ultimately start to become noticeable.

I think that pattern matching and sum types are orthogonal to monads, and aren't really relevant when discussing monads as alternatives to exceptions. C++ didn't required any of those to add std::optional or std::variant, and those are already used as result monads.

Supporting Result and Either monads in the standard would be nice, but again this does not stop anyone from adopting one of the many libraries that already provide those.

No> Context is whatever makes sense to provide to a consumer to help them debug it or respond to it

So it's both optional and unspecified. This means it can't be parsed or relied upon, specially by consumers. It's useless.

the same basic idea as in the rfc under details.

No, it isn't. Contrary to your ad-hoc format, RFC9457 specifies exactly the data type of detail and what's its purpose. This allows third parties to reliably consume resources that comply with RFC9457 while your ad-hoc format leaves clients no option other than to ignore it.

IMO, it can’t easily be generalized. Some APIs may have context to provide, others may not.

It matters nothing what services can produce. What matters is whether clients can consume it. Your ad-hoc format fails to specify this field, which is optional, and thus leaves no option other than to ignore it. It's unusable.

Success is something that you can sniff for after deserializing, as IIRC Fetch API will not throw except for a network errors, even in the event of a 4XX or 5XX.

What the Fetch API does or does not do is irrelevant. The responsibility of putting together a response and generating the resource shipped with it lies exclusicely in your service. If it outputs a resource that is unable to tell clients what went on, that's a problem cause by both how your service is designed and the ad-hoc format it outputs.

The main take is that RFC9457 is well specified and covers basic usecases, while your ad-hoc format is broken by design. Thus when you describe the RFC as "overwrought", you're actually expressing the half-baked approach you took.