41–50 of 150 posts
Earlier quoted context omitted.
Can you elaborate on the major developments in error handling in the last 30 years?
I assume exceptions, the Error/Either monad, and StatusOr.
Re: exceptions, there are a lot of people, myself included, who do not view exceptions as "advancements", but as setbacks. Magically and suddenly subverting the normal control flow and unwinding the stack in highly concurrent programs (as is expected in Go) is an awful way to do error handling, and you end up having to bypass that mechanism and pass the errors as values across call stacks anyway, so what are you really gaining for all the extra complexity, "implicitness", and cognitive load of doing that?
Earlier quoted context omitted.
> I use this language extensively but its weirdly mediocre design is totally unfathomable. So then why do you use it extensively?
because I use it in my day job, not by choice.
Earlier quoted context omitted.
because I use it in my day job, not by choice.
So what language do you think does everything the right way?
Earlier quoted context omitted.
It is. It's a backwards-compatibility magic string hack. I would suggest new code uses the new, formal ways of obtaining the same result. (I'm not defending it so much as explaining it. I'm not sure how I feel about it myself.)
Backwards compatibility with what? You have to change the code to do anything new, that change could be using a different function entirely.
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.
There was a precursor to golang that the some of the same authors worked on before they were at Google. It didn't go anywhere, precisely because it didn't have Google's name behind it.
I suspect that the overwhelming majority of Go developers has no idea this is in the works. It was covered once on the blog last August in the Draft Design summary, when there wasn't any code behind it. It was not mentioned in Go 2 Here We Come[2], nor at the start of the below golang-dev thread. It was mentioned on golang-dev when I posted a link to the issue tracker in late January, but my posts would see a fraction of the attention vs those by Rob, Robert, Russ, Ian, et al.
There are outstanding issues with the current draft, specifically its performance[3] and API[4].
If it lands in 1.13, please give it Experimental status, with a build or env flag to disable changes to existing APIs, and perhaps a way to re-enable them on a per-function or per-package basis.
[1] https://github.com/golang/go/issues/29934
[2] https://blog.golang.org/go2-here-we-come
[3] https://github.com/golang/go/issues/29934#issuecomment-48650...
[4] https://github.com/golang/go/issues/29934#issuecomment-48350...
.
[Originally posted on golang-dev, in response to "Last call for feedback on Go 1.13..."]
https://groups.google.com/d/topic/golang-dev/jPY0RYXSvCU/dis...
Earlier quoted context omitted.
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…
> And I am so happy that they won't do anything but the right thing. That's clearly not true - they've made plenty of mistakes.
Of course, any humans are making mistakes in the process nevertheless, but overall I think they got it pretty much right.
Having said that, I would be curious what you have in mind when saying that they made plenty of mistakes?
Earlier quoted context omitted.
> And I am so happy that they won't do anything but the right thing. That's clearly not true - they've made plenty of mistakes.
The only big one that comes to mind is GOPATH. What are you thinking of?
What is your issue with GOPATH, that you call it a big one?