33 ms·

Go 2, here we come

816 points by mdelias 8y ago

gnarbarian 8y ago
Go 2 Considered Harmful: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
- sdegutis 8y ago
  You got me. Genuinely thought it was gonna be a critique.
  - dao- 8y ago
    So what is it? I'm on my phone and don't feel like downloadig a random PDF just for curiosity...
    - williamdclt 8y ago
      Dijkstra's critique of the `goto` statement
    - barrkel 8y ago
      It's a pun. "Go 2" -> "Go To". Dijkstra coined "considered harmful" with the paper (letter) on "Go To statement considered harmful".
      - Stratoscope 8y ago
        It was actually Niklaus Wirth (designer of Pascal and other languages) who coined "considered harmful": > In 1968 the Communications of the ACM published a text of mine under the title "The goto statement considered harmful, which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a templace: we would see all sorts of articles under the title 'X considered harmful' for almost any X, including one titled "Dijkstra considered harmful." > But what had happened? I had submitted a paper under the title "A case against the goto statement, which in order to speed up its publication, the editor had changed into a 'Letter to the Editor', and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth". https://www.theregister.co.uk/2002/08/08/edsger_dijkstra_rip/ https://www.theregister.co.uk/2002/08/08/edsger_dijkstra_rip... https://en.wikipedia.org/wiki/Considered_harmful https://en.wikipedia.org/wiki/Considered_harmful
      - vram22 8y ago
        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." :)
        Stratoscope 8y ago
        And this classic by Scott Meyers of Effective C++ fame: "Considered Harmful" Essays Considered Harmful https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html
        vram22 8y ago
        Thanks, will check that out. I really liked the Effective C++ book by Scott. There's a good video talk by him titled something like "The Last Thing D Needs".
    - naibafo 8y ago
      > Edgar Dijkstra: Go To Statement Considered Harmful
      - Someone 8y ago
        Edsger, nog Edgar (http://www.cs.utexas.edu/users/EWD/ http://www.cs.utexas.edu/users/EWD/) Dijkstra would lambast you for that error :-)
        naibafo 8y ago
        He probably would :) But I just quoted the linked PDF a few comments above in the chain.
- agumonkey 8y ago
  Well played sir
- Zenst 8y ago
  When I started work in the early 80's as a COBOL analyst programmer, I encountered ideology vs reality of GOTO. When I learned COBOL, I was taught Jackson Structured Programming. No use of GOTO at all, even exception handling. Fast forward in my first week into work and having done a nice JSP program for the task at hand a senior came over with my code and had a chat. Then took me to the system developers who did all the dirty low level assembler code (for sorts and other area's in which speedup was huge over COBOL). Was shown how my approach was far more wasteful of CPU resources and why others would not be able to maintain such code as all the rest used GOTO's. I will admit, it was nicely explained and this is in a time in which mainframes offered the only computer solutions for business of this scale and not cheap. I will say GOTO's work well for exception handerling, but still doable without. But for speed, though less of a factor today, it still translates as faster code at the low level of CPU runs. But then, things move on and you will always have that wave of what students are taught being cutting edge compared to what is actualy in use in work. A friction many would have encountered in one form or another, even today. Be it style, design or language/tools choice. What is the best today, may well be outdated tomorrow, but you have to maintain that legacy investment and it is often too costly/risky to rewrite that legacy for something that itself could be legacy the next day. So as for harmful, well they can spagetti up code if used badly, yet that comes to many approaches and if they are that bad, why do CPU's still have JUMP instructions you could counter-argue. Oh and well played on the humour.
  - fwip 8y ago
    Are there normal coding patterns that are much faster with explicit gotos? Modern compilers seem to do a pretty good job of converting normal (goto-less) code into efficient binaries. E.g, the simple switch statement has several possible machine-code implementations that compilers will switch (heh) between, depending on the characteristics of the cases.
    - beetwenty 8y ago
      In bytecode interpreter VMs, one often encounters the "computed goto" [1] pattern in use to dispatch opcodes. This is one that tends to be a little faster than a switch statement, enough to matter in the dispatch inner loop. Of course, if you are going to JIT compile the bytecode, that'll usually be a lot faster. But at that point you're changing one form of low-level wizardry for another. [1] https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...
- vram22 8y ago
  I wonder how many people got the joke without reading the link. Good one, boss.
  - brlewis 8y ago
    I did because I'm a native speaker of English, am familiar with "goto considered harmful", and I noticed Dijkstra in the link.
    - vram22 8y ago
      >I noticed Dijkstra in the link. That's how I figured out the joke too - that plus the start of the comment :)
- slap_shot 8y ago
  I appreciate a good joke, but is this really necessary on a thread like this? Here's the equivalent Reddit thread; better suited for this sort of comment: https://www.reddit.com/r/golang/comments/a1j3h6/go_2_here_we_come/ https://www.reddit.com/r/golang/comments/a1j3h6/go_2_here_we...
  - tyrust 8y ago
    Smaller subreddits (like the one you linked) are typically against shitposting as well.
  - deleted 8y ago
    [deleted]
- colonelpopcorn 8y ago
  I came here just to say that. Glad to see I wasn't the only one.
- hu3 8y ago
  this kind of comment says a lot about current state of HN this is the new Reddit
  - burke 8y ago
    God forbid that one of 208 comments is a (rather funny) joke. I don't get why some people here are so against humour. I appreciate the high standards for jokes and expectation of high signal:noise, but this was clever and topical.
- codegeek 8y ago
  I always appreciate a good joke but unfortunately this has become the top comment as of now and is not adding to the real discussion around Go 2. This is a typical case of when I use my downvote power. Great joke but we should keep HN noise free.
  - esrauch 8y ago
    Is it really so harmful to have it at the top of the comment thread? I think HN can be focused mainly on serious discourse without being completely humorless.
    - codegeek 8y ago
      I think about it all the time. But imagine leaving the page and coming back a few hours later. Now you have to sort through tons of unnecessary comments (even if funny and humorous) while you look for the quality stuff. Quality requires sacrifice and I am willing to sacrifice the humor part for quality unless you throw in a bit of humor with quality content.
      - Stratoscope 8y ago
        A great way to solve this is to use the [-] button to collapse any comment threads that you're not interested in following, like this one. HN remembers which threads you've collapsed, so you won't see them when you come back to the page.
twoodfin 8y ago
Rob Pike had a good talk on the Go 2 process and a few of the proposals that went up on YouTube a few days ago: https://youtu.be/RIvL2ONhFBI https://youtu.be/RIvL2ONhFBI
glenrivard 8y ago
Big fan of both Go and also Rust. It is time we move beyond C and C++
- freedomben 8y ago
  I apologize for asking a question that will likely lead to a flame war regardless of your answer, but which is better? I've used Go for a while for certain apps, but as a primarily functional programmer I find my way of thinking often clashes with the language (and I also don't like the verbosity). So, do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than Go?
  - tazjin 8y ago
    As a Haskell & Erlang person who currently uses Rust as my primary language at work: > do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than Go? Yes, yes. Obviously the Rust ecosystem has fewer mature libraries, but its type system and error handling make Go look like a toy. Go can be okay for small one-off tools, but its safety guarantees are not far ahead of scripting languages and I think it should be considered as such.
  - tptacek 8y ago
    This is like asking for a language war, which is the last thing we want on a language thread. You shouldn't have any problem finding already-existing Go vs. Rust discussion either in the search bar here or on Google.
  - foldr 8y ago
    Rust has much better support for a functional style. On the other hand, not having a GC in Rust means that dealing with closures can in some cases get quite complicated, whereas closures in Go work exactly as you'd expect. (Although to be fair, if you aren't doing any mutation, closures in Rust are pretty easy to deal with.)
  - jpgvm 8y ago
    Both are fundamentally different, neither is "better". They are both good at slightly different things. If your desire is to accept bytes over the network and spit back bytes over network Go is going to be a pretty solid choice because that was very much the focus of it's design. However if you want to build an application for a hard realtime environment and you either lack the space for runtime or can't handle GC pauses then maybe Rust is a better choice. From a language perspective Go is a simple language and Rust is a complex language. The two have different tradeoffs here. Go is easy to learn, has limited pitfalls but also lacks in the power department if you need metaprogramming and abstractions to model your problem. Rust however accels in that role due to it's powerful type system and hygienic macros. The tradeoff is very apparent once you try use the two languages however, Rust is -far- more difficult to both climb the initial learning curve and has a much higher ceiling. Fundamentally you will probably find Go is better at replacing dynamic languages though there are many cases where C/C++ was used where it's bare metal nature isn't needed and Go is a very suitable replacement. Go however has some difficulty in replacing certain usages of C/++. Namely it can't easily be used to create a shared library because of it's runtime and I/O system. That said if you wanted to be able to replace any and all C/C++ code Rust would be a better choice as it can do anything C/C++ can with no downsides. i.e embedded systems, shared libraries, bare metal access without worrying about the green threaded execution model. There are many other things to consider too but these are some of the important ones from someone who got into coding doing C and embedded, has since learnt both Go (and used professionally) and Rust (and used for side projects). Subjectively I think Go is a better choice when it can do the job as it's easier and less brain intensive to just do the thing. Rust however is more "fun" to program in as it's a less mechanical endeavour and also can solve some problems you can't with Go.
rjplatte 8y ago
I'll be very sad if this goes the way of Perl 6
- bradfitz 8y ago
  It won't. It's an explicit requirement that it will not. Or even a Python 3. I had a slide saying as such in an earlier presentation: https://docs.google.com/presentation/d/1DmyTABhGLvN0m2uHktvkP_uXop6-Xy5HPNovjDKJ83g/edit#slide=id.g3140eee711_0_877 https://docs.google.com/presentation/d/1DmyTABhGLvN0m2uHktvk... (slide 140) Ian had a good talk & doc about this too recently: https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md https://github.com/golang/proposal/blob/master/design/28221-... https://www.youtube.com/watch?v=LqKOY_pH8u0 https://www.youtube.com/watch?v=LqKOY_pH8u0
  - dunpeal 8y ago
    How can you have an "explicit requirement" not to end up like Perl 6? Nobody planned to "end up like Perl 6", it's just something that happens when your new, backwards-incompatible version of the language doesn't catch on. Also, sounds like Go 2 is going to make backwards-incompatible language changes. How is that different from Python 3, or even Perl 6?
    - bradfitz 8y ago
      Perl 6 decided from the beginning to break away from Perl 5 and not care about backwards compat. That was their choice. We don't make the same choice.
      - dunpeal 8y ago
        But Go 2 is also introducing backwards incompatible changes, no?
        bradfitz 8y ago
        See the doc I linked above: https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md https://github.com/golang/proposal/blob/master/design/28221-... Probably not. We can add things and we can opt-in remove things (e.g. user says they want v1.14 of language gets them new language features and removes some language features), but we can't change the semantics of existing programs. That is, if a program compiles with two different language versions, that program should mean the same in both versions.
jonathanstrange 8y ago
I hope they keep the changes reasonable and do not introduce any breaking changes. I like the language as it is now and I'm very productive in it.
- jsmith45 8y ago
  Well for the first round they are looking at: 1. Allowing generalized unicode identifiers. That is hardly likely to break anything except possibly some crazy edge cases that dont happen in real code. 2. Binary integer literals. (unlikely to break things) 3. allowing seperating groups of digits in a number with _ like 1_000_000 (unlikely to break anything) 4. Permit signed integers as shift counts (no need to cast ant int to a uint to use it in a shift expression. This won't break any existing code). So at least this first round is quite unlikely to break anything in real use.
  - bryanlarsen 8y ago
    For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.
    - stcredzero 8y ago
      It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?
      - copperx 8y ago
        That's a good question because they ostensibly do it to get more users aboard, but in most cases, the result is the opposite (e.g., the Python 2/3 disaster).
        8y ago
icholy 8y ago
> Go 2 will be much more community-driven. Please no ...
- bsaul 8y ago
  There must be some very angry people downvoting on this comment section today. Go is very opinionated and it's quite obvious that its original design being so radical (no class, no inheritance, no generics, no macro) was only possible because it was designed by a few very experimented people with a very specific goal in mind. I'm also worried about how being "community driven" will change the philosophy of the language.
  - AnimalMuppet 8y ago
    I think "community driven" means less than you fear. I think it means that community feedback is used to push the language in directions that scratch some of the major community itches. That seems perfectly reasonable to me - more reasonable than making changes in a vacuum, in fact. But I don't think that they're going to let the community run wild and completely change the character of Go. I think they're looking for wins that matter to users, but wins that are possible within the framework of what Go is.
    - icholy 8y ago
      I hope you're right
  - atombender 8y ago
    HN has a good rule [1] about comments: "Please don't post shallow dismissals, especially of other people's work." The above comment is being downvoted because it just voices dissent, not a real, substantive opinion. I can guess what their intent is, but that's hardly a basis for good discussion. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- deleted 8y ago
  [deleted]
ilovecaching 8y ago
Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables, well that's just a different language, and we'll just end up on the hedonistic treadmill towards another Java. No thank you.
- pjmlp 8y ago
  Languages are products as well, either they grow to fulfil the needs of their customers or their fade away.
  - ilovecaching 8y ago
    What if the need is for a small language without generics?
    - pjmlp 8y ago
      If there was such a need, the languages without them would still have a major market, which isn't the case. Naturally those of us coding since the early days have experience with programming languages without generics support, yet a large majority eventually adopted generics. Even C has minimal generics support since C11.
    - bluejekyll 8y ago
      In what context would “need” a language to not have generics? I can understand not “wanting” generics to keep it simpler, but I can’t see that as a “need”. Personally, in any typed language, I want generics, not having them feels very limiting.
- bdamm 8y ago
  Isn't the premise of Go that a team sufficiently large enough will eventually act as a collective idiot in terms of code maintenance? I'm looking forward to some real research on the question of whether Go's design choices have had real world results in improving productivity with supersize code bases.
isuckatcoding 8y ago
Non-go user here. So what are the most desired fratures from Go 2 in the community? I remember something about generics not being supported.
- bradfitz 8y ago
  Generics and errors are the things that come up most frequently in surveys.
- nine_k 8y ago
  Helpful link from the text: https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2+sort%3Areactions-%2B1-desc https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+l... These are Go2 proposal PRs, sorted by upvotes.
komali2 8y ago
Hahah oh no, I literally started learning Go last night. Now what?
- zegl 8y ago
  No worries, "Go 2" is going to be delivered in small incremental changes.
- T-A 8y ago
  Finish learning it tonight. It's not that big.
- CydeWeys 8y ago
  This is going to take years to happen, so you're fine. This is just an announcement of what the process for coming up with Go 2 is going to look like.
infogulch 8y ago
I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.
- Teckla 8y ago
  Having to manually pass context through so many functions in code bases is definitely not ideal.
  - infogulch 8y ago
    It doubles the surface area of every library that deals with anything related to IO, and forces middle libraries that don't and shouldn't care about context to double their surface area just to support connecting their consumers to their upstream providers. "not ideal" is an understatement.
    - dolmen 8y ago
      My contextio package might be useful. Check example: https://godoc.org/github.com/dolmen-go/contextio#example-package--Copy https://godoc.org/github.com/dolmen-go/contextio#example-pac...
- atombender 8y ago
  This doesn't seem to be a popular opinion, but I agree. It's such a pervasive functionality in concurrent programs that it really should be a built-in aspect of a goroutine. The problem with context isn't necessarily the interface, it is that it is "viral". If you need context somewhere along a call chain, it infects more than just the place you need it — you almost always have to add it upwards (so the needed site gets the right context) and downwards (if you want to support cancellation/timeout, which is usually the point of introducing a context). Context's virality also applies to backwards compatibility. There have been discussions of adding context to io.Reader and io.Writer, for example, but there's no elegant way to retrofit them without creating new interfaces that support a context argument. This problem applies to any API; you may not expect your API to require a context today, but it might need one tomorrow, which would require a breaking API change. Given that it's impossible to predict, you might want to pre-emptively add context as an argument to all public APIs, just to be safe. Not good design. Cancellation/timeout is arguably so core to the language that it should be an implicit part of the runtime, just like goroutines are. It would be trivial for the runtime to associate a context with a goroutine, and have functions for getting the "current" context at any given time. (Erlang got this right, by allowing processes to be outright killed, but it's probably too late to redesign Go to allow that.) (I'm ignoring the key/value system that comes with the Context interface, because I think it's less core. It certainly seems less used than the other mechanisms. For example, Kubernetes, one of the largest Go codebases, doesn't use it.)
asien 8y ago
I 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.
- smudgymcscmudge 8y ago
  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.
  - freedomben 8y ago
    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).
    - jjtheblunt 8y ago
      That's not a shallow reason: the annoyance in aggregate motivated a language usability improvement with no regressions.
    - klodolph 8y ago
      That ended up being the biggest hurdle for me. I wanted a single repository with some Go source code, some Python, some C++, and I didn’t want to have to put the repo in a specific place or set environment variables for every project. Nowadays I just put my Go source code in <repo>/go/src/example.com/pkgname and that works well enough, but it's a bit clumsy and reminds me of bad experiences navigating Java source trees. I haven’t switched to modules yet but I will once I get 1.12 everywhere.
    - 8y ago
joppy 8y ago
I’m hoping that https://github.com/golang/go/issues/19623 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-level data structures like lists, hashtables, etc are content to just leave us with the bare minimum support of numbers, being basically whatever the hardware thinks a number is. The semantics of integers and fractions are perfect, and everybody already knows them. On the other hand, overflows in int32’s are weird, and if your idea of a fraction is a floating-point number, then you can never have something like (5/3)*6 evaluate to 10 exactly. To be clear, I think fixed-width integers and floating-point numbers have their place, I just see no reason why they should be the default.
- a_c_s 8y ago
  This was one thing COBOL got right: built in support for a DECIMAL data type.
  - prevedmedved 8y ago
    Don't be stupid. A "decimal" type is a floating-point number, just with a different base. It solves none of the underlying problems. (Which is why, incidentally, nothing made in this millennium supports it.)
    - christophilus 8y ago
      It’s been a while since I COBOLed, but if I recall, the COBOL decimal is similar to Currency types in languages like C#. (Maybe I’m misremembering.) If I’m right, though, it’s not a floating point number. It’s currency properly handled via integer math under the hood.
      - Symmetry 8y ago
        Decimal floating point is actually an established thing and part of the current IEEE 754 spec. I'm not too familiar with COBOL but pretty much any modern language will offer it through a library or compiler extension. Recent IBM Power processors even have hardware support. https://en.wikipedia.org/wiki/Decimal_floating_point https://en.wikipedia.org/wiki/Decimal_floating_point
smudgymcscmudge 8y ago
Am I reading this right that the list in the #Proposals header are the only proposals from the Go2 bucket that are being considered for 1.13? I was hoping "check" would make the cut.
- austeane 8y ago
  Yup. Specifically because they are backwards compatible and well known problems being used to test their proposal feedback system.
mempko 8y ago
I'm curious if making go an ISO standard was ever considered.
- sigjuice 8y ago
  What would be the benefits of an ISO standard? The list of programming languages with an ISO standard is pretty short https://en.wikipedia.org/wiki/Category:Programming_languages_with_an_ISO_standard https://en.wikipedia.org/wiki/Category:Programming_languages...
- remus 8y ago
  Given that go is already pretty well specified (and, perhaps more importantly, has 2 mature implementations) it's hard to see what advantages having it formally standardised would bring. https://golang.org/ref/spec https://golang.org/ref/spec
  - mempko 8y ago
    With Go 2, they are moving to a community run project. ISO is a process for that. I guess, why reinvent the wheel unless they think they can do substantially better.
curiousDog 8y ago
I 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?
- daxorid 8y ago
  fmt.Printf() debugging is always a time-honored tradition.
- org3432 8y ago
  If you use Goland 2018 it's pretty seamless, there are a few things missing like being able to get ptr addresses and view values in hex, and it's a little laggy compared to VS but not bad.
  - copperx 8y ago
    Is Goland's debugger written by Jetbrains?
    - org3432 8y ago
      Yes, it uses delve under the hood and acts much the same way as VS.
- pureadrenallen 8y ago
  I've had really good luck using delve with vs code. Easy setup and good experience overall
- mseepgood 8y ago
  Delve
  - deleted 8y ago
    [deleted]
- ar_lan 8y ago
  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.
dunpeal 8y ago
> We are constrained by the fact that we now have millions of Go programmers and a large body of Go code Are there really "millions" (plural) of Go programmers? Sounds like a bit of an overestimate, no?
- weberc2 8y ago
  Not sure, but I wouldn't be surprised. There seem to be a lot of Go developers in China and elsewhere who don't really participate in the English-speaking Go community.
  - dunpeal 8y ago
    I don't really see a reason why there'd be a large iceberg of Go developers in China. There's no reason why programmers in China would use Go in higher proportion than elsewhere in the world.
    - ghthor 8y ago
      The first class unicode support is one of the reasons that is big in China.
      - dunpeal 8y ago
        It's a nice feature, but several other languages have that, including languages that directly compete with Go.
        weberc2 8y ago
        Perhaps those languages also enjoy wider adoption in China than elsewhere in the world? Similarly, the software engineering industry has certainly advanced more rapidly in China than elsewhere in the world (as an artifact of China's rapid economic development), so their language adoption is likely skewed toward more recent languages (like Go).
        8y ago
openbasic 8y ago
Will we finally get a normal module implementation?
- icholy 8y ago
  What's wrong with packages?
gauravphoenix 8y ago
I really wish Go 2 can make dependency management easier.
- nerdwaller 8y ago
  Have you tried go modules since 1.11? It's significantly simpler now than it was before.
  - gauravphoenix 8y ago
    I haven't yet. I hope a good eco-system develops around them. My biggest gripe is that there are just too many approaches in Golang when it comes to the dependency management.
    - nerdwaller 8y ago
      Definitely true, the hands-off approach they took seemed strange to me - as others make that one of the core tenants of the community early on. Since I have been in the ecosystem it's been `go get`, `vendor` directory, the various community ones, and now modules.
- deleted 8y ago
  [deleted]
- atombender 8y ago
  Basically a solved problem now: https://news.ycombinator.com/item?id=18563267 https://news.ycombinator.com/item?id=18563267.
olafure 8y ago
I smell the second coming of the Python 3 fiasco.
- remus 8y ago
  I'd be surprised if something similar to python 2/3 happens. The go team have been very explicit in saying that all go 1 code must continue to compile, and transitioning to go 2 needs to be as seamless as possible (most likely using tooling to automatically migrate code across, a la go fix from the early days).
  - zhengyi13 8y ago
    Google had Guido working there for a very long time; there's probably a lot of institutional memory built up around the 2->3 transition, and likely a lot of lessons learned, and a strong desire not to repeat the experience.
Waterluvian 8y ago
As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go. There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure out. I haven't felt so viscerally aggressive about software like that whole experience made me feel in a long time. I hope Go2 makes something concrete from the start and sticks with it, for better or worse.
- tpfour 8y ago
  My only experience with Go was around 2012-2013. It was fun, but I did not bother sticking with it. The forced directory structure was a little bit annoying and I found myself writing interfaces for everything. I'm sure people will say it's my fault as a programmer, but it turned me off from the language.
  - zik 8y ago
    The new module system removes $GOPATH and the forced directory structure.
- cdoxsey 8y ago
  Go modules are available in go 1.11 today. If you're envisioning another new pkg management solution besides that, I don't think that's going to happen.
- atombender 8y ago
  Having used the new Go module system (introduced in Go 1.11 as an option, to be the default choice in 1.12) since August, it's my opinion that this is now a solved problem. The biggest source of pain moving forward is going to be the projects that haven't transitioned, including the various command-line tools that work on parsing, generating and manipulating Go code (e.g. linters, code generators). Most of the important ones are already there, and I've transitioned several myself. As an added bonus, word is that the Go team wants an official package repository system (similar to Cargo, RubyGems etc.). I wouldn't be surprised if this happens rather quickly.
wpietri 8y ago
I really like the humility in this part of the statement: > After almost 10 years of exposure, we have learned a lot about the language and libraries that we didn’t know in the beginning, and that was only possible through feedback from the Go community. It's so tempting to hold one's project back until it seems perfect. And then, even worse, to defend it as perfect in the face of real-world feedback. I really appreciate it when smart people do their best, but in full recognition that a lot of things will be learned once real use happens.
JulienSchmidt 8y ago
This blog post doesn't answer likely the biggest of all questions: Will there be breaking changes? If so, how will those be handled? "As a rule of thumb, we should aim to help at least ten times as many developers as we hurt with a given change" sounds like there might be breaking changes, but on the other hand Robert still talks about including new features in the Go 1 compatibility guarantee. I'd love if the compiler would stay backwards compatible and packages / modules could be pinned to a certain version, either during import or in the package / module itself. Then one could write Go 2 code but still use packages which are not yet updated to Go 2. Personally I think that making breaking changes is a good idea, as it allows to clean up previous mistakes. However, Go should at all cost avoid incompatibilities like between Python 2 and 3.
- austeane 8y ago
  It is very clear that there are breaking changes for Go 2. However, they are testing out their new proposal-review system using non-breaking changes included in Go 1.
nickcw 8y ago
I've been reading this proposal > #19113 Permit signed integers as shift counts: An estimated 38% of all non-constant shifts require an (artificial) uint conversion (see the issue for a more detailed break-down). This proposal will clean up a lot of code, get shift expressions better in sync with index expressions and the built-in functions cap and len. It will mostly have a positive impact on code. The implementation is well understood. The proposal as far as I can make out says allow signed integers for shifts but panic if they are negative. This seems like a step backwards to me pushing checking which the compiler made you do to runtime. Personally I'd expect a negative shift to shift the other way, but that doesn't seem to be a popular option with the team.
- the_clarence 8y ago
  why would someone shift numbers in the first place? I only shift uint8
- infogulch 8y ago
  > This seems like a step backwards to me pushing checking which the compiler made you do to runtime. No that means this operation is currently unchecked by the compiler: https://play.golang.org/p/nJmaEOkObk1 https://play.golang.org/p/nJmaEOkObk1
pc2g4d 8y ago
So generics are in?
revskill 8y ago
GOPATH is the ugliness of Go. Can't imagine that overhead for a modern PL.
- shawabawa3 8y ago
  that will be gone as of go 1.12 - already opt outable in 1.11
- emersion 8y ago
  Go modules will replace GOPATH, they're available since Go 1.11.
ausjke 8y ago
I'm learning Go, just a naive question, why does Go put the variable type at the end of declaration, is this an absolute need? no other widely usage language does that, and it just feels odd to me.
- mmastrac 8y ago
  Pascal did it: procedure SetColor (const NewColor: TColor; const NewFPColor: TFPColor); virtual; Rust does it too: fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32 Go is similar, but less symbols: f func(func(int,int) int, int) func(int, int) int
  - matt_kantor 8y ago
    Also Scala, Haskell, TypeScript, Swift, Kotlin, Visual Basic, Python (PEP 526), and many others.
- amenghra 8y ago
  A lot of languages have had type declarations at the end. The first popular which comes to mind is Pascal (see http://wiki.freepascal.org/Fibonacci_number http://wiki.freepascal.org/Fibonacci_number). You get used to it. Having to deal with this kind of differences between different programming languages is a lesser concern in the grand scheme of things.
- ausjke 8y ago
  My experience is limited to c, c++, java, all of them did 'type variable' instead of 'variable type', now I see there are many others that are doing things very differently. Thanks. Love Go's one binary does http-server-login-everything-etc, can't be simpler for deployments.
- AsyncAwait 8y ago
  > no other widely usage language does that Swift, Kotlin, TypeScript, Rust Like everything different, it can feel odd at first, but I actually prefer it now. Think of it as "Joe is a Person" is more natural than "Person named Joe".
- 8y ago
coldtea 8y ago
>* 1. Allowing generalized unicode identifiers.* I'm all for full support for unicode string manipulation. But when ever are "unicode identifiers" a good idea? All kinds of BS decisions (normalization etc) for no good reason at all. Would you share code with identifiers written in RTL language? Chinese? Hieroglyphics? And I'm saying this as someone who's not a native English speaker. If it was an APL dialect I'd see some reasoning, but what good does it do for Go?
johnvega 8y ago
"... keeping the language small and clean" + Go Modules is the sweet spot for me.
- klodolph 8y ago
  That’s 1.12 though, isn’t it? I’m not disagreeing that it’s the sweet spot, I just think we already have it, or close enough.
glangdale 8y ago
I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly reminiscent of Mac fanboys claiming PowerPC chips were the Very Best right up until this was obviously not true. C++ generics are a PITA in many ways, but you can be insanely productive in the STL without having to hand-roll everything and with good type safety. Despite the pain, I've been amazed at how easily you can build up some really complex data structures as pretty much one-liners ("Oh, I need a vector of maps from a pair of Foo to a set of Bar") that would either take a preposterous amount of code (or be a type-unsafe disaster waiting to happen) without generics. Hopefully the final Go 2 generics proposal will capture some of this goodness without some of the horrifying C++ issues (error messages, bloat, sheer brain-numbing complexity).
- burtonator 8y ago
  I'm hoping things like generics can just be accepted to be a good idea moving forward and that we can all agree that languages without them are handicapped. I still fell things are up in the air about exceptions but maybe we can just agree on generics which would make me feel better. Using go without generics just felt insane to me...
  - cultus 8y ago
    Yeah, Go has some really fantastic aspects around tooling and a good concurrency story, but it's otherwise such a huge step backwards. I can't fathom the reason for not having generics. It's such a simple, completely common-sense abstraction. Things like typeclasses or multimethods offer vastly more abstraction power. These are (a bit) more difficult to understand, but you certainly don't have to be a genius (take it from me). I can kind of get why a language targeted towards "average" programmers might want to omit these. But here's the thing: The less abstraction power a language has, the more complexity must be handled by the developer. This leads to things like Java Spring, which you do have to be a genius to understand.
sova 8y ago
Throw Semver OuT THE WINDOW!
RickJWagner 8y ago
What's that famous tag line? Oh, yes: "Use of Go 2 Considered Harmful".
rqs 8y ago
One question: As far as my knowledge told me, anything (or most?) interface{} in Go will be put to heap instead of stack. Will generics change that? I really want to utilize those 2~4K stack spaces for the routines.
throwaway487549 8y ago
I would love to have type-clases a-la Haskell (implicits with parametric polymorphism, which is dead-simple and well understood) and universal pattern matching everywhere, but this is, of course, just a dream. I would love to have ML/Scala-style syntax for curried functions and function definition via pattern-matching with guards, which is also, it seems, out of questions. Actuall, the more of ML a strict language gets in - the better. What is really funny is that Bell Labs did a lot of ML research, especially on stdlib, but Go team is ignoring everything which is not of the C flavour. Pity. Again, ML is absolutely wonderful, and type-classes are the biggest single major innovation since Smalltalk. It is better to lean towards ML instead of heading towards Javascript.
ThorinJacobs 8y ago
I know the comments aren't meant for silly jokes but I'm very disappointed that there's no "Go 2 Considered Harmful" jokes here
- nickm12 8y ago
  This is a awesome joke. Thanks for the laugh.
- idle_zealot 8y ago
  There's this[0] one from 10 hours ago, but it's pretty buried by actual discussion at this point. [0]: https://news.ycombinator.com/item?id=18561684 https://news.ycombinator.com/item?id=18561684
gBecks 8y ago
I've yet to see any mention of immutable data types, which I find I would use more than even generics.
sidcool 8y ago
I am torn apart between investing the next one year between Go and Rust. I want to do some cool systems level programming. Both seem to be very good at it. Go has additional advantages of being older (and may be wiser). What does the hivemind think?
- zbentley 8y ago
  > some cool systems level programming. What projects did you have in mind? I think the answer to your question depends on what you mean by "systems level programming" and what you plan on doing/trying.
akuji1993 8y ago
With that naming practice, it will probably become as hard to google problems as with AngularJS and Angular 2.
tromp 8y ago
Wasn't Go2 considered harmful :-?
dingle_thunk 8y ago
Awaiting obligatory "go 2 considered harmful" YNews article.
leshow 8y ago
It seems Go wants to have a more open development process, but it looks like all the decisions are ultimately under the purview of the "Go team". Does the Go team include any community members? Or is this "open process" still essentially up to whims of a small group working at Google?
systemBuilder 8y ago
When I was young I thought Dijkstra published a paper called, "go2's considered harmful!'. I think the next version of Go should be Go3.

816 points by mdelias 8y ago

Go 2 Considered Harmful: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...

sdegutis 8y ago
You got me. Genuinely thought it was gonna be a critique.
- dao- 8y ago
  So what is it? I'm on my phone and don't feel like downloadig a random PDF just for curiosity...
  - williamdclt 8y ago
    Dijkstra's critique of the `goto` statement
  - barrkel 8y ago
    It's a pun. "Go 2" -> "Go To". Dijkstra coined "considered harmful" with the paper (letter) on "Go To statement considered harmful".
    - Stratoscope 8y ago
      It was actually Niklaus Wirth (designer of Pascal and other languages) who coined "considered harmful": > In 1968 the Communications of the ACM published a text of mine under the title "The goto statement considered harmful, which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a templace: we would see all sorts of articles under the title 'X considered harmful' for almost any X, including one titled "Dijkstra considered harmful." > But what had happened? I had submitted a paper under the title "A case against the goto statement, which in order to speed up its publication, the editor had changed into a 'Letter to the Editor', and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth". https://www.theregister.co.uk/2002/08/08/edsger_dijkstra_rip/ https://www.theregister.co.uk/2002/08/08/edsger_dijkstra_rip... https://en.wikipedia.org/wiki/Considered_harmful https://en.wikipedia.org/wiki/Considered_harmful
    - vram22 8y ago
      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." :)
      - Stratoscope 8y ago
        And this classic by Scott Meyers of Effective C++ fame: "Considered Harmful" Essays Considered Harmful https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html
        vram22 8y ago
        Thanks, will check that out. I really liked the Effective C++ book by Scott. There's a good video talk by him titled something like "The Last Thing D Needs".
  - naibafo 8y ago
    > Edgar Dijkstra: Go To Statement Considered Harmful
    - Someone 8y ago
      Edsger, nog Edgar (http://www.cs.utexas.edu/users/EWD/ http://www.cs.utexas.edu/users/EWD/) Dijkstra would lambast you for that error :-)
      - naibafo 8y ago
        He probably would :) But I just quoted the linked PDF a few comments above in the chain.
agumonkey 8y ago
Well played sir
Zenst 8y ago
When I started work in the early 80's as a COBOL analyst programmer, I encountered ideology vs reality of GOTO. When I learned COBOL, I was taught Jackson Structured Programming. No use of GOTO at all, even exception handling. Fast forward in my first week into work and having done a nice JSP program for the task at hand a senior came over with my code and had a chat. Then took me to the system developers who did all the dirty low level assembler code (for sorts and other area's in which speedup was huge over COBOL). Was shown how my approach was far more wasteful of CPU resources and why others would not be able to maintain such code as all the rest used GOTO's. I will admit, it was nicely explained and this is in a time in which mainframes offered the only computer solutions for business of this scale and not cheap. I will say GOTO's work well for exception handerling, but still doable without. But for speed, though less of a factor today, it still translates as faster code at the low level of CPU runs. But then, things move on and you will always have that wave of what students are taught being cutting edge compared to what is actualy in use in work. A friction many would have encountered in one form or another, even today. Be it style, design or language/tools choice. What is the best today, may well be outdated tomorrow, but you have to maintain that legacy investment and it is often too costly/risky to rewrite that legacy for something that itself could be legacy the next day. So as for harmful, well they can spagetti up code if used badly, yet that comes to many approaches and if they are that bad, why do CPU's still have JUMP instructions you could counter-argue. Oh and well played on the humour.
- fwip 8y ago
  Are there normal coding patterns that are much faster with explicit gotos? Modern compilers seem to do a pretty good job of converting normal (goto-less) code into efficient binaries. E.g, the simple switch statement has several possible machine-code implementations that compilers will switch (heh) between, depending on the characteristics of the cases.
  - beetwenty 8y ago
    In bytecode interpreter VMs, one often encounters the "computed goto" [1] pattern in use to dispatch opcodes. This is one that tends to be a little faster than a switch statement, enough to matter in the dispatch inner loop. Of course, if you are going to JIT compile the bytecode, that'll usually be a lot faster. But at that point you're changing one form of low-level wizardry for another. [1] https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...
vram22 8y ago
I wonder how many people got the joke without reading the link. Good one, boss.
- brlewis 8y ago
  I did because I'm a native speaker of English, am familiar with "goto considered harmful", and I noticed Dijkstra in the link.
  - vram22 8y ago
    >I noticed Dijkstra in the link. That's how I figured out the joke too - that plus the start of the comment :)
slap_shot 8y ago
I appreciate a good joke, but is this really necessary on a thread like this? Here's the equivalent Reddit thread; better suited for this sort of comment: https://www.reddit.com/r/golang/comments/a1j3h6/go_2_here_we_come/ https://www.reddit.com/r/golang/comments/a1j3h6/go_2_here_we...
- tyrust 8y ago
  Smaller subreddits (like the one you linked) are typically against shitposting as well.
- deleted 8y ago
  [deleted]
colonelpopcorn 8y ago
I came here just to say that. Glad to see I wasn't the only one.
hu3 8y ago
this kind of comment says a lot about current state of HN this is the new Reddit
- burke 8y ago
  God forbid that one of 208 comments is a (rather funny) joke. I don't get why some people here are so against humour. I appreciate the high standards for jokes and expectation of high signal:noise, but this was clever and topical.
codegeek 8y ago
I always appreciate a good joke but unfortunately this has become the top comment as of now and is not adding to the real discussion around Go 2. This is a typical case of when I use my downvote power. Great joke but we should keep HN noise free.
- esrauch 8y ago
  Is it really so harmful to have it at the top of the comment thread? I think HN can be focused mainly on serious discourse without being completely humorless.
  - codegeek 8y ago
    I think about it all the time. But imagine leaving the page and coming back a few hours later. Now you have to sort through tons of unnecessary comments (even if funny and humorous) while you look for the quality stuff. Quality requires sacrifice and I am willing to sacrifice the humor part for quality unless you throw in a bit of humor with quality content.
    - Stratoscope 8y ago
      A great way to solve this is to use the [-] button to collapse any comment threads that you're not interested in following, like this one. HN remembers which threads you've collapsed, so you won't see them when you come back to the page.

twoodfin 8y ago

Rob Pike had a good talk on the Go 2 process and a few of the proposals that went up on YouTube a few days ago: https://youtu.be/RIvL2ONhFBI https://youtu.be/RIvL2ONhFBI

glenrivard 8y ago

Big fan of both Go and also Rust. It is time we move beyond C and C++

freedomben 8y ago
I apologize for asking a question that will likely lead to a flame war regardless of your answer, but which is better? I've used Go for a while for certain apps, but as a primarily functional programmer I find my way of thinking often clashes with the language (and I also don't like the verbosity). So, do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than Go?
- tazjin 8y ago
  As a Haskell & Erlang person who currently uses Rust as my primary language at work: > do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than Go? Yes, yes. Obviously the Rust ecosystem has fewer mature libraries, but its type system and error handling make Go look like a toy. Go can be okay for small one-off tools, but its safety guarantees are not far ahead of scripting languages and I think it should be considered as such.
- tptacek 8y ago
  This is like asking for a language war, which is the last thing we want on a language thread. You shouldn't have any problem finding already-existing Go vs. Rust discussion either in the search bar here or on Google.
- foldr 8y ago
  Rust has much better support for a functional style. On the other hand, not having a GC in Rust means that dealing with closures can in some cases get quite complicated, whereas closures in Go work exactly as you'd expect. (Although to be fair, if you aren't doing any mutation, closures in Rust are pretty easy to deal with.)
- jpgvm 8y ago
  Both are fundamentally different, neither is "better". They are both good at slightly different things. If your desire is to accept bytes over the network and spit back bytes over network Go is going to be a pretty solid choice because that was very much the focus of it's design. However if you want to build an application for a hard realtime environment and you either lack the space for runtime or can't handle GC pauses then maybe Rust is a better choice. From a language perspective Go is a simple language and Rust is a complex language. The two have different tradeoffs here. Go is easy to learn, has limited pitfalls but also lacks in the power department if you need metaprogramming and abstractions to model your problem. Rust however accels in that role due to it's powerful type system and hygienic macros. The tradeoff is very apparent once you try use the two languages however, Rust is -far- more difficult to both climb the initial learning curve and has a much higher ceiling. Fundamentally you will probably find Go is better at replacing dynamic languages though there are many cases where C/C++ was used where it's bare metal nature isn't needed and Go is a very suitable replacement. Go however has some difficulty in replacing certain usages of C/++. Namely it can't easily be used to create a shared library because of it's runtime and I/O system. That said if you wanted to be able to replace any and all C/C++ code Rust would be a better choice as it can do anything C/C++ can with no downsides. i.e embedded systems, shared libraries, bare metal access without worrying about the green threaded execution model. There are many other things to consider too but these are some of the important ones from someone who got into coding doing C and embedded, has since learnt both Go (and used professionally) and Rust (and used for side projects). Subjectively I think Go is a better choice when it can do the job as it's easier and less brain intensive to just do the thing. Rust however is more "fun" to program in as it's a less mechanical endeavour and also can solve some problems you can't with Go.

rjplatte 8y ago

I'll be very sad if this goes the way of Perl 6

bradfitz 8y ago
It won't. It's an explicit requirement that it will not. Or even a Python 3. I had a slide saying as such in an earlier presentation: https://docs.google.com/presentation/d/1DmyTABhGLvN0m2uHktvkP_uXop6-Xy5HPNovjDKJ83g/edit#slide=id.g3140eee711_0_877 https://docs.google.com/presentation/d/1DmyTABhGLvN0m2uHktvk... (slide 140) Ian had a good talk & doc about this too recently: https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md https://github.com/golang/proposal/blob/master/design/28221-... https://www.youtube.com/watch?v=LqKOY_pH8u0 https://www.youtube.com/watch?v=LqKOY_pH8u0
- dunpeal 8y ago
  How can you have an "explicit requirement" not to end up like Perl 6? Nobody planned to "end up like Perl 6", it's just something that happens when your new, backwards-incompatible version of the language doesn't catch on. Also, sounds like Go 2 is going to make backwards-incompatible language changes. How is that different from Python 3, or even Perl 6?
  - bradfitz 8y ago
    Perl 6 decided from the beginning to break away from Perl 5 and not care about backwards compat. That was their choice. We don't make the same choice.
    - dunpeal 8y ago
      But Go 2 is also introducing backwards incompatible changes, no?
      - bradfitz 8y ago
        See the doc I linked above: https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md https://github.com/golang/proposal/blob/master/design/28221-... Probably not. We can add things and we can opt-in remove things (e.g. user says they want v1.14 of language gets them new language features and removes some language features), but we can't change the semantics of existing programs. That is, if a program compiles with two different language versions, that program should mean the same in both versions.

jonathanstrange 8y ago

I hope they keep the changes reasonable and do not introduce any breaking changes. I like the language as it is now and I'm very productive in it.

jsmith45 8y ago
Well for the first round they are looking at: 1. Allowing generalized unicode identifiers. That is hardly likely to break anything except possibly some crazy edge cases that dont happen in real code. 2. Binary integer literals. (unlikely to break things) 3. allowing seperating groups of digits in a number with _ like 1_000_000 (unlikely to break anything) 4. Permit signed integers as shift counts (no need to cast ant int to a uint to use it in a shift expression. This won't break any existing code). So at least this first round is quite unlikely to break anything in real use.
- bryanlarsen 8y ago
  For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.
  - stcredzero 8y ago
    It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?
    - copperx 8y ago
      That's a good question because they ostensibly do it to get more users aboard, but in most cases, the result is the opposite (e.g., the Python 2/3 disaster).
      - 8y ago

icholy 8y ago

> Go 2 will be much more community-driven. Please no ...

bsaul 8y ago
There must be some very angry people downvoting on this comment section today. Go is very opinionated and it's quite obvious that its original design being so radical (no class, no inheritance, no generics, no macro) was only possible because it was designed by a few very experimented people with a very specific goal in mind. I'm also worried about how being "community driven" will change the philosophy of the language.
- AnimalMuppet 8y ago
  I think "community driven" means less than you fear. I think it means that community feedback is used to push the language in directions that scratch some of the major community itches. That seems perfectly reasonable to me - more reasonable than making changes in a vacuum, in fact. But I don't think that they're going to let the community run wild and completely change the character of Go. I think they're looking for wins that matter to users, but wins that are possible within the framework of what Go is.
  - icholy 8y ago
    I hope you're right
- atombender 8y ago
  HN has a good rule [1] about comments: "Please don't post shallow dismissals, especially of other people's work." The above comment is being downvoted because it just voices dissent, not a real, substantive opinion. I can guess what their intent is, but that's hardly a basis for good discussion. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
deleted 8y ago
[deleted]

ilovecaching 8y ago

Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables, well that's just a different language, and we'll just end up on the hedonistic treadmill towards another Java. No thank you.

pjmlp 8y ago
Languages are products as well, either they grow to fulfil the needs of their customers or their fade away.
- ilovecaching 8y ago
  What if the need is for a small language without generics?
  - pjmlp 8y ago
    If there was such a need, the languages without them would still have a major market, which isn't the case. Naturally those of us coding since the early days have experience with programming languages without generics support, yet a large majority eventually adopted generics. Even C has minimal generics support since C11.
  - bluejekyll 8y ago
    In what context would “need” a language to not have generics? I can understand not “wanting” generics to keep it simpler, but I can’t see that as a “need”. Personally, in any typed language, I want generics, not having them feels very limiting.
bdamm 8y ago
Isn't the premise of Go that a team sufficiently large enough will eventually act as a collective idiot in terms of code maintenance? I'm looking forward to some real research on the question of whether Go's design choices have had real world results in improving productivity with supersize code bases.

isuckatcoding 8y ago

Non-go user here. So what are the most desired fratures from Go 2 in the community? I remember something about generics not being supported.

bradfitz 8y ago
Generics and errors are the things that come up most frequently in surveys.
nine_k 8y ago
Helpful link from the text: https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2+sort%3Areactions-%2B1-desc https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+l... These are Go2 proposal PRs, sorted by upvotes.

komali2 8y ago

Hahah oh no, I literally started learning Go last night. Now what?

zegl 8y ago
No worries, "Go 2" is going to be delivered in small incremental changes.
T-A 8y ago
Finish learning it tonight. It's not that big.
CydeWeys 8y ago
This is going to take years to happen, so you're fine. This is just an announcement of what the process for coming up with Go 2 is going to look like.

infogulch 8y ago

I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.

Teckla 8y ago
Having to manually pass context through so many functions in code bases is definitely not ideal.
- infogulch 8y ago
  It doubles the surface area of every library that deals with anything related to IO, and forces middle libraries that don't and shouldn't care about context to double their surface area just to support connecting their consumers to their upstream providers. "not ideal" is an understatement.
  - dolmen 8y ago
    My contextio package might be useful. Check example: https://godoc.org/github.com/dolmen-go/contextio#example-package--Copy https://godoc.org/github.com/dolmen-go/contextio#example-pac...
atombender 8y ago
This doesn't seem to be a popular opinion, but I agree. It's such a pervasive functionality in concurrent programs that it really should be a built-in aspect of a goroutine. The problem with context isn't necessarily the interface, it is that it is "viral". If you need context somewhere along a call chain, it infects more than just the place you need it — you almost always have to add it upwards (so the needed site gets the right context) and downwards (if you want to support cancellation/timeout, which is usually the point of introducing a context). Context's virality also applies to backwards compatibility. There have been discussions of adding context to io.Reader and io.Writer, for example, but there's no elegant way to retrofit them without creating new interfaces that support a context argument. This problem applies to any API; you may not expect your API to require a context today, but it might need one tomorrow, which would require a breaking API change. Given that it's impossible to predict, you might want to pre-emptively add context as an argument to all public APIs, just to be safe. Not good design. Cancellation/timeout is arguably so core to the language that it should be an implicit part of the runtime, just like goroutines are. It would be trivial for the runtime to associate a context with a goroutine, and have functions for getting the "current" context at any given time. (Erlang got this right, by allowing processes to be outright killed, but it's probably too late to redesign Go to allow that.) (I'm ignoring the key/value system that comes with the Context interface, because I think it's less core. It certainly seems less used than the other mechanisms. For example, Kubernetes, one of the largest Go codebases, doesn't use it.)

asien 8y ago

I 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.

smudgymcscmudge 8y ago
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.
- freedomben 8y ago
  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).
  - jjtheblunt 8y ago
    That's not a shallow reason: the annoyance in aggregate motivated a language usability improvement with no regressions.
  - klodolph 8y ago
    That ended up being the biggest hurdle for me. I wanted a single repository with some Go source code, some Python, some C++, and I didn’t want to have to put the repo in a specific place or set environment variables for every project. Nowadays I just put my Go source code in <repo>/go/src/example.com/pkgname and that works well enough, but it's a bit clumsy and reminds me of bad experiences navigating Java source trees. I haven’t switched to modules yet but I will once I get 1.12 everywhere.
  - 8y ago

joppy 8y ago

I’m hoping that https://github.com/golang/go/issues/19623 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-level data structures like lists, hashtables, etc are content to just leave us with the bare minimum support of numbers, being basically whatever the hardware thinks a number is. The semantics of integers and fractions are perfect, and everybody already knows them. On the other hand, overflows in int32’s are weird, and if your idea of a fraction is a floating-point number, then you can never have something like (5/3)*6 evaluate to 10 exactly. To be clear, I think fixed-width integers and floating-point numbers have their place, I just see no reason why they should be the default.

a_c_s 8y ago
This was one thing COBOL got right: built in support for a DECIMAL data type.
- prevedmedved 8y ago
  Don't be stupid. A "decimal" type is a floating-point number, just with a different base. It solves none of the underlying problems. (Which is why, incidentally, nothing made in this millennium supports it.)
  - christophilus 8y ago
    It’s been a while since I COBOLed, but if I recall, the COBOL decimal is similar to Currency types in languages like C#. (Maybe I’m misremembering.) If I’m right, though, it’s not a floating point number. It’s currency properly handled via integer math under the hood.
    - Symmetry 8y ago
      Decimal floating point is actually an established thing and part of the current IEEE 754 spec. I'm not too familiar with COBOL but pretty much any modern language will offer it through a library or compiler extension. Recent IBM Power processors even have hardware support. https://en.wikipedia.org/wiki/Decimal_floating_point https://en.wikipedia.org/wiki/Decimal_floating_point

smudgymcscmudge 8y ago

Am I reading this right that the list in the #Proposals header are the only proposals from the Go2 bucket that are being considered for 1.13? I was hoping "check" would make the cut.

austeane 8y ago
Yup. Specifically because they are backwards compatible and well known problems being used to test their proposal feedback system.

mempko 8y ago

I'm curious if making go an ISO standard was ever considered.

sigjuice 8y ago
What would be the benefits of an ISO standard? The list of programming languages with an ISO standard is pretty short https://en.wikipedia.org/wiki/Category:Programming_languages_with_an_ISO_standard https://en.wikipedia.org/wiki/Category:Programming_languages...
remus 8y ago
Given that go is already pretty well specified (and, perhaps more importantly, has 2 mature implementations) it's hard to see what advantages having it formally standardised would bring. https://golang.org/ref/spec https://golang.org/ref/spec
- mempko 8y ago
  With Go 2, they are moving to a community run project. ISO is a process for that. I guess, why reinvent the wheel unless they think they can do substantially better.

curiousDog 8y ago

I 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?

daxorid 8y ago
fmt.Printf() debugging is always a time-honored tradition.
org3432 8y ago
If you use Goland 2018 it's pretty seamless, there are a few things missing like being able to get ptr addresses and view values in hex, and it's a little laggy compared to VS but not bad.
- copperx 8y ago
  Is Goland's debugger written by Jetbrains?
  - org3432 8y ago
    Yes, it uses delve under the hood and acts much the same way as VS.
pureadrenallen 8y ago
I've had really good luck using delve with vs code. Easy setup and good experience overall
mseepgood 8y ago
Delve
- deleted 8y ago
  [deleted]
ar_lan 8y ago
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.

dunpeal 8y ago

> We are constrained by the fact that we now have millions of Go programmers and a large body of Go code Are there really "millions" (plural) of Go programmers? Sounds like a bit of an overestimate, no?

weberc2 8y ago
Not sure, but I wouldn't be surprised. There seem to be a lot of Go developers in China and elsewhere who don't really participate in the English-speaking Go community.
- dunpeal 8y ago
  I don't really see a reason why there'd be a large iceberg of Go developers in China. There's no reason why programmers in China would use Go in higher proportion than elsewhere in the world.
  - ghthor 8y ago
    The first class unicode support is one of the reasons that is big in China.
    - dunpeal 8y ago
      It's a nice feature, but several other languages have that, including languages that directly compete with Go.
      - weberc2 8y ago
        Perhaps those languages also enjoy wider adoption in China than elsewhere in the world? Similarly, the software engineering industry has certainly advanced more rapidly in China than elsewhere in the world (as an artifact of China's rapid economic development), so their language adoption is likely skewed toward more recent languages (like Go).
        8y ago

openbasic 8y ago

Will we finally get a normal module implementation?

icholy 8y ago
What's wrong with packages?

gauravphoenix 8y ago

I really wish Go 2 can make dependency management easier.

nerdwaller 8y ago
Have you tried go modules since 1.11? It's significantly simpler now than it was before.
- gauravphoenix 8y ago
  I haven't yet. I hope a good eco-system develops around them. My biggest gripe is that there are just too many approaches in Golang when it comes to the dependency management.
  - nerdwaller 8y ago
    Definitely true, the hands-off approach they took seemed strange to me - as others make that one of the core tenants of the community early on. Since I have been in the ecosystem it's been `go get`, `vendor` directory, the various community ones, and now modules.
deleted 8y ago
[deleted]
atombender 8y ago
Basically a solved problem now: https://news.ycombinator.com/item?id=18563267 https://news.ycombinator.com/item?id=18563267.

olafure 8y ago

I smell the second coming of the Python 3 fiasco.

remus 8y ago
I'd be surprised if something similar to python 2/3 happens. The go team have been very explicit in saying that all go 1 code must continue to compile, and transitioning to go 2 needs to be as seamless as possible (most likely using tooling to automatically migrate code across, a la go fix from the early days).
- zhengyi13 8y ago
  Google had Guido working there for a very long time; there's probably a lot of institutional memory built up around the 2->3 transition, and likely a lot of lessons learned, and a strong desire not to repeat the experience.

Waterluvian 8y ago

As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go. There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure out. I haven't felt so viscerally aggressive about software like that whole experience made me feel in a long time. I hope Go2 makes something concrete from the start and sticks with it, for better or worse.

tpfour 8y ago
My only experience with Go was around 2012-2013. It was fun, but I did not bother sticking with it. The forced directory structure was a little bit annoying and I found myself writing interfaces for everything. I'm sure people will say it's my fault as a programmer, but it turned me off from the language.
- zik 8y ago
  The new module system removes $GOPATH and the forced directory structure.
cdoxsey 8y ago
Go modules are available in go 1.11 today. If you're envisioning another new pkg management solution besides that, I don't think that's going to happen.
atombender 8y ago
Having used the new Go module system (introduced in Go 1.11 as an option, to be the default choice in 1.12) since August, it's my opinion that this is now a solved problem. The biggest source of pain moving forward is going to be the projects that haven't transitioned, including the various command-line tools that work on parsing, generating and manipulating Go code (e.g. linters, code generators). Most of the important ones are already there, and I've transitioned several myself. As an added bonus, word is that the Go team wants an official package repository system (similar to Cargo, RubyGems etc.). I wouldn't be surprised if this happens rather quickly.

wpietri 8y ago

I really like the humility in this part of the statement: > After almost 10 years of exposure, we have learned a lot about the language and libraries that we didn’t know in the beginning, and that was only possible through feedback from the Go community. It's so tempting to hold one's project back until it seems perfect. And then, even worse, to defend it as perfect in the face of real-world feedback. I really appreciate it when smart people do their best, but in full recognition that a lot of things will be learned once real use happens.

JulienSchmidt 8y ago

This blog post doesn't answer likely the biggest of all questions: Will there be breaking changes? If so, how will those be handled? "As a rule of thumb, we should aim to help at least ten times as many developers as we hurt with a given change" sounds like there might be breaking changes, but on the other hand Robert still talks about including new features in the Go 1 compatibility guarantee. I'd love if the compiler would stay backwards compatible and packages / modules could be pinned to a certain version, either during import or in the package / module itself. Then one could write Go 2 code but still use packages which are not yet updated to Go 2. Personally I think that making breaking changes is a good idea, as it allows to clean up previous mistakes. However, Go should at all cost avoid incompatibilities like between Python 2 and 3.

austeane 8y ago
It is very clear that there are breaking changes for Go 2. However, they are testing out their new proposal-review system using non-breaking changes included in Go 1.

nickcw 8y ago

I've been reading this proposal > #19113 Permit signed integers as shift counts: An estimated 38% of all non-constant shifts require an (artificial) uint conversion (see the issue for a more detailed break-down). This proposal will clean up a lot of code, get shift expressions better in sync with index expressions and the built-in functions cap and len. It will mostly have a positive impact on code. The implementation is well understood. The proposal as far as I can make out says allow signed integers for shifts but panic if they are negative. This seems like a step backwards to me pushing checking which the compiler made you do to runtime. Personally I'd expect a negative shift to shift the other way, but that doesn't seem to be a popular option with the team.

the_clarence 8y ago
why would someone shift numbers in the first place? I only shift uint8
infogulch 8y ago
> This seems like a step backwards to me pushing checking which the compiler made you do to runtime. No that means this operation is currently unchecked by the compiler: https://play.golang.org/p/nJmaEOkObk1 https://play.golang.org/p/nJmaEOkObk1

pc2g4d 8y ago

So generics are in?

revskill 8y ago

GOPATH is the ugliness of Go. Can't imagine that overhead for a modern PL.

shawabawa3 8y ago
that will be gone as of go 1.12 - already opt outable in 1.11
emersion 8y ago
Go modules will replace GOPATH, they're available since Go 1.11.

ausjke 8y ago

I'm learning Go, just a naive question, why does Go put the variable type at the end of declaration, is this an absolute need? no other widely usage language does that, and it just feels odd to me.

mmastrac 8y ago
Pascal did it: procedure SetColor (const NewColor: TColor; const NewFPColor: TFPColor); virtual; Rust does it too: fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32 Go is similar, but less symbols: f func(func(int,int) int, int) func(int, int) int
- matt_kantor 8y ago
  Also Scala, Haskell, TypeScript, Swift, Kotlin, Visual Basic, Python (PEP 526), and many others.
amenghra 8y ago
A lot of languages have had type declarations at the end. The first popular which comes to mind is Pascal (see http://wiki.freepascal.org/Fibonacci_number http://wiki.freepascal.org/Fibonacci_number). You get used to it. Having to deal with this kind of differences between different programming languages is a lesser concern in the grand scheme of things.
ausjke 8y ago
My experience is limited to c, c++, java, all of them did 'type variable' instead of 'variable type', now I see there are many others that are doing things very differently. Thanks. Love Go's one binary does http-server-login-everything-etc, can't be simpler for deployments.
AsyncAwait 8y ago
> no other widely usage language does that Swift, Kotlin, TypeScript, Rust Like everything different, it can feel odd at first, but I actually prefer it now. Think of it as "Joe is a Person" is more natural than "Person named Joe".
8y ago

coldtea 8y ago

>* 1. Allowing generalized unicode identifiers.* I'm all for full support for unicode string manipulation. But when ever are "unicode identifiers" a good idea? All kinds of BS decisions (normalization etc) for no good reason at all. Would you share code with identifiers written in RTL language? Chinese? Hieroglyphics? And I'm saying this as someone who's not a native English speaker. If it was an APL dialect I'd see some reasoning, but what good does it do for Go?

johnvega 8y ago

"... keeping the language small and clean" + Go Modules is the sweet spot for me.

klodolph 8y ago
That’s 1.12 though, isn’t it? I’m not disagreeing that it’s the sweet spot, I just think we already have it, or close enough.

glangdale 8y ago

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly reminiscent of Mac fanboys claiming PowerPC chips were the Very Best right up until this was obviously not true. C++ generics are a PITA in many ways, but you can be insanely productive in the STL without having to hand-roll everything and with good type safety. Despite the pain, I've been amazed at how easily you can build up some really complex data structures as pretty much one-liners ("Oh, I need a vector of maps from a pair of Foo to a set of Bar") that would either take a preposterous amount of code (or be a type-unsafe disaster waiting to happen) without generics. Hopefully the final Go 2 generics proposal will capture some of this goodness without some of the horrifying C++ issues (error messages, bloat, sheer brain-numbing complexity).

burtonator 8y ago
I'm hoping things like generics can just be accepted to be a good idea moving forward and that we can all agree that languages without them are handicapped. I still fell things are up in the air about exceptions but maybe we can just agree on generics which would make me feel better. Using go without generics just felt insane to me...
- cultus 8y ago
  Yeah, Go has some really fantastic aspects around tooling and a good concurrency story, but it's otherwise such a huge step backwards. I can't fathom the reason for not having generics. It's such a simple, completely common-sense abstraction. Things like typeclasses or multimethods offer vastly more abstraction power. These are (a bit) more difficult to understand, but you certainly don't have to be a genius (take it from me). I can kind of get why a language targeted towards "average" programmers might want to omit these. But here's the thing: The less abstraction power a language has, the more complexity must be handled by the developer. This leads to things like Java Spring, which you do have to be a genius to understand.

sova 8y ago

Throw Semver OuT THE WINDOW!

RickJWagner 8y ago

What's that famous tag line? Oh, yes: "Use of Go 2 Considered Harmful".

rqs 8y ago

One question: As far as my knowledge told me, anything (or most?) interface{} in Go will be put to heap instead of stack. Will generics change that? I really want to utilize those 2~4K stack spaces for the routines.

throwaway487549 8y ago

I would love to have type-clases a-la Haskell (implicits with parametric polymorphism, which is dead-simple and well understood) and universal pattern matching everywhere, but this is, of course, just a dream. I would love to have ML/Scala-style syntax for curried functions and function definition via pattern-matching with guards, which is also, it seems, out of questions. Actuall, the more of ML a strict language gets in - the better. What is really funny is that Bell Labs did a lot of ML research, especially on stdlib, but Go team is ignoring everything which is not of the C flavour. Pity. Again, ML is absolutely wonderful, and type-classes are the biggest single major innovation since Smalltalk. It is better to lean towards ML instead of heading towards Javascript.

ThorinJacobs 8y ago

I know the comments aren't meant for silly jokes but I'm very disappointed that there's no "Go 2 Considered Harmful" jokes here

nickm12 8y ago
This is a awesome joke. Thanks for the laugh.
idle_zealot 8y ago
There's this[0] one from 10 hours ago, but it's pretty buried by actual discussion at this point. [0]: https://news.ycombinator.com/item?id=18561684 https://news.ycombinator.com/item?id=18561684

gBecks 8y ago

I've yet to see any mention of immutable data types, which I find I would use more than even generics.

sidcool 8y ago

I am torn apart between investing the next one year between Go and Rust. I want to do some cool systems level programming. Both seem to be very good at it. Go has additional advantages of being older (and may be wiser). What does the hivemind think?

zbentley 8y ago
> some cool systems level programming. What projects did you have in mind? I think the answer to your question depends on what you mean by "systems level programming" and what you plan on doing/trying.

akuji1993 8y ago

With that naming practice, it will probably become as hard to google problems as with AngularJS and Angular 2.

tromp 8y ago

Wasn't Go2 considered harmful :-?

dingle_thunk 8y ago

Awaiting obligatory "go 2 considered harmful" YNews article.

leshow 8y ago

It seems Go wants to have a more open development process, but it looks like all the decisions are ultimately under the purview of the "Go team". Does the Go team include any community members? Or is this "open process" still essentially up to whims of a small group working at Google?

systemBuilder 8y ago

When I was young I thought Dijkstra published a paper called, "go2's considered harmful!'. I think the next version of Go should be Go3.