Go is staunch about its specification. To the point that the Go team maintains two independent compiler implementations to ensure that "features"/bugs in one implementation doesn't end up defining the standard and to ensure that a compiler can be implemented from the spec.

There's actually 3 now from google afaik

- gc

- gccgo

- gollvm [0]

[0] https://go.googlesource.com/gollvm/

Is the other compiler you are referring to gcc-go?

C# has a spec, although it's a few versions out-of-date. https://github.com/dotnet/csharpstandard/blob/draft-v7/stand...

Dart has a complete specification. It tends to lag somewhat behind the most recent features (which are documented in separate language proposals), but we keep it as current as we can.

Maintaining a language specification is a lot more work than people realize, and a job that few have the skills to do well.

Standard ML, Scheme, Common Lisp, Java.

In my opinion the presence of undefined behavior in the C/C++ specification makes it no better than the "specification by implementation" approach

C/C++ "undefined behavior" means your program is wrong and not within the spec, not that different compiler implementations might differ. There is no scenario in which any code with UB is valid, regardless of what compiler implementation you use. That's very different. (And IMHO a horrible feature of the spec, but it's there for historical reasons.)

C/C++ spec does have some "implementation defined behavior", which is where you can't rely on what will happen unless you know what compiler you're targeting. They are explicitly listed out as such, and not that common.

without a specification you can never tell with certainty if there's a bug

I guess you have to define "specification" because there's a spectrum. A full book describing the formal syntax, semantics, type system, and standard library/built ins (and macros, preprocessing, compiler flags, what have you) is fairly rare because of how big it needs to be.

Partial specification like the grammar, the type system, etc are more common (particularly because they're so useful for writing one implementation, let alone multiple!).

Raku fka Perl 6.

Ruby?

If you're referring to the ISO spec, it's effectively completely irrelevant.

If you're talking about ruby/spec, a comprehensive test suite is really great, but is also not what most people think about when they think of a spec, though it also may count! You could even argue that such a thing is better than a traditional spec.

Yes, I was thinking about the latter but was unsure if it counted. Yes, looking at the spec has been a helpful strategy for me to understand how something is supposed to work.