3 ms·

> That's bad Go design. An API where the particular nature of the error matters, should declare error constants and use the "Is" mechanism. You shouldn't be un

by aikah 7y ago

> That's bad Go design. An API where the particular nature of the error matters, should declare error constants and use the "Is" mechanism. You shouldn't be unpicking the internals with an IDE, you should be getting something you can work with, right there. AKA roll your own stack trace library. That's what "errors" package and co are. That's not "bad God design". It's just not Go's problem, as deemed by Go designers. Thus criticizing that trade-off is fair, like any trade-offs.

apta 7y ago
So we're back to C where each project rolls out its own string implementation. This really shows the mentality of the golang authors.
- aikah 7y ago
  I mean at that point if you are still using Go, then you agree with whatever Golang authors tell you. Most people who were sceptical about Go or were vocal about trying to improve the language moved on to something else, because they faced a wall of contempt. The whole Go 2 stunt is more an "idea parking lot" than anything else.
_ph_ 7y ago
First of all, there are plenty of stack trace libraries to use. Then, the Go creators gave you the chance to roll out whatever mechanism you want, because they made "error" a minimal interface. This is actually quite a feature. You are not forced into a complex mechanism which might be badly fit to your requirements. And finally, rolling out a "stack trace library" should be like writing 2-3 functions which you can use all around in your project. The interesting thing about the new error APIs is, they are just auxiliary APIs. Every user could have written them, they are not mandatory to be in the core language or even in the compiler. They are just added as a standardized guideline how common tasks are handled and especially are standardized across packages from different maintainers, if they decide to follow that convention.
JulianMorrison 7y ago
That isn't a stack trace, it's wrapping a specific complaint around a category of complaint. The Java equivalent would be a specific FileNotFoundException with a text mentioning a file name, versus the general class hierarchy of FileNotFoundException -> IOException -> Exception which is routinely used for "Is" tests in Java.

by aikah 7y ago

apta 7y ago

So we're back to C where each project rolls out its own string implementation. This really shows the mentality of the golang authors.

aikah 7y ago
I mean at that point if you are still using Go, then you agree with whatever Golang authors tell you. Most people who were sceptical about Go or were vocal about trying to improve the language moved on to something else, because they faced a wall of contempt. The whole Go 2 stunt is more an "idea parking lot" than anything else.

_ph_ 7y ago

First of all, there are plenty of stack trace libraries to use. Then, the Go creators gave you the chance to roll out whatever mechanism you want, because they made "error" a minimal interface. This is actually quite a feature. You are not forced into a complex mechanism which might be badly fit to your requirements. And finally, rolling out a "stack trace library" should be like writing 2-3 functions which you can use all around in your project. The interesting thing about the new error APIs is, they are just auxiliary APIs. Every user could have written them, they are not mandatory to be in the core language or even in the compiler. They are just added as a standardized guideline how common tasks are handled and especially are standardized across packages from different maintainers, if they decide to follow that convention.

JulianMorrison 7y ago

That isn't a stack trace, it's wrapping a specific complaint around a category of complaint. The Java equivalent would be a specific FileNotFoundException with a text mentioning a file name, versus the general class hierarchy of FileNotFoundException -> IOException -> Exception which is routinely used for "Is" tests in Java.