4 ms·

The sad thing about this is: Imagine how amazing our languages and tooling could be if there was a happy path for talented people to work on this. For example

The sad thing about this is: Imagine how amazing our languages and tooling could be if there was a happy path for talented people to work on this. For example, the error messages in Elm are just insanely better than in any other language I know. Like, it's not even in the same ballpark. Why doesn't every language have this? But that's just an example. In general, I think we under-invest in tooling.

vlovich123 3y ago
Can you give an example? I find Rust’s error messages to be also very good in most cases, but I’ve been in C/C++ land so long I don’t know what the state of the art actually looks like. Also, do you think Elm’s error messages come from a simpler language design? For example, some of Rust’s ability to provide better error messages come from the language improvements relative to C/C++ itself I think.
- mbStavola 3y ago
  Fun fact, Rust's human readable errors were inspired by elm[1]. [1]: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...
- deleted 3y ago
  [deleted]
- diggan 3y ago
  I'm fairly sure I read somewhere that Rust error messages were inspired by the great error messages popularized by Elm. And in most cases, it's just a matter of sitting down and really thinking about what is the best error message you could provide in that specific scenario, what context is needed any so on. Instead of just writing down the first thing that comes to your mind, and never iterating on it ever again.
CSSer 3y ago
Oh, absolutely. This came up in a conversation I had with a friend last night about antitrust in tech. Not only do we underinvest in tooling but only the largest companies have the spare time and resources to do so. I think this has led to many modern open innovations only realistically being useful for solving the problems of very large companies. On a cynical day I might even accuse certain tools of being designed that way for job security. Or at least it looks that way because the majority of people who are using the tool could only dream of getting approval from management to make a better alternative. The priorities of many of the tool maintainers, no matter how honest, just don’t match like they used to, and this is in an ecosystem awash with telemetry.
phillipcarter 3y ago
I don't think it's really a matter of having more people working on this stuff. For everyone who craves better ergonomics for the "easy" stuff, there's someone who demands ever more advanced features. It's not possible to keep both camps happy, even when there's immense financial investment. This is exactly my experience doing this work for ~5 years.
estebank 3y ago
> For example, the error messages in Elm are just insanely better than in any other language I know. Like, it's not even in the same ballpark. Why doesn't every language have this? It's a combination of economics (who pays for the work? It could be people scratching an itch, but these people also have to have the privilege of being able to pay their bills somehow), difficulty (it's not a trivial problem space, you need to turn your compiler into one that understands not only its own language but also every potential language people try, and the errors might crop up in unexpected places where the context you need to provide good errors is long gone, so you must change the compiler to a bowl of spaghetti design, so you can access, for example, the type checker during parsing) and inertia (developers are used to building tools for themselves, so they dont spend time on diagnostics because they are already familiar with the inner workings od the tool, then other developers use those tools and because every other tool is like that they don't expect good errors, so no one considers them important enough, and the cycle goes on and on). But let me be clear on one thing: although there are many things in your language design and compiler implementation that you can do to make things easier on yourself (don't throw anything away related to the causal relationship for why a certain constraint is present!), the work is mostly elbow grease, and spit and polish, little more.

vlovich123 3y ago

Can you give an example? I find Rust’s error messages to be also very good in most cases, but I’ve been in C/C++ land so long I don’t know what the state of the art actually looks like. Also, do you think Elm’s error messages come from a simpler language design? For example, some of Rust’s ability to provide better error messages come from the language improvements relative to C/C++ itself I think.

mbStavola 3y ago
Fun fact, Rust's human readable errors were inspired by elm[1]. [1]: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...
deleted 3y ago
[deleted]
diggan 3y ago
I'm fairly sure I read somewhere that Rust error messages were inspired by the great error messages popularized by Elm. And in most cases, it's just a matter of sitting down and really thinking about what is the best error message you could provide in that specific scenario, what context is needed any so on. Instead of just writing down the first thing that comes to your mind, and never iterating on it ever again.

CSSer 3y ago

Oh, absolutely. This came up in a conversation I had with a friend last night about antitrust in tech. Not only do we underinvest in tooling but only the largest companies have the spare time and resources to do so. I think this has led to many modern open innovations only realistically being useful for solving the problems of very large companies. On a cynical day I might even accuse certain tools of being designed that way for job security. Or at least it looks that way because the majority of people who are using the tool could only dream of getting approval from management to make a better alternative. The priorities of many of the tool maintainers, no matter how honest, just don’t match like they used to, and this is in an ecosystem awash with telemetry.

phillipcarter 3y ago

I don't think it's really a matter of having more people working on this stuff. For everyone who craves better ergonomics for the "easy" stuff, there's someone who demands ever more advanced features. It's not possible to keep both camps happy, even when there's immense financial investment. This is exactly my experience doing this work for ~5 years.

estebank 3y ago

> For example, the error messages in Elm are just insanely better than in any other language I know. Like, it's not even in the same ballpark. Why doesn't every language have this? It's a combination of economics (who pays for the work? It could be people scratching an itch, but these people also have to have the privilege of being able to pay their bills somehow), difficulty (it's not a trivial problem space, you need to turn your compiler into one that understands not only its own language but also every potential language people try, and the errors might crop up in unexpected places where the context you need to provide good errors is long gone, so you must change the compiler to a bowl of spaghetti design, so you can access, for example, the type checker during parsing) and inertia (developers are used to building tools for themselves, so they dont spend time on diagnostics because they are already familiar with the inner workings od the tool, then other developers use those tools and because every other tool is like that they don't expect good errors, so no one considers them important enough, and the cycle goes on and on). But let me be clear on one thing: although there are many things in your language design and compiler implementation that you can do to make things easier on yourself (don't throw anything away related to the causal relationship for why a certain constraint is present!), the work is mostly elbow grease, and spit and polish, little more.