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).
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.
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/
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!
For people who aren't familiar with the language, pretty much all modern languages are descended from Algol 60 or Algol 68. C descends from Algol 60, so pretty much every popular modern language derives from Algol in some way [1].
Sure it's ideas spawned many of today's languages, But wasn't that because at the time nobody could afford to actually implement the spec. So we ended up with a ton of "algols buts" (like algol but can actually be implemented and runs on real hardware).
https://academic.oup.com/comjnl/article-abstract/22/2/114/42...
Structs come from PL/I, not from ALGOL 68, together with the postfix operators "." and "->". The term "pointer" also comes from PL/I, the corresponding term in ALGOL 68 was "reference". The prefix operator "*" is a mistake peculiar to C, acknowledged later by the C language designers, it should have been a postfix operator, like in Euler and Pascal.
Examples of things that come from ALGOL 68 are unions (unfortunately C unions lack most useful features of the ALGOL 68 unions. which are implicitly tagged unions) and the combined operation-assignment operators, e.g. "+=" or "*=".
The Bourne shell scripting language, inherited by ksh, bash, zsh etc., also has many features taken from ALGOL 68.
The explicit "malloc" and "free" also come from PL/I. ALGOL 68 is normally implemented with a garbage collector.
Aside from historical interest, why are you excited for it?
Admittedly, every language I really enjoy and get along with is one of those languages that produced little compared to the likes of C (APL, Tcl/Tk, Forth), and as a hobbyist I have no real stake in the game.
While I doubt I'll do any major development in it, I'll definitely have a play with it, just to revisit old memories and remind myself of its many innovations.
Ironically, Algol 68 and Modula-2 are getting more contributions than Go, on GCC frontends, which seems stuck in version 1.18, in a situation similar to gcj.
Either way, today is for Algol's celebration.
Regarding Go, gccgo was a way to have a better compiler backend for those that care about optimizations that reference Go compiler isn't capable of, due to the difference in history, philosophy, whatever.
Apparently that effort isn't seen as worthwile by the community.
GCC has some rules to add, and keep frontends on the main compiler, instead of additional branches, e.g. GNU Pascal never got added.
So if there is no value with maintenance effort, the GCC steering will eventually discuss this.
https://github.com/search?q=algol68&type=repositories
Without knowing what your interests/motivations and backgrounds are, it is hard to make good recommendations, but if you didn't know about rosettacode or github I figured I should start with that
Godcc is a command-line interface for Compiler Explorer written in Algol 68.
Many have been digitalized throughout the years across Bitsavers, ACM/SIGPLAN, IEEE, or university departments.
Also heavily influenced languages like ESPOL, NEWP, PL/I and its variants.
begin
real procedure A(k, x1, x2, x3, x4, x5);
value k; integer k;
real x1, x2, x3, x4, x5;
begin
real procedure B;
begin k := k - 1;
B := A := A(k, B, x1, x2, x3, x4)
end;
if k ≤ 0 then A := x4 + x5 else B
end;
outreal(1, A(10, 1, -1, -1, 1, 0))
end
#include <functional>
#include <iostream>
using cf = std::function<int()>;
int A(int k, cf x1, cf x2, cf x3, cf x4, cf x5)
{
int Aval;
cf B = [&]()
{
int Bval;
--k;
Bval = Aval = A(k, B, x1, x2, x3, x4);
return Bval;
};
if (k <= 0) Aval = x4() + x5(); else B();
return Aval;
}
cf I(int n) { return [=](){ return n; }; }
int main()
{
for (int n=0; n<10; ++n)
std::cout << A(n, I(1), I(-1), I(-1), I(1), I(0)) << ", ";
std::cout << std::endl;
}
These were fairly popular for awhile and supported advanced features like multiprocessing. The demand for exercising the full range of capabilities was kind of niche but an "amateur", like myself, could make a few bucks if you knew ALGOL.
I used to have the grey manual for the Burrough's variant - I'll have to poke around to see if it's in the attic somewhere.
That said, it really stands out to me that the two latest GCC languages are Cobol and Algol68 while LLVM gets Swift and Zig.
And Rust and Julia come from LLVM as well of course.