Ah, a Lisp user. Common Lisp is Exhibit A for standardization. Every Lisp user claims it is great because of either standardization of advanced features in the days when the Berlin Wall has barely fallen or the mere existence of macros. No real first-party improvement to the language in almost three decades after ANSI standardisation. Massive fragmentation in the compiler ecosystem, rarely do libraries work out of the box on non-SBCL tooling. Yes, I can definitely see the advantage of standardization now, very much so.

> No real first-party improvement to the language in almost three decades

That sounds like a benefit to me :)

However, I think that's due to the general lack of interest in Lisp. You can see the C++ community has a similar ANSI standard and updates it every few years.

> Massive fragmentation in the compiler ecosystem

I wouldn't call it massive. They are pretty consistent, up until things like POSIX and FFI APIs. Let's agree there is some fragmentation. Isn't this still a better situation than if nothing was guaranteed?

Yup I have had the same exact experience with Common Lisp and every time somebody talks about standardization being so great I think back on this.

Scheme is suffering from the same issues. Scheme is standardized, but implementations end up being incompatible with each other in subtle ways and the level of fragmentation is very painful. Scheme does get some updates unlike CL I guess, but all of the implementations either don't implement the the modern standard, don't have useful extensions for real world programming or are simply immature and don't have enough people working on them to get them into a nice state. In practice it's very difficult to use Scheme for anything non-trivial because of these issues.

I would much rather have no standard at all, and a single high quality implementation that everyone targeted instead of the current mess for both CL and Scheme. Until we get a new dialect that solves these issues Lisp is going to be more or less dead and irrelevant.

> I would much rather have no standard at all, and a single high quality implementation that everyone targeted instead of the current mess for both CL and Scheme.

That would be Chez Scheme [0], maintained actively by Cisco, a company that you may have heard of - who also use the language extensively.

Racket is porting to using Chez, because it is the industry standard, it's performant, and rock solid.

The GNU alternative to Chez is Guile. Emacs can run with Guile, and Guix is built on it. It's got a fairly large community.

Outside of Chez and Guile, there are implementations and communities, but comparatively, they're tiny. Those two are the only big names you need. Like GCC and Clang for C. There are other C compilers. But you only need to know those two.

[0] https://www.scheme.com/

> Racket is porting to using Chez,

I think it already happened in 8.0

Thanks. I'm going to install guile and tinker around with it! So far it looks pretty good.

Racket?

Why do libraries not work across compilers of the compilers are implementing a standard? Are they perhaps not really implementing a standard?

Simply having a document called "a standard" doesn't mean that:

1. the standard covers everything you wished it would cover

2. every implementation implements the standard, with no bugs

3. the standard doesn't itself contain incoherent or contradictory things

Standards are a tool, not magic interoperability sauce.

Hence the existence of standard certification for compilers as business.

Like the Goldman Rep says in The Big Short, "If you offer us free money, we ARE going to take it..."

I bet Ferrocene will also happily take part of that money.

There are simply lacking of such strong requirements in language standards. C/C++ even have the specific "linkage" concept to abstract the binary details under the source form away. And you may know, many libraries are distributed by binaries.

The standards implying binary compatibility rules are about ABI (application binary interface), which usually depend on the ISA (instruction-set architecture) or the OS (if any) being used. You cannot have the unique one once there are multiple ISAs/OSes supported. Even when you only want to rely on some external "exchanging" representations not tied to specific ISAs, there are already plenty of candidates: CLI, JVM, WebAssembly... Plus there are more than one executable (and mostly, runtime loadable) image formats widely used (PE/COFF, ELF, Mach-O ...). You will not have the unique combination, and any attempts to ensure it "work across compilers" in that way will likely finally just add a new instance not fully compatible to existing ones, making it more fragile.

Standards are often incomplete, or full of "implementation specific" behaviour, since AIUI standards often end up catering to implementations, instead of the other way around (For example C/C++ standards, you can read a plethora of blog posts about the experience of people trying to contribute to them, and some of the hurdles are related to how strongly tied to existing implementations they are). That means you can often have 2 "standards compliant" compilers that are wildly different. Another reason is compiler extensions. Sometimes a compiler is "standards compliant", but also implements a superset of the standard (Sometimes by default, sometimes under a flag) which means code gets written for that "superset" instead of according to a "standard" (for example, the linux kernel and gcc extensions to C).

Typically, some library features contain things that require cooperation with a specific compiler to work correctly. Consider something like std::is_standard_layout in C++, or java.lang.Object in Java, or std::panic::catch_unwind in Rust.

They typically do, unless they are wrapping C libraries or making platform specific API calls.

That sounds a little circular. The benefit of alternate compilers is that it makes making alternate compilers easier.

For stability compilers already have a large incentive not to break old programs. For longevity I don't really see how a standard affects it that much. For being more portable you do not need an entirely knew compiler.

Being able to specify a language outside an implementation is extremely useful to prevent hidden logical inconsistencies between different parts of the language, and makes the language more robust.

It also allows people to design new backends (looking at CUDA LLVM backends)by finding out the right abstraction to support performance. For example, implementing a C or C++ compatible CUDA backend required the C++ committee to make changes to the memory model / consistency guarantees of C++ atomics. If C or C++ had only depended on compiler implementation for it, then there would have just been different implementations with different guarantees with no consistencies between them, and no single way to even define why they were different.

Actually it was the other way around, CUDA was fixed to follow C++11 memory model.

There are a couple of CppCon talks on the subject.

Partially correct, even now, SG1 in C++ fixes a lot of things in C++ specification to allow for CUDA like approaches.

The reason it isn't circular is that if there is one implementation, even with good documentation, there will inevitably be lots of corner cases where the implementation does something, but it isn't written down anywhere. Independent implementations will discover many of these issues and they get clarified as part of the standards process.

So you can't really produce a high quality standard with only one implementation. You'll miss important details.

Rust is ,,A language empowering everyone to build reliable and efficient software.'' (from the home page)

Reliability at the extremes (where it may be even life or death situation) requires the developer knowing what the program (s)he is writing exactly expresses in Rust.

>requires the developer knowing what the program (s)he is writing exactly expresses in Rust.

That just need documentation. You don't need a standard for that.