But if something like this existed, consumer vendors such as Dell might pre-install it.

Yeah, consistency is good, which is why it's good to follow the spec. I'm saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where code is nested one level below error, plus permitting extra implementation-defined fields in that object.

There is indeed a caveat in the introduction to the Reference that there may be statements in it that are specific to rustc. However, the authors strive to keep statements about the implementation separate from statements about the language.

The main reason there's not yet an "official" spec is that creating one takes enormous time and money, which are always limited resources. (Note that both C and C++ had no formal standard for over a decade after their initial release.) The Reference is "good enough" to make a formal spec not strictly necessary, and the existence of Ferrocene makes it even less necessary, since anyone who absolutely needs a spec can use Ferrocene.

Creation is easy, assuming the many-worlds interpretation of quantum mechanics!

Or Stockholm Syndrome

I'm not sure I understand what issue Linus et al. are trying to solve. If the full hash is used whenever a commit reference is saved somewhere, then why does it matter how core.abbrev is configured? In particular, why use a static value, when git's default behavior is to compute a value based on the current number of objects in the repository? (Edit: just noticed this post is over 10 years old. Maybe git didn't have this automatic default behavior back then.)

For what it's worth, jj has an even better solution, which is to highlight the shortest unique prefix in each specific hash it displays.

Elixir is running on the BEAM. It wasn't invented until 2012, though, so it couldn't have become popular in time to influence the JVM or Netscape.

That's fair, but if you edit the question to explain how it's different (without which, how could anyone even answer your question?), it can be (and often is) reopened.

Uh, neither did you? Both explanations mostly just provide links.

If you're running the GUI locally, what makes it "too bulky"?

FWIW, I believe emacs has good support for remote editing, though it requires more configuration than VSCode.

Jeeze, I knew that simplicity was the goal (and I think they largely succeeded in that), but that quote is so explicitly condescending. "They're not capable of understanding a brilliant language"?

I disagree slightly with the need to add full ADT support to the language to implement that style of error handling, because Pike et al. had no problem adding "special cases" to the language: in particular, return values are essentially tuples, but that's the only place in the language with that concept. So they wouldn't need to introduce user-definable enums and full pattern-matching to have better error handling. I can think of a couple approaches they could have used:

• Use compound-return-values as they currently exist, but have additional compiler-enforced restrictions:
  • There can be at most one error value in the return types, and it must be the last element in the "tuple"
  • when returning a non-nil error, the other values must be zero/nil
  • the compiler would require all errors to be checked, never ignored (Go should have at least done this, even without the other stuff)
  • Add the question-mark operator, which would do basically the same thing as in Rust: check if the error value is nil, discard it if so, return early if not
• Have a special "result" type that is quasi-generic (like slices and maps) and treated as a sum-type by the compiler, but which can only be used as a return value from functions. Provide some special variant of the switch statement to destructure it (akin to how type switches have their own bespoke syntax/keyword).

It absolutely can be constructive. The reason people respond that way on SO is because it is genuinely common for people to think they need something because they've misinterpreted the core problem they have.