21–30 of 150 posts
Speaking of errors, here's how i approach writing a good error message. Fill in the blank "Well basically what happened is ___________" For example i've found this has helped me to go from "Invalid phone number" to "The phone number needs to be 10 digits"
Earlier quoted context omitted.
> I would suggest new code uses the new, formal ways of obtaining the same result I missed that. How else do you wrap an error with xerrors?
return errors.Wrap(err, "read failed")
It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable.…
Over the decades as a programmer I have seen a lot of language come and go. A lot of languages suffer from "features". Where either a language is designed with advanced concepts getting either directly in the way of writing simple programs, or even worse, getting bolted on later on, creating something very different from the initial language.
I love the dependable simplicity of Go. It contains everything I need for a surprisingly large part of my work and not offering more than that is an asset. Few things in Go feel like they had been thrown in without proper consideration.
It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable.…
I've heard great points and experienced myself how utterly legible go is. But nobody on earth has ever praised anything about the language design itself. I wonder if go came from somewhere not google- how would it fare.
Earlier quoted context omitted.
> I would suggest new code uses the new, formal ways of obtaining the same result I missed that. How else do you wrap an error with xerrors?
return errors.Wrap(err, "read failed")
Personally, I don't care for "string magic"
Edit: Instead of making another post, I'll add this here. It also feels odd that concerns about xerrors.As possibly panicking at runtime are considered addressed by the addition of a go vet check: https://github.com/golang/go/issues/29934#issuecomment-46252...
I am not opposed to go vet, to be clear, but one of the aspects of the go compiler is that it does not warn, only errors out if compilation can't proceed. But the design of xerrors.As is fine because go vet acts like a compiler warning might? This is an aesthetic complaint more than anything else, but it still doesn't sit right with me.
Earlier quoted context omitted.
return errors.Wrap(err, "read failed")
That's what I do now with pkg/errors, but I don't see a xerrors.Wrap in the docs or any mention of it in the proposal.
I suppose it won't take long for a component of one of the gometalinter or golang-ci or whatever to develop a "Errorf used without %w in the final position" warning, which will be good enough for me, but it would be better to have something like Wrap officially, IMHO.
It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable.…
And I am so happy that they won't do anything but the right thing. Over the decades as a programmer I have seen a lot of language come and go. A lot of languages suffer from "features". Where either a language is designed with advanced concepts getting either directly in the way of writing simple programs, or even worse, getting bolted on later on, creating something very different from the initial language. I love t…
That's clearly not true - they've made plenty of mistakes.
Earlier quoted context omitted.
I've heard great points and experienced myself how utterly legible go is. But nobody on earth has ever praised anything about the language design itself. I wonder if go came from somewhere not google- how would it fare.
Dart also came from Google. Why isn't everyone jumping on that train?
Dart struggled for years to find a killer app, though Flutter now seems to be a good bet.
Originally the idea was to replace JavaScript and everyone except TypeScript pretty much failed at that. (I mean failed from a popularity point of view, they often succeeded technically.)
I'll also point out that coming from Google is kind of a mixed blessing these days, from a popularity standpoint.
Earlier quoted context omitted.
I've heard great points and experienced myself how utterly legible go is. But nobody on earth has ever praised anything about the language design itself. I wonder if go came from somewhere not google- how would it fare.
Dart also came from Google. Why isn't everyone jumping on that train?
Earlier quoted context omitted.
I've heard great points and experienced myself how utterly legible go is. But nobody on earth has ever praised anything about the language design itself. I wonder if go came from somewhere not google- how would it fare.
Dart also came from Google. Why isn't everyone jumping on that train?