Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GopherCon 2014 Videos

confreaks.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: GopherCon 2014 Videos

#21

Post by dmunoz »

willvarfar wrote: post #19

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.

> 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

Re: GopherCon 2014 Videos

#22

Post by dagw »

mindcrime wrote: post #4

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 [1]: https://en.wikipedia.org/wiki/Gopher_%28protocol%29 [2]: gopher://gopher.floodgap.com/ [3]: https://addons.mozilla.org/en-US/firefox/addon/overbiteff/ [4]: gopher://sdf.lonestar.org/

Or actual gophers for that matter.

Re: GopherCon 2014 Videos

#23

Post by Laremere »

leaveyou wrote: post #12
canadev wrote: post #3

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…

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.

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

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.

Re: GopherCon 2014 Videos

#24

Post by valevk »

gw wrote: post #9

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 is…

Isn't "go get ..." the dependency management tool for Go?

Re: GopherCon 2014 Videos

#25

Post by pjmlp »

chubot wrote: post #17
canadev wrote: post #3

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…

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…

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.

Re: GopherCon 2014 Videos

#26

Post by pjmlp »

valevk wrote: post #24
gw wrote: post #9

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 is…

Isn't "go get ..." the dependency management tool for Go?

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.

Re: GopherCon 2014 Videos

#27

Post by rm445 »

valevk wrote: post #24
gw wrote: post #9

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 is…

Isn't "go get ..." the dependency management tool for Go?

It is, but it doesn't do versioning, and people often like to target specific versions of the libraries that their programs depend on.

Re: GopherCon 2014 Videos

#28

Post by pjmlp »

willvarfar wrote: post #19

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.

Nowadays I consider Go as a better C, except for those scenarios where C is being used as a portable assembler.

Other than that, I spend my time with other languages.

Rob said something interesting at the end, it appears they are leaving the language to the community and stepping out.

Re: GopherCon 2014 Videos

#29

Post by leaveyou »

Laremere wrote: post #23
leaveyou wrote: post #12

Earlier quoted context omitted.

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.

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

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.

Re: GopherCon 2014 Videos

#30

Post by willvarfar »

dmunoz wrote: post #21
willvarfar wrote: post #19

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.

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

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

Post reply on HN