Do you have an example of the first?

When I wrote that, I was thinking about typed, compiled languages' documentation generated by the compiler at build time. Assuming that version drift ("D'oh, I was reading the docs for v1.2.3 but running v4.5.6") is user error and not a docs-trustworthiness issue, that'd qualify.

But now that I'm coming back to it, I think that this might be a larger category than I first envisioned, including projects whose build/release processes very reliably include the generation+validation+publication of updated docs. That doesn't imply a specific language or release automation, just a strong track record of doc-accuracy linked to releases.

In other words, if a user can validate/regenerate the docs for a project, that gets it 9/10 points. The remaining point is the squishier "the first party docs are always available and well-validated for accuracy" stuff.

Another example of extremely far towards the "accurate and trustworthy" end of the spectrum: asking a running webservice for the e.g. Swagger/OpenAPI schema that it is currently using to serve requests. If you can trust that those docs are produced (on request or cached at deployment time) by the same backend application instances serving other requests, you'd have pretty high assurance.

Nobody does that, though. Instead they all auto-publish their OpenAPI schemas through rickety-ass, fail-soft build systems to flaky, unmonitored CDNs. Then they get mad at users who tell them when their API docs don't match their running APIs.

Languages with strong static type systems

Is there a mainstream language where you can’t arbitrarily cast a variable to any other type?

This can obviously be expanded to top to bottom programming, and there's a related principle of reorder / relocation.

If/else if fails the relocation principal across many languages, since the first must be if, and middles else if. Switch tends to pass.

Languages that don't allow trailing commas also fail

> by replacing inline types with whitespace, Node.js can run TypeScript code without the need for source maps.

This is a really neat idea and I hope typescript adds this as a compiler option.

Anecdotally Ive noticed a lot of packages failing to build when updating from node 20 to 22.18.0 that weren't failing with earlier node 22 versions. .18 unflagged typescript support.

These are packages using ts-node or tsx to run typescript in node, and with node 22.18 they seem to be using nodes native typescript support instead, and failing due to its limited feature set, or subtly different module resolution.

Yeah, this felt like a gap in the article. You'd have to wait for every package to update from the bottom up before you could update you top levels to remove a risk (or you could patch in place, or override)

But what if all the packages had automatic ci/cd, and libinsecure 0.2.1 is published, libuseful automatically tests a new version of itself that uses 0.2.1, and if it succeeds it publishes a new version. And consumers of libuseful do the same, and so on.

The automatic ci/cd suggestion sounds appealing, but at least in the NPM ecosystem, the depth of those dependencies would mean the top-level dependencies would constantly be incrementing. On the app developer side, it would take a lot of attention to figure when it's important to update top-level dependencies and when it's not.

Could aggregate the incrementing to for example 1 per day.

It's wild that that's not what the section is about. Extending error is not new at-all.

Most people (including the author apparently) don't know they can chain errors with cause option in-built way in node and in browser. It is not just arbitrary extending and it is relatively a new thing. https://nodejs.org/api/errors.html#errorcause

I've found that a lot of logging frameworks and patterns will not include cause which can absolutely fuck debugging

Which typescript features are improving runtime validation?

Previously (~2-3 years ago), it was impossible to narrow `unknown` to a fully typed object. Recently-ish, they added the ability for `"foo" in obj` to type-refine `object` to `object & {"foo": unknown}`, which lets you further narrow foo down to something more specific.

IMO until the abstract logging interface is built into the language, or standard library, we'll keep building different log libraries and adapters between them, and shipping libraries without logging.

It makes me actively disinterested in these libraries. I just want some built in interface with levels, hierarchy, and structured logging

This is one of the things Elixir got right on day 1, all the libraries in the ecosystem use the standard library and it makes dealing with logs so much easier compared to other languages.

This slows down innovation.

In Java it is common to use the MDC support of slf4j. You can add to metadata in thread local variables, so that you don't have to add it at every logging site.

Any precedent for language agnostic behavior (I genuinely don’t know)? Would be keen to have a common interface that languages implement into their standard libraries or keywords

OTEL perhaps

Java has the java.util.logging classes.

Java historically has had so many logging frameworks it needs logging framework adapters to deal with the problem that in any significant program you will end up with dependencies that log in incompatible ways :/

It probably has the most complex and messy logging story of any language - but at least the solutions are very mature at this point.

Not a good example, as the de-facto logging interface for Java was SLF4J.

Though I myself prefer Log4J2, as I'm already using Log4J2 as the concrete logging implementation.

Why do you prefer Log4j2 over the slf4j api and why over logback as the backend?

I prefer Log4J2 built-in JSON Template Layout to Logback's various JSON output solution.

The API of Log4J2 and SLF4J v2 are similar enough that it does not matter for basic usage, I don't see the benefit of SLF4J in a project that's already using Log4J2.

Swift has a de-facto logging library: swift-log (by Apple, with levels and structured logging; not sure about hierarchy as I don’t know what you mean by that).

Probably, a hierarchy of different loggers.

You're right that people will continue building their own libraries. I also wish this was all built-in so you wouldn't need something like loglayer.

This is how .net does this as well. You write logs via ILogger interface and then wire it up to a logging library of any flavor.

ILogger is not in the BCL. Its part of the Microsoft.Extensions family of libraries.

Though today much of the Microsoft.Extensions family is considered BCL by most users, especially in the way it is documented as "Core functionality" (the "Generic Host" model uses a lot of Microsoft.Extensions, up front in .NET documentation today) and also in the way that the majority of it (especially in this case of Microsoft.Extensions.Logging) is source controlled side-by-side with most of the BCL, including almost all of System.**: https://github.com/dotnet/runtime/tree/main/src/libraries

(There are some of Microsoft.Extensions that exist outside of dotnet/runtime in dotnet/extensions: https://github.com/dotnet/extensions/tree/main/src/Libraries)

I don't see anything wrong with this and hope that countries and manufacturers start to cut power or refuse to exceed limits.

At the very least within cities and towns. New modes of transit have geofenced speed govenors, I don't think we should grandfather cars exceptions.

I rode in a waymo for the first time yesterday, and it was going the speed limit in downtown SF (20 MPH) while cars were speeding around us. It seems like in the future if all cars are driven by robots, traffic would go much slower, maybe to the detriment of intended capacity (the roads still felt really busy, I assume if all the cars were going 20 it would quickly jam to much less than that).

Id love it of npm added support for additional artifacts — separate tarballs for source, code, binaries, source maps, docs etc

Fair, but if you don't fall into the pit of despair by consuming micro libraries (ie "is-true" or "leftpad"), the overhead of having source and source maps present on a developer environment or even a server deployment is not terrible. If you are bundling for web delivery, those files will be omitted automatically by nature of the bundling process.

While it would be nice to have native support for package components, personally I think the best path is to ship all of it (save perhaps documentation, where there's currently no ergonomic way for a consumer to make use of it) in the main package.

The above is assuming "docs" mean some kind of external documentation, you absolutely should not strip out your docblocks when you package your code. Ditto for minification: Just don't. If the end user needs to optimize for size, they will be minifying anyway, all packaging minification does is create painful debugging and code reading experiences for consumers.