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

31–40 of 75 posts

Re: GopherCon 2014 Videos

#31

Post by sagichmal »

pjmlp wrote: post #26
valevk wrote: post #24

Earlier quoted context omitted.

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.

    > [go get] Only works for source code packages, not
    > binary dependencies.
There's no such thing as a binary dependency in the Go ecosystem. (At least, not without stretching some definitions.) It's one of Go's greatest strengths, actually.

    > There isn't a way to specific source code versions/tags 
    > in a portable way.
Well, the best practice is to vendor[0], and there are plenty of third-party tools like godep[1] that can manage it for you.

___

[0] http://peter.bourgon.org/go-in-production/#dependency-manage...

[1] https://github.com/tools/godep

Re: GopherCon 2014 Videos

#32

Post by sagichmal »

willvarfar wrote: post #30
dmunoz wrote: post #21

Earlier quoted context omitted.

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

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.

Re: GopherCon 2014 Videos

#33

Post by sagichmal »

pjmlp wrote: post #28
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.

    > Rob said something interesting at the end, it appears 
    > they are leaving the language to the community and 
    > stepping out.
He said nothing to imply that at all.

Re: GopherCon 2014 Videos

#34

Post by FranOntanaya »

ForHackernews wrote: post #6
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/

I was pretty disappointed when Mozilla dropped native Gopher support from Firefox.

There's still plugins for it though.

Re: GopherCon 2014 Videos

#35

Post by pjmlp »

sagichmal wrote: post #33
pjmlp wrote: post #28

Earlier quoted context omitted.

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.

> Rob said something interesting at the end, it appears > they are leaving the language to the community and > stepping out. He said nothing to imply that at all.

At 54:51 in response to the generics question, "I said we are going to leave the language, we are done".

Re: GopherCon 2014 Videos

#36

Post by pjmlp »

sagichmal wrote: post #31
pjmlp wrote: post #26

Earlier quoted context omitted.

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.

> [go get] Only works for source code packages, not > binary dependencies. There's no such thing as a binary dependency in the Go ecosystem. (At least, not without stretching some definitions.) It's one of Go's greatest strengths, actually. > There isn't a way to specific source code versions/tags > in a portable way. Well, the best practice is to vendor[0], and there are plenty of third-party tools like godep[1] tha…

Vendoring is a practice stuck in C and C++ archaic tooling support ideas.

I am on the side for proper dependency management.

> It's one of Go's greatest strengths, actually.

Which will keep it outside the boring closed source enterprise commercial library tooling.

Re: GopherCon 2014 Videos

#37

Post by Shamanmuni »

cespare wrote: post #13
willvarfar wrote: post #10

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…

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

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.

Re: GopherCon 2014 Videos

#38

Post by lmm »

pjmlp wrote: post #28
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.

What else does one use C for? Applications that are too latency-sensitive for garbage collection maybe, but Go doesn't help there.

Re: GopherCon 2014 Videos

#39

Post by pjmlp »

lmm wrote: post #38
pjmlp wrote: post #28

Earlier quoted context omitted.

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.

What else does one use C for? Applications that are too latency-sensitive for garbage collection maybe, but Go doesn't help there.

Sadly for too many user space applications that are better served with safer languages, having native compilers available, that tend to be ignored by many.

Re: GopherCon 2014 Videos

#40

Post by dsymonds »

pjmlp wrote: post #36
sagichmal wrote: post #31

Earlier quoted context omitted.

> [go get] Only works for source code packages, not > binary dependencies. There's no such thing as a binary dependency in the Go ecosystem. (At least, not without stretching some definitions.) It's one of Go's greatest strengths, actually. > There isn't a way to specific source code versions/tags > in a portable way. Well, the best practice is to vendor[0], and there are plenty of third-party tools like godep[1] tha…

Vendoring is a practice stuck in C and C++ archaic tooling support ideas. I am on the side for proper dependency management. > It's one of Go's greatest strengths, actually. Which will keep it outside the boring closed source enterprise commercial library tooling.

Vendoring is also a practice that Google and other large tech companies use extensively. Just because something is old doesn't mean it's a bad idea.
Post reply on HN