41–50 of 75 posts
Earlier quoted context omitted.
> 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".
Earlier quoted context omitted.
> 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.
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!")
}
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.
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.
> I am on the side for proper dependency management.
Earlier quoted context omitted.
At 54:51 in response to the generics question, "I said we are going to leave the language, we are done".
He means "we are going to leave the language [alone], we are done [changing it]." There is no expectation that the community will change the language instead.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
My C, C++ and Java Ant scars in Fortune 500 consulting projects tell me otherwise.
Earlier quoted context omitted.
My C, C++ and Java Ant scars in Fortune 500 consulting projects tell me otherwise.
That's fine. Some do it badly, and some do it well.
Does not seem very supportive of vendoring.
Earlier quoted context omitted.
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.
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…
As willvarfar points out, I feel Rob Pike is being disingenous when he talks about this. Golang uses less significant whitespace than Python, but it exists, the difference is in degree. If he prefers to minimize the impact of whitespace in Go code, that's fine. But why does he have to talk about it as an error or misjudgment?
If significant whitespace is such a bad idea, why do exist keywords that require whitespace around them in Go (package, func, type, etc.? Why can't I use whitespace in names in Go? This didn't happen in good old FORTRAN ;)
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.…
No, the official apologist story is: we will add them as soon as we find a way to avoid all tradeoffs of the 3 different approaches to generics.
And when asked how are they going to find this "magic bullet" solution since noone seems to be looking for it, some Go devs wrote HN comments to say that "we are looking into them [generics]".
I'm a little offended, because nobody admitted what Rob said at the conference -- and they even tried to convince us of the contrary. That was like 2-3 months ago.