Error codes are googlable.

Things like "TS1234", "flake8 E802", "Yarn E4882" etc are pretty much guaranteed to give you the results you want. Whereas "yarn some-error-text" can be much noisier, especially if the error text changes over time, is short, is obscure or even translated. Worst case they're also more greppable inside the codebase.

Error codes are a really, really good idea if your application is popular and used by devs, IMO.

> if your application is popular and used by devs

I'd argue even if it's not popular and it's used by non-devs.

Error codes saved our support people a ton of time when trying to understand user problems. It's good for the user to be able to understand the problem, but it's great when they can call you up or send a ticket in about error "E4882", and you instantly have a good amount of information about the problem.

As far as Rust is concerned[0] the error code is accompanied by a pretty extensive error message (with lots of arrows and suggestions) but the actual error code documentation is basically an entire book page, it would be completely unusable if that much stuff were printed to the terminal. So the compilation error provides an explanation and the error code links to an expanded explanation.

For instance, this is the basic "use after drop" error message:

    error[E0382]: borrow of moved value: `s`
     --> src/main.rs:5:20
      |
    4 |     drop(s);
      |          - value moved here
    5 |     println!("{}", s);
      |                    ^ value borrowed here after move
      |
      = note: move occurs because `s` has type `std::string::String`, which does not implement the `Copy` trait

this is the expanded explanation: https://doc.rust-lang.org/stable/error-index.html#E0382 On my machine, I have to "page down" twice to get through the entire thing. "rustc --explain E0382 | wc" tells me the markdown source is close to 110 lines and 550 words.

And as other people noted, hopefully other folks discussing the issue used the error code, which makes their discussion not just more easy to find but survive localisation: if you get a localised error message it's almost impossible to find information on it unless it's absolutely ubiquitous, because the vast majority of the discussions (and especially the most useful discussions) are going to refer to the non-localised version, which your software will not provide.

edit: I can understand taking issue with it though, some systems do use error codes to skimp on the actual error messages. I recall Oracle being a particularly bad offender.

[0] I'd expect Typescript is the same, but don't know for sure

The Rust compiler generates unique error codes for every type of error, and suggests that you run the command `rustc --explain E0275` (as an example) to get more information on the error, with an (often) in-depth description of what the error means, how it is usually caused, how to potentially fix it, etc.

This is extremely useful, because the error output can focus on just saying what the error is (which is great when you already know what the error means), and there is an obvious next step to get more information if you need more help.

And if you don't find the answer, searching online for "rust E0275" gives much more relevant answers than trying to search the right parts of the error message.

In general it improves interoperability between non-human systems.

Say that you have a database. When you ask it for a specific piece of data, and it can't find it, it shows 'data not found'.

Then I build a program that reads information from that database; I program it so that if it receives the text 'data not found' it knows to handle the error somehow.

Ten days later, the guy who programs the database decides that 'oops! we couldn't find the element :(' is a more friendly message to the user. Now my program will stop working until I switch it to the correct error text.

With an error code those kind of things don't happen. If you need extra legibility you can totally send both a code and a message, but the code is expected to remain unchanged and I can trust that it will stay the same in the future.

Grouping behaviours is another use. For example, if I have a system that sends you information and you have sent me wrong input, there's a dozen ways you could have done that (maybe you didn't send me enough data, or you sent it in chinese characters I don't recognise, or I just got gibberish I can't even start to understand). All of those cases might require different messages to the final user, but internally for me they're the same thing ('invalid data') and the things I'll have to do will be the same, so propagating a code serves me well.

There's also the issue of internationalization. If 200 android users across the world are having problems with their phones, and they all get an error 3242, they'll be able to find proper help. If one is showing "the application couldn't start due to memory issues", the other "la aplicacion no pudo iniciarse por problemas con la memoria" and yet another shows "لا يمكن بدء التطبيق بشكل صحيح" we're gonna have trouble identifying all those things as the same problem.

Humans are not always the consumer of error output. Distinct error codes simplify parsing and eliminate ambiguity.

It also makes it easier for developers look up a specific error in the documentation, assuming it's been documented.

It's also easier for a (technical) user to reference they got error 1018 than copy & paste "An index signature parameter cannot have an accessibility modifier." Especially in titles and when referencing it multiple times within a body of text.

Updates can improve on the error messages, making them more clear, the error code does not change but the message changes.

Also many times the error message is interpolated with your specific details like

"Syntax error at line 123 in file /home/user/myfile , symbol X is not allowed here" this is a silly example but often enough when i google this errors I have to first strip out my data from them.

Googling the text of an error often finds lots of unrelated results. So no, the docs might not be the top hit.

All errors are google-able?

All the responses so far are seem really helpful but also quite specific. It might also be useful to understand the problem space at a higher level. We also see this in good database design. Which says that every record should always have a unique id that is not related to any of the other data. This allows you to freely change things like product descriptions, short name, SKU, price, weight, etc. Because you know that no matter what else changes, you have a unique ID to refer back to, that will get you to that product. Since a unique ID is often a random looking string, there is nothing stopping you from also having a human friendly lookup code for a product. For example, unique id is 186746, but the lookup code is BRWNCOUCH37. If the couch doesn't change color, the lookup code stays good. But if it does, you can change even the lookup code. Because the product unique id remains 186746.

So unique IDs are useful in many places other than just error codes. Hope that helps.

That's exactly the point. The unique error code matches up with documentation so you can easily research your problem. Especially helpful with Google. Yarn "some error happened" is a lot more difficult to track down than Yarn "Error 3617" even if Error 3617 doesn't immediately provide more information.

Many scripts rely on the error's in order to decide what to do. When you have error codes, you can then change the actual description of the error without breaking the scripts that rely on the error codes. You can also show the errors in different languages depending on the user's settings.

To add to the other replies - you quickly find the utility of error codes when working on a product that ships in many different languages. Diagnosing a bug report from, say, a Chinese user can be a lot easier if the screenshot with the error message also has the code in it somewhere.

You can also ask "why do programmers love GUIDs" and probably receive a similar response.

The HTTP protocol is another famous example of user-facing error/status codes that don't necessarily mean anything on their own.

This isn't really relevant for something like Typescript, but for traditional applications, error codes can help with establishing observability metrics if properly collected, aggregated and analyzed.

IMO Error codes are easier to search then english error descriptions.