10 ms·

GopherCon 2014 Videos

• pecanpieyw 12y ago
  Finally! Thanks for all the effort!
• canadev 12y ago
  I am watching the keynote, it looks interesting. I don't know Go at all, though I know several languages including C. I don't quite know what he is talking about when he talks about main and initialization. Can anyone elaborate on this for me? I hate to say this because I feel like a jerk in doing so, but I'm about 25 minutes in and the little gopher that scrolls across the screen (some sort of advertisement, I think) is so distracting. It is awful.
  • leaveyou 12y ago
    Function main() in package "main" is the entry point for a Go application but it is not the first code that gets executed when you start a Go app. Each package can have an init() function which gets executed in the order of dependency (if pkg A imports pkg B then B.init() is executed before A.init()) before main.main() is executed.
    • canadev 12y ago
      I see. Thank you.
    • Laremere 12y ago
      It's slightly more complicated than that: In addition to the init() function, variables on the package level can be initialized during initialization too. For example: http://play.golang.org/p/tvlX7cqaaB http://play.golang.org/p/tvlX7cqaaB This is important for package level variables such as arrays. Since there are only a very limited number of types which can be constants in Go, everything else which you'd use like a constant needs to be initialized.
      • leaveyou 12y ago
        If we go in details, we can also add that goroutines created in init() or at init time are effectively started only after all init() functions finish.
  • chubot 12y ago
    Not a Go expert, but I think it has to do with global variables/constants in modules. In C, what can run before main() is extremely limited. In C++, much more can happen before main(), i.e. running constructors for static objects, and the initialization order is undefined (this is a pretty well known problem). I guess in Go you can also have relatively elaborate static initialization, so it has a similar problem as C++? Interested if any Go users can elaborate on this.
    • pjmlp 12y ago
      Like in the Object Pascal/Modula-2 language family, you can define a package initialization sections. There are executed before control reaches main, and you need to have import relationships into consideration.
  • bketelsen 12y ago
    The gophers are being removed by popular demand.
    • canadev 12y ago
      Nice!
• mindcrime 12y ago
  OK, who wants to put on a GopherCon 2015 next year, dedicated to actual Gopher[1][2][3][4]? I mean, there is a precedent for this sort of thing. http://iubio.bio.indiana.edu/soft/util/gopher/gophercon1.txt http://iubio.bio.indiana.edu/soft/util/gopher/gophercon1.txt [1]: https://en.wikipedia.org/wiki/Gopher_%28protocol%29 https://en.wikipedia.org/wiki/Gopher_%28protocol%29 [2]: gopher://gopher.floodgap.com/ [3]: https://addons.mozilla.org/en-US/firefox/addon/overbiteff/ https://addons.mozilla.org/en-US/firefox/addon/overbiteff/ [4]: gopher://sdf.lonestar.org/
  • rsync 12y ago
    cuervocon > gophercon
  • ForHackernews 12y ago
    I was pretty disappointed when Mozilla dropped native Gopher support from Firefox.
    • FranOntanaya 12y ago
      There's still plugins for it though.
  • danieldk 12y ago
    From the first link: Finally, the relative numeric success of Gopher over WWW was discussed (there are orders of magnitude more Gopher servers than WWW servers out there): Gopher seems to have won out primarily because of the ease of entry (it's much harder to put up a WWW server than a Gopher server), although another factor may be that a hierarchical presentation is more appropriate than hypertext for the broad-based audience of a CWIS. :)
    • pjmlp 12y ago
      When I started my CS degree we still used mostly Gopher, the WWW browsers started to appear on campus AIX, DG/UX terminals around one year later.
  • 12y ago
• georgecalm 12y ago
  > Ken: lary and sergey came by tonight... > Ken: p.s. one of larrys comments was "why isnt function spelled func? > Rob: fine with me. seems compatible with 'var' > Rob: anyway we can always say, "larry said to call it 'func'"
• gw 12y ago
  I've wondered what the story was on Go's dependency management, so I'm glad someone brought it up at the end of the keynote. Pike said that it was up to the community to develop tools to deal with that. This is what happened in the Clojure community when Leiningen became the de facto standard, but its dependency management builds on a pre-existing system (Maven). I am curious if this is on anyone's radar, or if it isn't considered a problem.
  • msmith 12y ago
    Ruby's dependency management (rubygems) also came from the community and is now part of the standard library. That seems like a good model to follow. Dependency management for Go is definitely on people's radar. https://github.com/tools/godep https://github.com/tools/godep has been getting some traction.
    • cridenour 12y ago
      Same with Python/pip with 3.4
  • pjmlp 12y ago
    Take some popcorn and go through the discussions on golang-nuts mailing list. There is a big discussion between those that think a language without dependency management tooling does not make sense in modern times. And those that think it should be abolished from the face of earth and replaced with git revisions and pure open source, regardless of industry needs.
  • valevk 12y ago
    Isn't "go get ..." the dependency management tool for Go?
    • pjmlp 12y ago
      Not really. Only works for source code packages, not binary dependencies. There isn't a way to specific source code versions/tags in a portable way. Also makes the import paths dependent on your repositories.
• willvarfar 12y ago
  I really enjoyed the keynote. The joke about the profound error of using whitespace just shows how partisan these discussions are. In go, with the semi-colon insertion rules and with gofmt, there is an implicit whitespace rule all over again. Personally, I like whitespace because its how my mind reads code. Its nice in Python, mostly because of how concise Python is to read. Its a bit of a bind in Java, where you don't trust tools to roll-up functions but on the other hand they all seem so long and full of boilerplate. With gofmt, the go world lives in a significant whitespace world they just don't want to admit it :)
  • cespare 12y ago
    > In go, with the semi-colon insertion rules and with gofmt, there is an implicit whitespace rule all over again. Can you explain what this means?
    • Shamanmuni 12y ago
      It means that you have to be careful about how you treat whitespace (mostly newlines and how they relate to curly braces), otherwise a semicolon could be inserted where it shouldn't or gofmt could format your code in a way you didn't mean to. So, the whitespace is significant in Go too.
      • NateDad 12y ago
        Newlines are important, but that's true of pretty much every language. Go does have more stringent requirements on where open braces are placed, but it's not a hard rule to remember (they always go on the same line as the code that opens the new scope). Also, this rule makes your code significantly less prone to breakage from errant edits and merges, since inserting a line can never separate your brace from the line it goes with. In this way, Go is actually more robust with respect to whitespace than almost any other language. Note that in languages that don't mandate the open brace be on the same line as the code that opens the new scope, this can happen during a merge: // original code if (foo) { printf("foo is true!") } // after the merge if (foo) someFunction() { printf("foo is true!") } Now this code will always print "foo is true!". Because Go requires the open brace to be on the same line as the if, this type of bug is impossible in Go. Gofmt will never change the behavior of your code, so you don't have to "worry" about what it will do. It only makes cosmetic changes to code, never functional.
• willvarfar 12y ago
  So, in the keynote, Rob underlines again that there'll be no generics. Ever. Path to getting generics thus becomes: 1. A preprocessor that eats ggo (generic go) files and emits go. This is is like the original C++ which translated to C for compilation. 2. Someone integrates ggo into go to speed it all up.
  • dmunoz 12y ago
    > So, in the keynote, Rob underlines again that there'll be no generics. Ever. No. He said there were no plans for generics, which has been the story for some time. The official FAQ still states [0]: > Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly. It is my understanding that what Mr. Pike means by there being no plans for generic is in relation to the sentence > We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. [0] http://golang.org/doc/faq#generics http://golang.org/doc/faq#generics
    • willvarfar 12y ago
      At the very end of the keynote, he fields questions from the audience. Predictably, he is asked about generics (54 mins in). His reply is very clear: "There are no plans for generics. I said we're going to leave the language; we're done."
      • sagichmal 12y ago
        By "the language" he means Go major-version-1. There will be no generics in Go 1, that's clear. The path is wide open for Go 2, though.
    • coldtea 12y ago
• aaronbrethorst 12y ago
  So disappointed, again, that this has nothing to do with my alma mater, the U of MN.