Rust's target tier support policies aren't based on "corporate needs". They're based, primarily, on having people willing to do the work to support the target on an ongoing basis, and provide the logistics needed to make sure it works.
The main difference, I would say, is that many projects essentially provide the equivalent of Rust's "tier 3" ("the code is there, it might even work") without documenting it as such.
Both sets of constraints produce patterns and gaps. UX and documentation are commonly cited gaps for volunteer programming efforts, for example.
But I think it's true that corporate funding has its own gaps and other distinctive tendencies.
Algol 68 isn’t any more useful than obsolete Rust, however.
But we are carefully adding many GNU extensions to the language, as was explicitly allowed by the Revised Report:
[RR page 52]
"[...] a superlanguage of ALGOL 68 might be defined by additions to
the syntax, semantics or standard-prelude, so as to improve
efficiency or to permit the solution of problems not readily
amenable to ALGOL 68."
You can find the extensions currently implemented by GCC listed at https://algol68-lang.org/
It was an AWK like task, but I decided up front it was too much trouble to do in AWK, as I needed to build a graph of data structures from the input data.
In part the program had an AWK like pattern matching and processing section, which wasn't too awkward. I found having to use REF's more trouble that dealing with pointers, in part due to the forms of auto dereferencing the language uses; but that was expected.
The real problem though was that I ended up needing something like a map / hash-table, and I concluded it was too much trouble to write from scratch.
So in the end I switched the program to be written in Go.
That then suggests a few things to me:
- it should have an extension library (prelude) offering some form of hash table.
- it would be useful to add syntax for explicit pointers (PTR keyword) which are not automatically dereferenced when used.
- maybe have with either something like the Go (or Zig) style syntax for selecting a member of a pointed to struct (a.b) and maybe Zig like explicit defer (ptr.\*).
However I think there's the retro-computing, and other hobby niches that align with your hacker view. And certainly there's a bunch of corp enthusiasm for standardizing shiny things.
A number of years ago I worked on a POWER9 GPU cluster. This was quite painful - Python had started moving to use wheels and so most projects had started to build these automatically in CI pipelines but pretty much none of these even supported ARM let alone POWER9 architecture. So you were on your own for pretty much anything that wasn’t Numpy. The reason for this of course is just that there was little demand and as a result even fewer people willing to support it.
Most people don't care about our history, only what is shiny.
It is sad!
FOSS driven by hackers is about increasing and maintaining support (old and new hardware, languages etc..) while FOSS influenced by corporate needs is about standardizing around 'blessed' platforms like is happening in Linux distributions with adoption of Rust (architectures unsupported by Rust lose support).