Go 2 Considered Harmful: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
I wonder how many people got the joke without reading the link. Good one, boss.
Go 2, here we come
81–90 of 534 posts
Re: Go 2, here we come
#82Earlier quoted context omitted.
Actually, the issues you mention are already fixed by Go modules. EDIT: Removed a parenthetical that was based on a misreading of the parent.
I believe they’re saying that vendor support is a good thing in Golang.
Thanks; I definitely misread. I deleted the relevant bit from my post.
Re: Go 2, here we come
#83I haven't been keeping up with Go much these days but is there proper debugger support now? Or is it still a half-broken experience?
I've never had any issues with debuggers over the past year of developing full-time in it.
I use GoLand for development, which I believe uses Delve by default and it's entirely pleasant.
Re: Go 2, here we come
#84I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. Haven’t tried it since. Hope lots of this change to make the language more welcoming for Newcomers to the language.
Same here. For me it was primarily the syntax. So many people think that syntax is something you get used to, but I don't. Syntax matters a lot for me, and the way Go does it just isn't compatible with my brain. Regular grammars are great for parsers. But really, having an easy to read (conceptually!) language is way more important imho. But call me crazy when I say that I like C++ and can read it effortlessly :)
Well of course you get used to it, like you did get used to C++ (unless you were born that way which I doubt).
It just takes time, you don't want to spend that time getting used to Go and that's perfectly understandable.
Re: Go 2, here we come
#85Earlier quoted context omitted.
So what is it? I'm on my phone and don't feel like downloadig a random PDF just for curiosity...
It's a pun. "Go 2" -> "Go To". Dijkstra coined "considered harmful" with the paper (letter) on "Go To statement considered harmful".
I seem to remember seeing a few articles about "'$X considered harmful' considered harmful'.
Also: Why Functional Programming Matters
and
Why Why Functional Programming Matters Matters
Edit: Just saw the sibling comment by Stratoscope:
"we would see all sorts of articles under the title 'X considered harmful' for almost any X, including one titled "Dijkstra considered harmful."
:)
Re: Go 2, here we come
#86I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…
Makes no sense to me to redefine existing integer types. Why not introduce a primitive type "num" for arbitrary precision rational numbers instead?
As a long-time Racket and Scheme user, I'd say that arbitrary precision numbers as default bring more disadvantages than advantages. As an option with syntax support Yes, but not as a default. it just makes it harder to port all kinds of code that relies on modulo arithmetics.
Re: Go 2, here we come
#87I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…
That would be quite a fundamental change. At the moment _int_ and _uint_ have certain semantics that, if changed, would surely break many applications and libraries that rely on the current semantics. I am finding it hard to think of a more sweeping and drastic change to the core of a language. Having said that, I'm by no means a Golang expert – this is the comment of an outsider looking in. I get that the proposer i…
If the change as originally proposed went through, it probably wouldn't affect most uses of bitbanging low level code because they are already using int32/int64 rather than int (which has different size on different platforms). You are correct that it could definitely break some programs though, and so with recent sensibilities veering away from making any non- backwards-compatible changes, an amended proposal would probably just introduce a new "vint" type (maybe removing the old int type at the same time if it is really ambitious)
Re: Go 2, here we come
#88I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…
I am misunderstanding or really go is using the ‘int’ type that can be 32 or 64 bit depending on the system that it runs on???
If this is the case I think that is crazy and I can’t think of any useful use case for it.
If it’s not the case then please explain me what that proposal is really about...
Re: Go 2, here we come
#89Earlier quoted context omitted.
If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets you avoid using GOPATH. I believe it's going to be non-experimental starting in 1.12.
That's terrific news! GOPATH and the file system conventions are horrible for me as well. It forces me to break my personal conventions and workflow that I use for every other language. I avoid using go for new projects now because it got to be so annoying and disruptive (a somewhat shallow reason, I know).
That's not a shallow reason: the annoyance in aggregate motivated a language usability improvement with no regressions.
Re: Go 2, here we come
#90Earlier quoted context omitted.
If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets you avoid using GOPATH. I believe it's going to be non-experimental starting in 1.12.
> there's an experimental feature That's not a feature but a fix for a design problem, and currently the only fix is an experimental one. For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.
Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.